Aspnetcore: टेम्पलेट आधारित घटक

विशेष रूप से, इसका मतलब है कि हमें यह संकेत देने के लिए किसी तरह की आवश्यकता है कि एक घटक के भीतर बच्चे की सामग्री का एक हिस्सा Action<RenderTreeBuilder, T> रूप में संकलित किया जाना चाहिए, कुछ प्रकार के टी के लिए जिसे हमें डिजाइन पर उपयोग से गतिशील रूप से हल करने में सक्षम होना चाहिए समय। तब हमारा डिज़ाइन-टाइम कोडजन उस चाइल्ड एलिमेंट के अंदर रेजर एक्सप्रेशन लिखते समय सही इंटेलिजेंस संदर्भ उत्पन्न करने में सक्षम होगा।

उदाहरण:

<MyListWithHeader RowItems=@People>
    <Title>
        Here I'm still in the outer context so can reference properties on the component itself 
        such as <strong i="8">@TitleText</strong>
    </Title>
    <RowTemplate> <!-- Somehow need intellisense to know that RowTemplate is meaningful here, and that its "item" value is taken from the generic type arg on the RowItems property -->
        Here I'm in the context of an Action<RenderTreeBuilder, Person> because we supplied
        an IEnumerable<Person> as the value for RowItems, so I can write @item.FirstName
    </RowTemplate>
</MyListWithHeader>

<strong i="9">@functions</strong>
{
    string TitleText { get; set; }
    IEnumerable<Person> People { get; set; }

    class Person
    {
        public string FirstName { get; set; }
    }
}

मुझे यकीन नहीं है कि हम इस सुविधा को कितना सामान्य बनाना चाहते हैं। संभवतः ऊपर के स्केच में संकेत से कम सामान्य। @rynowak यहां लागू करने के लिए उचित विशेषज्ञ होगा। सभी जटिलता डिजाइन/संकलन समय पर है। इसे किसी रनटाइम समर्थन की आवश्यकता नहीं है जिसके बारे में मैं सोच सकता हूं।

हाय ने इसे एक आईनेमेरेबल पास करके इसे पूरा करने की कोशिश कीएक पैरामीटर के रूप में, मैं एक ग्रिड बनाने में सक्षम था लेकिन पैरामीटर बदलने पर मैं इसे अपडेट करने में सक्षम नहीं था। यह कोड है:

<table class="@ClassName">
  <tr>
    <strong i="7">@foreach</strong> (var col in Columns)
    {
      <th>@col</th>
    }
  </tr>

  <strong i="8">@foreach</strong> (System.Data.DataRow row in table.Rows)
  {
    <tr>
      <strong i="9">@foreach</strong> (var col in Columns)
      {
        <td>@row[col]</td>
      }
      <strong i="10">@if</strong> (Select != null)
      {
        <td><a @onclick(() => Select(row))>Seleccionar</a></td>
      }
    </tr>
  }
</table>

@functions{
    public string ClassName { get; set; }
    public List<string> Columns { get; set; }
    public object DataSource { get; set; }
    private System.Data.DataTable table;


    private string Log;

    //call backs it seens I will have many of them

    public Action Change { get; set; }
    public Action<object> Select { get; set; }

    protected void UpdateState()
    {
      int count = ((IEnumerable<object>)DataSource).Count();
      Log = $"Table count rows:{table.Rows.Count} count object ${count}";
      StateHasChanged();
    }

    protected override void OnInit()
    {
      base.OnInit();

      Change += StateHasChanged;

      var enumerable = (IEnumerable<object>)DataSource;
      table = new System.Data.DataTable();

      if (Columns == null)
      {
        Columns = new List<string>();
        Columns.AddRange(enumerable.FirstOrDefault().GetType().GetProperties().Select(x => x.Name).ToList());
      }


      Columns.ForEach(x =>
      {
        table.Columns.Add(x);
      });

      enumerable.ToList()
                .ForEach(x =>
                {
                  var row = table.NewRow();

                  foreach (var property in x.GetType().GetProperties())
                  {
                    row[property.Name] = property.GetValue(x);
                  }

                  table.Rows.Add(row);
                });

      StateHasChanged();
    }
}

@SteveSandersonMS , क्या आपके उदाहरण में Title और RowTemplate का मतलब MyListWithHeader या विशेष घटकों के गुण हैं? यदि वे गुण हैं, तो इसे व्यक्त करने के वैकल्पिक तरीकों के बारे में सोचने लायक हो सकता है ...

मैं एक्सएएमएल के साथ बहुत काम कर रहा हूं और जब मैंने ब्लेज़र के साथ प्रोटोटाइप करना शुरू किया तो मुझे तुरंत इस सुविधा की आवश्यकता महसूस हुई। क्या आपको लगता है कि इस परिदृश्य में एक्सएएमएल का संपत्ति तत्व वाक्यविन्यास उचित हो सकता है? काफी वर्बोज़ होने पर, यह स्पष्ट रूप से व्यक्त करता है कि हम MyListWithHeader चाइल्ड घटकों को जोड़ने के बजाय यहां गुण निर्दिष्ट कर रहे हैं। उदाहरण:

<MyListWithHeader>
    <MyListWithHeader.Title>
       ...
    </MyListWithHeader.Title>
    <MyListWithHeader.RowTemplate>
       ...
    </MyListWithHeader.RowTemplate>
</MyListWithHeader>

मेरा व्यक्तिगत विचार यह है कि रेजर को एचटीएमएल मुहावरों के जितना संभव हो उतना करीब रहना चाहिए, बजाय इसके कि हम एक्सएएमएल में देखे जाने वाले मुहावरों की ओर बढ़ें। इसका मतलब यह होगा कि आप सामान्य एक्सएएमएल चीजों की बजाय <table> में देखे जाने वाले तत्वों के पदानुक्रम की तरह दिख रहे हैं। हम आपके दिमाग में किसी का समर्थन करने के लिए पर्याप्त सामान्य हो सकते हैं, लेकिन मैं अभी भी "रेजर एचटीएमएल है" के शिविर में बहुत मजबूती से हूं।

पूरी तरह से इसके समर्थन में। अगर हम "IENumerable" के बजाय आइटम "ऑब्जर्वेबल कोलेक्शन" की सूची बना सकते हैं जो एक बोनस होगा। xaml की तरह pattrens की ओर बढ़ने से हमें एक उचित टेम्प्लेट सिस्टम मिलता है, जिसमें html की कमी होती है, वेब ui में सभी लोकप्रिय फ्रेमवर्क में एक टेम्प्लेट सिस्टम होता है, जो उन्हें बहुत एक्स्टेंसिबल बनाता है, जाहिर है ब्लेज़र में भी एक होना चाहिए, और एक नया बनाने के बजाय इसे एक होना बहुत अच्छा होगा जो पहले से ही एमएस और कई नेट देवों से प्यार करता है, तकनीकी रूप से यह अभी भी एचटीएमएल/सीएसएस आधारित होगा, इसलिए सभी एचटीएमएल डेवलपर्स अभी भी तकनीक की ओर आकर्षित होंगे क्योंकि यह एक्सएएमएल नहीं होगा (न जाने क्यों एचटीएमएल Guyx हालांकि xaml से नफरत करता है) लेकिन यह केवल xaml pattrens का पालन करेगा।

@DamianEdwards मैं "रेजर HTML है" के संबंध में आपसे पूरी तरह सहमत हूं। हालाँकि, HTML में विशेषता मान हमेशा प्रारंभिक टैग में विशेषताओं के रूप में निर्दिष्ट किए जाते हैं। बच्चे के तत्वों के रूप में टेम्पलेट्स जैसे जटिल विशेषता मानों को व्यक्त करने (और इसकी कोई आवश्यकता नहीं) करने का कोई तरीका नहीं है। उदाहरण के लिए आप लिख नहीं सकते

<a>
    <href>http://dot.net</href>
</a>

इसलिए मुझे लगता है कि हम तकनीकी रूप से जो लक्ष्य बना रहे हैं उसे शुद्ध HTML में व्यक्त नहीं किया जा सकता है।
यहां उन विकल्पों का सारांश दिया गया है जिन्हें मैं वर्तमान में देख रहा हूं:

1. HTML सिंटैक्स के साथ रहें : संपत्ति के मूल्यों को केवल एक घटक के शुरुआती टैग में निर्दिष्ट किया जा सकता है।

   • मुझे लगता है कि रिएक्ट ने यही चुना है, उदाहरण के लिए:
     <MyListWithHeader RowTemplate={(data) => <p>...</p>} />
   • प्रो : सामान्य HTML सिंटैक्स के बहुत करीब
   • Con : बहु-पंक्ति मानों के लिए गन्दा हो जाता है, अर्थात अधिक जटिल टेम्पलेट्स

2. HTML सिंटैक्स के साथ रहें : संदर्भ के आधार पर, किसी घटक के चाइल्ड नोड्स नेस्टेड तत्वों या संपत्ति असाइनमेंट का प्रतिनिधित्व कर सकते हैं।

   • प्रो : सामान्य HTML सिंटैक्स के बहुत करीब
   • Con : भ्रमित करने वाला हो सकता है क्योंकि प्रॉपर्टी असाइनमेंट और चाइल्ड एलिमेंट वाक्य-रचना की दृष्टि से अप्रभेद्य हैं। उदाहरण में, <Title>...</Title> एक स्टैंडअलोन घटक हो सकता है जबकि <RowTemplate>...</RowTemplate> आसपास के <MyListWithHeader> एक संपत्ति (एक विशेषता) हो सकता है - IntelliSense के बिना आप वास्तव में नहीं जानते हैं
   • Con : यदि कोई घटक और समान नाम वाली संपत्ति है, तो नामकरण के विरोध का कारण बन सकता है

3. नए सिंटैक्स का आविष्कार करें : एक्सएएमएल का प्रॉपर्टी एलिमेंट सिंटैक्स सिर्फ एक विकल्प है, यह कुछ रेजर का निर्माण <strong i="39">@functions</strong> { } या कुछ पूरी तरह से अलग हो सकता है।

   • प्रो : पठनीय होने के बावजूद मनमाने ढंग से जटिल टेम्पलेट्स की अनुमति देता है
   • Con : वेब देवों को अलग कर सकता है

यह पूरी तरह से संभव है कि मैं यहाँ कुछ गलत समझ रहा हूँ। यदि हां, तो कृपया मुझे बताएं।

@SvenEV मुझे नहीं लगता कि xaml सिंटैक्स किसी को भी अलग कर देगा, यदि आप ध्यान दें, कोणीय, वू, प्रतिक्रिया और लाखों अन्य ढांचे के लिए टेम्पलेट सिंटैक्स, सभी के पास अलग-अलग तरीके और सामान करने के लिए अलग-अलग वाक्यविन्यास हैं, फिर भी उन सभी को प्यार है, नहीं? इसी तरह ब्लेज़र का अपना सिंटैक्स हो सकता है, इसके मामले में एकमात्र समर्थक यह होगा कि हम इस ढांचे के लिए पहले से ही लोकप्रिय सिंटैक्स को लाने के लिए एक नया सिंटैक्स का आविष्कार नहीं करेंगे (इसलिए xaml देवों के लिए कम सीखने की अवस्था) लेकिन जहां तक ​​​​वेब देवों को माना जाता है वैसे भी ब्लेज़र टेम्प्लेट सीख रहे होंगे चाहे ब्लेज़र xaml का पालन करें या नहीं, वेब देवों के लिए सीखने की अवस्था समान रहती है, वेब देवों को इस खामी से दूर रहने का एकमात्र तरीका यह है कि यदि ब्लेज़र सीधे html का उपयोग करता है, जो मुझे नहीं लगता कि एक के रूप में एक्स्टेंसिबल होगा टेम्पलेट मॉडल। :)

इसलिए एक पूरी तरह से नया टेम्प्लेट सिंटैक्स प्रत्येक डेवलपर को सीखने की अवस्था देता है। लेकिन सिंटैक्स जैसा xaml आधे डेवलपर्स की कम से कम समस्या हल करता है। लेकिन xaml भी एचटीएमएल की तरह है, दोनों मार्कअप बाद में हैं। एक बार जब आप इसे सीख लेंगे, तो यह केक का टुकड़ा होगा, एक्सएएमएल तरीके से अच्छी बात यह है कि आपको सीएसएस के बारे में चिंता करने की ज़रूरत नहीं है, सभी स्टाइल नियंत्रण पर सीधे गुणों के साथ किया जाता है। और यहां तक ​​​​कि स्टाइल को भी समान सिंटैक्स के साथ किया जाता है, लेकिन दूसरी ओर html और css अलग-अलग सिंटैक्स और चीजों को करने की संरचना के साथ पूरी तरह से अलग भाषाएं हैं।

लेकिन हमें टेम्प्लेट की भी आवश्यकता क्यों है? मेरा मतलब है कि जब आप रेज़र में फ़ोरैच कर सकते हैं। टेम्प्लेट करने की तुलना में मेरे लिए बहुत आसान लगता है।
या यह पुन: उपयोग के कारण है? मैं एक अलग घटक की कल्पना कर सकता हूं जो उस मामले में foreach करता है।

@MihaMarkic टेम्प्लेट सब कुछ मानकीकृत करते हैं, यह पुन: उपयोग को बढ़ाता है, और सबसे महत्वपूर्ण बात यह है कि यह एक नियंत्रण के लिए लिखे गए सभी जटिल कोड को छुपाता है और आप कोड की 2 पंक्तियों के साथ उस रैप नियंत्रण का उपयोग कर सकते हैं और पुन: आविष्कार करने के बजाय अपने व्यावसायिक तर्क पर अधिक ध्यान केंद्रित कर सकते हैं। पहिया।

खैर, मुझे इस बारे में जानकारी नहीं है। IMO foreach एक टेम्प्लेट है, बस एक अधिक शक्तिशाली है और आप एक "foreach" टेम्प्लेट को एक अलग घटक में रख सकते हैं और कोड की उन दो पंक्तियों के साथ इसे कहीं से भी कॉल कर सकते हैं।

foreach सिर्फ एक लूप है और हाँ एक सरल नियंत्रण के लिए हम ऐसा कर सकते हैं, जैसे मूल ListView ( तालिका ) के लिए हम बस एक नियंत्रण बना सकते हैं जो कुछ इनपुट लेता है, इसे फोरचॉन करता है और एक टेबल थूकता है, और फिर हमें बस आवश्यकता होती है एक टैग लगाने के लिएऐसा कुछ और फिर हम एक टेबल तैयार करने में सक्षम होंगे, अगर हम एक आधुनिक डिजाइन, अत्यधिक इंटरैक्टिव इत्यादि के साथ एक अनुकूलित सूचीदृश्य चाहते हैं, तो हम foreach के साथ एक और घटक नियंत्रण बना सकते हैं, और बहुत सारे कटोम सीएसएस, और बहुत कुछ एक फ़ाइल में ब्लेज़र कोड, शायद एकाधिक फ़ाइलें, और उन सभी को 1 घटक में लपेटें, और फिर उस सभी को केवल 1 टैग के साथ उपयोग करें। आप देखते हैं कि मुझे इसके साथ कहां मिल रहा है? कोई फर्क नहीं पड़ता कि नियंत्रण में कितना कोड है, वह सब 1 टैग में लपेटा जा सकता है :) @ मिहामार्किक

यह केवल एक ही टेम्पलेट के साथ कई आइटम प्रस्तुत करने के बारे में नहीं है। एक घटक के कई हिस्सों को अनुकूलन योग्य बनाने के लिए भी इसकी आवश्यकता होती है। वर्तमान में, एक घटक के लेआउट में केवल एक ऐसा "छेद" हो सकता है जिसे ChildContent से भरा जा सकता है, एक पूर्वनिर्धारित संपत्ति, जैसे:

<div style="some fancy styling">
    <strong i="7">@ChildContent</strong>
</div>

अब कल्पना करें कि आप एक संवाद जैसे कई "छेद" के साथ एक घटक लिखना चाहते हैं जो आपको सामग्री के साथ-साथ शीर्षलेख, या एक बटन को अनुकूलित करने देता है जहां आप आंतरिक सामग्री को अनुकूलित कर सकते हैं लेकिन संदर्भ मेनू और टूलटिप के लिए टेम्पलेट भी निर्दिष्ट कर सकते हैं शायद। तो यह अच्छा होगा यदि आप निम्न की तरह कुछ लिख सकें (जो भी वाक्यविन्यास होगा):

<MyButton>
    <h2>I am the button caption (the usual ChildContent)</h2>

    <MyButton.ContextMenu>
        <button>Context menu button 1</button>
        <button>Context menu button 2</button>
    </MyButton.ContextMenu>

    <MyButton.ToolTip>
        This explains <strong>what the button does</strong>. It is displayed when hovering over the button.
    </MyButton.ToolTip>
</MyButton>

@SvenEV क्या सिर्फ कई छेद नहीं हैं और कड़ाई से टेम्पलेट की आवश्यकता नहीं है?

हाँ यह एक और उपयोगकेस का अच्छा उदाहरण है, प्रत्येक भाग को अनुकूलित करने योग्य होना चाहिए।

@MihaMarkic यह सच है, हम यहां दो अलग-अलग चीजों के बारे में बात कर रहे हैं:

1. कई छेदों के लिए समर्थन ( RenderFragment s / Action<RenderTreeBuilder> ) जैसा कि मेरे उदाहरण में है
2. उन टेम्प्लेट के लिए समर्थन जिनमें डेटा इनपुट ( Action<RenderTreeBuilder, T> ) है जैसा कि ListView आदि में है।

मुझे लगता है कि पहला दूसरे के लिए एक आवश्यकता है और मुझे उम्मीद है कि दोनों सुविधाओं को किसी बिंदु पर लागू किया जाएगा। यह हमें कुछ शक्तिशाली घटक पुस्तकालय बनाने में सक्षम करेगा।

यह किस समस्या को हल करने की कोशिश कर रहा है? मैं बस सोच रहा हूं क्योंकि मैंने अन्य एसपीए ढांचे में इस तरह की चीज नहीं देखी है।

क्या यह एक घटक आधारित संरचना के साथ संघर्ष करता है? साथ ही, क्या यह सामान्य वेब विकास प्रथाओं के खिलाफ जाता है ताकि अधिक "ऐप-जैसी" संरचना को मजबूर किया जा सके?

@AWulkan यह सामान्य घटक संरचना के खिलाफ नहीं जाता है, लेकिन हाँ यह संरचना की तरह ऐप-देव की ओर थोड़ा सा जाता है, लेकिन इसका मतलब यह नहीं है कि यह वेब विकास से दूर हो जाता है, बीसीजे सभी लोकप्रिय ढांचे भी वही काम कर रहे हैं, पूरा उद्देश्य एसपीए अवधारणा की यह थी। वेब विकास को ऐप विकास की तरह बनाने के लिए एसपीए बनाया गया था। और अब हर ढांचा स्पा का अनुसरण कर रहा है। स्पा का अगला चरण अब pwa है। आप जानते हैं कि एक pwa क्या सही है? यह मूल एप्लिकेशन जैसे नोटिफिकेशन और ऑफलाइन सिंक से कुछ प्रमुख विशेषताओं का परिचय देता है, इसलिए अंततः वेब देव समग्र रूप से देशी ऐप विकास का पालन करने की कोशिश कर रहा है।

@AWulkan चूंकि आप Vue से परिचित हैं, इसलिए मैंने अभी Vue डॉक्स में देखा कि क्या कुछ ऐसा ही है। वहाँ है और इसे " स्लॉट " कहा जाता है, विशेष रूप से "नामित स्लॉट" और "स्कोप्ड स्लॉट्स" - ठीक यही इस मुद्दे के बारे में है। यह वही अवधारणा है। शायद यह आपको इस मुद्दे को समझने में मदद करता है?

@SvenEV ओके मैं थोड़े देखता हूं कि आपका क्या मतलब है। जहां तक ​​मेरा संबंध है, यह एक बहुत ही विशिष्ट विशेषता है। स्पष्टीकरण देने के लिए धन्यवाद।

क्या वह इस मसौदे को एक मॉडल के रूप में इस्तेमाल करेगी?
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md

लगता है Vue.js स्लॉट XAML डेटा टेम्प्लेटिंग के समान है।
टेम्प्लेटिंग मौजूदा घटकों को अनुकूलित करने का एक शक्तिशाली तरीका प्रदान करता है, एक मामला जो मैं देख सकता था वह एक सूची दृश्य है जहां डिफ़ॉल्ट रूप से बिना टेम्प्लेटिंग के यह है कि यह सिर्फ स्ट्रिंग्स की सूची पर पुनरावृति करता है और इसे प्रदर्शित करता है।

<ListView list=<strong i="7">@ListOfUrlsAsStrings</strong> />

टेम्प्लेटिंग के साथ आप यह कहने के लिए ओवरराइड कर सकते हैं, इसके बजाय पास किए गए Type T का उपयोग करके छवि टैग की एक सूची दिखाएं।

<ListView list=@ListOfUrlsAsStrings>
    <ListView.ListTemplate>
         <img src=<strong i="12">@item</strong> alt="overriden by a template" />
        <CustomComponentHere />
    </ListView.ListTemplate>
</ListView>

यह घटकों की पुन: प्रयोज्यता में काफी वृद्धि करेगा क्योंकि वे गतिशील हो सकते हैं। तीसरे पक्ष के घटक विक्रेता इस तरह से घटकों को संलेखित करने पर अधिक रचनात्मक हो सकते हैं।

हाँ बिल्कुल डेटा टेम्पलेट बाइंडिंग के साथ सरल और देखने योग्य हो जाता है

हमें बहुत उम्मीद है कि ब्लेज़र घटकों को नेस्टिंग और टेंपलेटिंग के लिए अच्छा समर्थन मिलेगा।
पहले हमने रेजर टैग हेल्पर्स के लिए एक ही विषय पर @Mehul , @NTaylorMullen , @DamianEdwards के साथ कई चर्चाएँ की थीं , जिसमें हमने यह समझाने की कोशिश की थी कि हमें अधिक XAML- जैसे दृष्टिकोण की आवश्यकता क्यों है। प्रासंगिक गिटहब मुद्दे: एस्पनेट/रेजर # 474, एस्पनेट/रेजर # 576, एस्पनेट/रेजर # 570।

हम डेटा ग्रिड जैसे यूआई घटक विकसित करते हैं और विजेट को कॉन्फ़िगर करने के लिए विशिष्ट मार्कअप इस तरह से टहनी हो सकता है:

<TabPanel>
    <Grid>
        <DataSource>
            <More about data source />
        </DataSource>

        <Column />
        <Column>
            <Lookup>
                <DataSource>
            . . .
            <CellTemplate>
                arbitrary html
            </CellTemplate>
        </Column>

        <DetailTemplate>
            <div>arbitrary content</div>
            <ThirdPartyComponent />

            <Grid>
                detail grid configuration with own templates (and there may be more levels)
            </Grid>
        </DetailTemplate>
    </Grid>
</TabPanel>

इस तरह के पदानुक्रम के लिए, एक डेवलपर सटीक संदर्भ जागरूकता और इंटेलिजेंस चाहता है।

@AlekseyMartynov क्या हमारे पास लंबे समय में स्टाइलिंग + एनिमेशन जैसे xaml हो सकते हैं?

मुझे बहुत खुशी है कि यह विचार कर्षण प्राप्त कर रहा है। चूंकि एमएस ने सिल्वरलाइट, डब्ल्यूपीएफ और यूडब्ल्यूपी के साथ टेम्पलेटेबल नियंत्रण के विचार का बीड़ा उठाया है, इसलिए इसे ब्लेज़र का हिस्सा बनाना समझ में आता है।

एक प्रश्न डेटा/कोड संदर्भ होगा। जब cshtml टेम्प्लेट बाउंड C# ऑब्जेक्ट में कोड को संदर्भित करता है जो कि संभवतः बड़े घटक के समान संदर्भ में नहीं होने वाला है। तो क्या किसी प्रकार के डायनेमिक डेटा बाइंडिंग की आवश्यकता नहीं होगी? या एक टेम्पलेट के पास सख्त लक्ष्य प्रकार की आवश्यकता होगी ताकि पार्सर जानता हो कि डेटा बाध्य ऑब्जेक्ट सदस्यों के संदर्भों को कैसे हल किया जाए?

उस नोट पर, गतिशील डेटा बाध्यकारी और निर्भरता गुणों के बारे में क्या? जहां तक ​​मैं बता सकता हूं, इस समय इसे रोकने वाला कुछ भी नहीं होगा। या प्रतिबिंब समस्याग्रस्त होने जा रहा है यदि सी # या आईएल हवाओं को मोनो द्वारा व्याख्या करने के बजाय वासम में संकलित किया जा रहा है?

@AlekseyMartynov जो सुझाव दे रहा है

मेरी परियोजना Xamzor में मैंने कुछ सीमित टेम्पलेटिंग समर्थन इस तरह लागू किया है:

<ListView ItemTemplate="typeof(MyCustomTemplate)" ... />

जहां MyCustomTemplate एक संपत्ति "DataContext" के साथ एक और Blazor घटक है जिसे ListView द्वारा असाइन किया जाता है। हालांकि यह काफी अच्छी तरह से काम करता है, फिर भी एक अलग घटक के बजाय टेम्प्लेट इनलाइन को परिभाषित करना वांछनीय है, खासकर यदि टेम्प्लेट छोटे और सरल हैं।

शायद ember.js प्रासंगिक घटक कुछ प्रेरणा प्रदान कर सकते हैं: https://www.mutuallyhuman.com/blog/2016/09/23/creating-an-accordion-with-contextual-components-in-ember

@SvenEV मैं मानता हूं कि सरल टेम्प्लेट के मामले में इनलाइन टेम्प्लेट मददगार होंगे, लेकिन हमारे पास अभी भी आपके प्रोजेक्ट में लागू किए गए अलग-अलग कंपोनेंट टेम्प्लेट के लिए विकल्प होना चाहिए, क्योंकि इससे हमें चिंताओं को अलग करने और टेम्प्लेट की पुन: प्रयोज्यता में मदद मिलती है :)

मेरे दिमाग में तीन चीजें:

1. घटकों को मूल रूप से श्रेणीबद्ध बनाएं (उदा. पेरेंटकंपोनेंट टाइप प्रॉपर्टी; ताकि आप MyTableComponent -> MyRowComponent -> MyColumnComponent) को लागू कर सकें। यदि माता-पिता कॉम्पोनेंट टाइप शून्य है, तो घटक किसी भी घटक प्रकार का बच्चा हो सकता है (उदा। MyTableComponent.ParentComponentType शून्य हो सकता है)।

पदानुक्रम को घटकों की परिभाषाओं में घोषणाओं के माध्यम से लागू किया जाता है जैसे:

```सी#
// MyRowComponent में
पेरेंटकंपोनेंट टाइप टाइप करें {प्राप्त करें; } = टाइपऑफ़ (MyTableComponent);
...

// In MyColumnComponent
Type ParentComponentType {get; } = typeof(MyRowComponent); 
...

Thus, MyColumnComponent can only be created within a MyRowComponent, and MyRowComponent can only be created within a MyTableComponent.

2. Allow components to be extended via ITemplateable interface. When the ITemplateable.Template [Tag] property is valued, it overrides the component's default rendering. Internally, it's something like:

```C#
    if (component is ITemplateable)
    {
        if (component.Template != null)
        {
            … return template rendering ...
        }
    }
    … return default rendering ...

1. एक इंटरफ़ेस ITemplate बनाएं जिसे वैकल्पिक बेस क्लास BlazorTemplate के रूप में कार्यान्वित किया जा सकता है, जिसका उपयोग टेम्पलेट्स के साथ प्रोग्रामिंग को ऑब्जेक्टिफाई करने के लिए किया जा सकता है।

नमूना उपयोग जहां MyColumnComponent ITemplateable है:

    <MyTableComponent>  
        <MyRowComponent>  
            <MyColumnComponent>  
                <Template>  
                    …  template codes here; can contain a call to another component ...
                </Template>  
            </MyColumnComponent>  
        </MyRowComponent>  
    </MyTableComponent>  

MyColumnComponent के साथ ITemplateable के रूप में परिभाषित किया गया है, यह <Template> … </Template> टैग युक्त समर्थन करता है। इस टैग की प्रविष्टियाँ MyColumnComponent के डिफ़ॉल्ट रेंडरिंग को ओवरराइड करती हैं।

आंतरिक रूप से, MyColumnComponent विशेष टेम्पलेट व्यवहारों, घटनाओं और विशेषताओं को प्रोग्रामेटिक रूप से संभालने के लिए BlazorTemplate कार्यान्वयन कर सकता है/उपयोग कर सकता है।

मैं संपत्ति तत्व सिंटेक्स के लिए मतदान कर रहा हूँ

<Button>
  <Button.ContextMenu>
    <ContextMenu>
      <MenuItem Header="1">First item</MenuItem>
      <MenuItem Header="2">Second item</MenuItem>
    </ContextMenu>
  </Button.ContextMenu>

  Right-click me!
</Button>

के विकल्प के रूप में

<Button ContextMenu=@GetContextMenuRenderFragment()>
  Right-click me!
</Button>

मुझे यह पसंद है, लेकिन क्या वेब शुद्धतावादी इस पर अपनी नाक नहीं मोड़ेंगे क्योंकि यह XAML की तरह बहुत अधिक है?

नहीं, वे ठीक रहेंगे, property element syntax html attribute syntax (प्रतिस्थापन नहीं) का एक विकल्प है। लेकिन मैं बाहर निकल रहा हूं कि यह घटक डेवलपर्स के लिए कितनी सकारात्मकता प्रदान करता है (यूआई नियंत्रण पुस्तकालय देव)

मुझे यह भी पसंद है क्योंकि यह अधिक स्पष्ट रूप से बताता है कि बच्चा माता-पिता से कैसे संबंधित है, यह विशेष रूप से टेम्पलेटिंग पर अच्छा है क्योंकि आप यह भेद करने में सक्षम होंगे कि यह एक कस्टम घटक के बजाय माता-पिता से डेटा टेम्पलेट है जिसका कोई संबंध नहीं है मूल घटक।

इस कदर:

<List>
    <List.DataTemplate>
      <!-- Template Here -->
    </List.DataTemplate>
    <ComponentWithNoRelationToTheList />
</List>

यह आपको एक विचार देता है कि DataTemplate समग्र रूप से एक कस्टम टेम्पलेट की तुलना में सूची से संबंधित है। हालांकि मैं एक्सएएमएल की तरह सहमत हूं, यह सिर्फ एक विकल्प होना चाहिए।

क्या होगा यदि "टेम्पलेट" किसी टेम्पलेट करने योग्य ब्लेज़र घटक के लिए एक आरक्षित/विशेष कीवर्ड है? जब एक टैग के रूप में उपयोग किया जाता है, तो इसमें टेम्पलेट कोड हो सकते हैं। जब एक विशेषता के रूप में उपयोग किया जाता है, तो यह एक नामित टेम्पलेट निर्दिष्ट कर सकता है, जिसमें टेम्पलेट कोड हो सकते हैं।

तो, आइए एक घटक की कल्पना करें जैसे:

ComponentTemplateTest.cshtml

<strong i="7">@functions</strong>
{
  [Parameter]
  public RenderFragment Template { get; set; }

  [Parameter]
  public RenderFragment<int> TemplateWithInt { get; set; }

  [Parameter]
  public RenderFragment<TestObject> TemplateWithObject { get; set; }

  public class TestObject
  {
      public string PropString { get; set; }
      public int PropInt { get; set; }
  }

  private TestObject testobject = new TestObject();
}

<div>
    <div><button onclick="@((x) => this.testobject.PropInt++)">test</button></div>
    <div>@Template</div>
    <div>@((RenderFragment)(x => TemplateWithInt(x, testobject.PropInt)))</div>
    <div>@((RenderFragment)(x => TemplateWithObject(x, testobject)))</div>
</div>

हम इसे के रूप में उपयोग कर सकते हैं

<ComponentTemplateTest>
    <Template>
        test simple template
    </Template>

    <TemplateWithInt params="param1">
        <strong i="11">@param1</strong>
    </TemplateWithInt>

    <TemplateWithObject params="paramObject">
        @paramObject.PropInt
    </TemplateWithObject>
</ComponentTemplateTest>

हमें params जैसी विशेषता की आवश्यकता है क्योंकि ब्लेज़र कोड को इस प्रकार लिखता है

            builder.OpenComponent<StandaloneApp.ComponentTemplateTest>(16);
            builder.AddAttribute(17, "template", (Microsoft.AspNetCore.Blazor.RenderFragment)((builder2) => {
                builder2.AddContent(18, "\n        test simple template\n    ");
            }
            ));
            builder.AddAttribute(19, "templatewithint", (Microsoft.AspNetCore.Blazor.RenderFragment<System.Int32>)((builder2, param1) => {
                builder2.AddContent(20, param1);
            }
            ));
            builder.AddAttribute(21, "templatewithobject", (Microsoft.AspNetCore.Blazor.RenderFragment<StandaloneApp.ComponentTemplateTest.TestObject>)((builder2, paramObject) => {
                builder2.AddContent(22, "\n        ");
                builder2.AddContent(23, paramObject.PropInt);
                builder2.AddContent(24, "\n    ");
            }
            ));
            builder.CloseComponent();

यह पर्याप्त होगा? कुछ याद आ रही है?

@uazo बस ध्यान दें, संपत्ति तत्व सिंटैक्स के बिना property और component बीच अंतर करना असंभव है।

@danieldegtyarev मुझे लगता है कि हम यहां दो अलग-अलग चीजों के बारे में बात कर रहे हैं ... मेरा लक्ष्य अभी के लिए घटकों के लिए केवल टेम्पलेट है ...

https://github.com/uazo/Blazor/tree/dev-experimental-template-component पर एक नज़र डालें
आपको उस एक्सटेंशन को बनाने और स्थापित करने की आवश्यकता है ...

टैग के रूप में प्रयुक्त "टेम्पलेट" घोषणात्मक और स्वाभाविक रूप से इनलाइन है:

<MyCom MyComProp="MyComPropValue">
    <Template>
        Components, @MyCom.MyComProp, HTML, content and <strong i="6">@values</strong>
    </Template>
</MyCom>

"टेम्पलेट" को "नामित टेम्पलेट" निर्दिष्ट करने के लिए टैग के रूप में उपयोग किया जाता है। आंतरिक रूप से, नामित टेम्पलेट के पास इसके मूल घटक तक पहुंच होगी, ताकि MyCom.MyComProp जैसा कुछ भी संभव हो:

<MyCom MyComProp="MyComPropValue">
    <Template Name="MyTemplate {Content: @content; Values: @values}" />
</MyCom>

"टेम्पलेट" का उपयोग "नामित टेम्पलेट" निर्दिष्ट करने के लिए एक विशेषता के रूप में किया जाता है। आंतरिक रूप से, नामित टेम्पलेट के पास इसके मूल घटक तक पहुंच होगी, ताकि MyCom.MyComProp जैसा कुछ भी संभव हो:

<MyCom 
    MyComProp="MyComPropValue"
    Template="MyTemplate {Content: @content; Values: @values}" />

टैग के रूप में या विशेषता के रूप में उपयोग किए जाने वाले "टेम्पलेट" के परिणामस्वरूप समान संकलन होना चाहिए, जैसे कि घटक प्रदान की गई टेम्प्लेट जानकारी को प्रस्तुत करेगा, जो कि घटक के डिफ़ॉल्ट रेंडर को ओवरराइड करता है।

एक "नामित टेम्पलेट" एक पुन: प्रयोग करने योग्य टेम्पलेट है। "नामित टेम्पलेट" बनाना लगभग एक घटक बनाने जैसा है। हालांकि, बड़ा अंतर यह है कि नामित टेम्पलेट का उपयोग केवल "टेम्पलेट" के लिए एक घटक के समर्थन के माध्यम से किया जा सकता है।

एक टेम्पलेट में घटक हो सकते हैं, लेकिन संभावित अनंत लूप को रोकने के लिए चेक डालने की आवश्यकता होती है, उदाहरण के लिए, एक घटक जो एक ही घटक का उपयोग करने वाले टेम्पलेट का उपयोग करता है उसे कोडित किया जाता है ... डिज़ाइन/संकलन-समय त्रुटि शायद?

प्रश्न: क्या एक नामित टेम्पलेट किसी अन्य टेम्पलेट से प्राप्त हो सकता है? क्या किसी नामित टेम्पलेट को केवल विशिष्ट घटक प्रकार (प्रकारों) के साथ उपयोग करने के लिए प्रतिबंधित किया जा सकता है?

मुझे लगता है कि आप लोगों को जितना हो सके एचटीएमएल सिंटैक्स के लिए जाना चाहिए, नई चीजें पेश न करें। कोई Xamarin xaml वाक्यविन्यास या बदसूरत एएसपीनेट वेबफॉर्म घटक नहीं (एएसपी पुनरावर्तक और इसी तरह)।
मैं एएसपीएनटी एमवीसी दुनिया से हूं, मुझे खुशी और आजादी याद है जब मैंने "एएसपीनेट वेबफॉर्म" से "एएसपीएनटी एमवीसी" में स्विच किया, एएसपी जैसे कोई और अजीब घटक नहीं
कृपया, ब्लेज़र को एक नया "एएसपीनेट वेबफॉर्म" न बनने दें।

मैं @GoranHalvarsson से सहमत , एक ही उपयोग के मामले के साथ (पहला उदाहरण @etmendz पोस्ट में)।

उसके लिए, मैंने अपनी शाखा को अद्यतन किया है, अब विजुअल स्टूडियो (पैरा और अनुमत बच्चे) में इंटेलिजेंस के लिए पूर्ण समर्थन के साथ।

क्या कोई मुझे कुछ प्रतिक्रिया दे सकता है?

@GoranHalvarsson मैं सहमत हूँ। एमवीपी ब्लेज़र घटकों के लिए मूल टेम्पलेट समर्थन के लिए हो सकता है। इस अर्थ में, एक "टेम्पलेट" में HTML, घटक, सामग्री और रेजर कोड हो सकते हैं। अपने सबसे बुनियादी रूप में, Blazor घटक+टेम्प्लेट अभी भी पहचानने योग्य HTML+Razor कोड होने चाहिए। घोषणात्मक वाक्यविन्यास इस बिल में फिट बैठता है, जो उदाहरण के लिए <Template> या @template कीवर्ड हो सकता है।

एक अगले चरण की वस्तु ब्लेज़र की एपीआई/एक्सटेंसिबिलिटी लाइब्रेरी हो सकती है जो घटक निर्माताओं को अपने ब्रांड को बढ़ावा देने में सक्षम बनाती है - उदाहरण: एचटीएमएल हेल्पर-जैसे सिंटैक्स (प्रोग्रेस टेलीरिक/केंडो यूआई) या ज़ैमरिन/एक्सएएमएल-जैसे सिंटैक्स (ooui.wasm, Platform .Uno) इसके बजाय तृतीय पक्ष/विक्रेता-स्तर की डिलीवरी हो सकती है। Blazor के भीतर, विशिष्ट मुद्दों/आवश्यकताओं/आवश्यकताओं को संबोधित करने के लिए घटक निर्माता भागीदारों के साथ मिलकर टेम्पलेट प्रोग्रामयोग्यता और संकलन लचीलेपन पर काम किया जा सकता है।

पुन: उपयोग करने योग्य टेम्पलेट्स के बारे में इस धागे में एक सुझाव है। पुन: उपयोग करने योग्य टेम्प्लेट या "नामित टेम्प्लेट" कोड के पुन: उपयोग को बढ़ावा दे सकते हैं। हालांकि, ईमानदारी से, मुझे इसमें बहुत अधिक मूल्य नहीं दिख रहा है और कम प्राथमिकता हो सकती है। अधिक संभावना है, यदि यह पुन: उपयोग के लिए है, तो शायद यह एक घटक होना चाहिए? ;-)

@uazo IMHO, आपके उदाहरणों के आधार पर, <Template> करना <Template> टैग के अंदर सीधे पैरामीटर/मान का उपयोग करने की घोषणात्मक प्रकृति को हराने लगता है।

मुझे घटकों को एकाधिक टेम्पलेट गुणों का समर्थन करने देने के बारे में भी संदेह है। इस मायने में, इसे बहुत फ्रीस्टाइल बनाना। मुझे लगता है कि ब्लेज़र के पास घटक टेम्पलेट्स का समर्थन करने का एक सरल और अधिक मानक तरीका होना चाहिए, शायद ITemplate इंटरफ़ेस के माध्यम से और कुछ कंपाइलर यहां और वहां ट्वीक करते हैं।

@SteveSandersonMS https://github.com/aspnet/Blazor/issues/404#issuecomment -377229910 के लिए
aspnet/AspNetCore#15829 कोड के साथ होगा

MyListWithHeader.cshtml

<strong i="10">@functions</strong>
{
    [Parameter]
    public RenderFragment Title { get; set; }

// NOT MANDATORY
    [Parameter]
    public RenderFragment ChildContent { get; set; }
// *******************

    [Parameter]
    public IEnumerable<example.Person> RowItems { get; set; }

    [Parameter]
    public RenderFragment<example.Person> RowTemplate { get; set; }
}

<div>
    <strong i="11">@Title</strong>
</div>

<strong i="12">@foreach</strong> (var item in RowItems)
{
    <div>
    @RowTemplate.Render(item)
    </div>
}

<strong i="13">@ChildContent</strong>

example.cshtml

<strong i="17">@page</strong> "/component-test"

<MyListWithHeader RowItems=@People>
    <MyListWithHeader.Title>
        Here I'm still in the outer context so can reference properties on the component itself
        such as <strong i="18">@TitleText</strong>
    </MyListWithHeader.Title>

    <MyListWithHeader.RowTemplate WithParams="item">
        <!-- Somehow need intellisense to know that RowTemplate is meaningful here, and that its "item" value is taken from the generic type arg on the RowItems property -->
        Here I'm in the context of an Action RenderTreeBuilder, Person
        because we supplied
        an IEnumerable Person as the value for RowItems, so I can write <b>@item.FirstName</b>
    </MyListWithHeader.RowTemplate>
</MyListWithHeader>

<strong i="19">@functions</strong>
{
  string TitleText { get; set; }
  IEnumerable<Person> People { get; set; }

  protected override void OnInit()
  {
      var people = new List<Person>();
      people.Add(new Person { FirstName = "uno" });
      people.Add(new Person { FirstName = "due" });
      people.Add(new Person { FirstName = "tre" });

      this.People = people;
  }

  public class Person
  {
      public string FirstName { get; set; }
  }
}

इंटेलिजेंस के लिए पूर्ण समर्थन के साथ!

@uazo बहुत बहुत अच्छा! केवल एक ही चीज़ है: WithParams="item" हटा दें और टेम्पलेट के 'संदर्भ' तक पहुँचने के लिए केवल @item का उपयोग करें

उहम .. लेकिन अगर item घटक example में पहले से मौजूद है?
चूंकि टेम्पलेट के 'संदर्भ' तक पहुंचने के लिए उपयोग किए जाने वाले चर नाम का पता नहीं लगाया जा सकता है, इसलिए WithParams , डेवलपर्स चर का नाम तय कर सकते हैं।

क्या आप एक वायर्ड डिफ़ॉल्ट नाम (जैसे ChildContent ) के बारे में सोच रहे हैं, वैकल्पिक WithParams साथ या बिना? या <MyListWithHeader.RowTemplate WithParams=@item> जैसे सिंटेक्स?

पीछे मुड़कर देखें, तो नेस्टेड टेम्प्लेट के लिए एक डिफ़ॉल्ट नाम ठीक नहीं होगा...

चलो सोचते है। टेम्पलेट एक पैरामीटर के साथ कोड जनरेशन है। टेम्पलेट के पास केवल इस आइटम तक पहुंच है। तो अगर हम एक चर item 'आरक्षित' करते हैं - यह सुरक्षित है और संघर्ष नहीं कर सकता है। नेस्टेड टेम्प्लेट का अपना दायरा होता है और @item का उपयोग करना अभी भी सुरक्षित है।

BTW, इस टेम्पलेट की तरह दिखता है- scope के पास अपना @functions ब्लॉक भी होना चाहिए

चलो करते है

<MyListWithHeader RowItems=@People>
    <MyListWithHeader.Title>
        ...<strong i="6">@TitleText</strong>
    </MyListWithHeader.Title>

    <MyListWithHeader.RowTemplate WithParams="item">
        ... <b>@item.FirstName</b>

        <MyListWithHeader>
            <MyListWithHeader.RowTemplate WithParams="item">
                @item.FirstName
            </MyListWithHeader.RowTemplate>
        </MyListWithHeader>

    </MyListWithHeader.RowTemplate>
</MyListWithHeader>

के रूप में प्रस्तुतकर्ता होगा

protected override void BuildRenderTree(Microsoft.AspNetCore.Blazor.RenderTree.RenderTreeBuilder builder)
{
    base.BuildRenderTree(builder);
    builder.OpenComponent<StandaloneApp.Pages.testtemplated.MyListWithHeader>(0);
    builder.AddAttribute(1, "RowItems", Microsoft.AspNetCore.Blazor.Components.RuntimeHelpers.TypeCheck<System.Collections.Generic.IEnumerable<StandaloneApp.Pages.testtemplated.example.Person>>(People));
    builder.AddAttribute(2, "Title", (Microsoft.AspNetCore.Blazor.RenderFragment)((builder2) => {
        builder2.AddContent(3, "\n        Here I\'m still in the outer context so can reference properties on the component itself\n        such as ");
        builder2.AddContent(4, TitleText);
        builder2.AddContent(5, "\n    ");
    }
    ));
    builder.AddAttribute(6, "RowTemplate", (Microsoft.AspNetCore.Blazor.RenderFragment<StandaloneApp.Pages.testtemplated.example.Person>)((builder2, item) => {
        builder2.AddContent(7, "\n        ");
        builder2.AddContent(8, "\n        Here I\'m in the context of an Action RenderTreeBuilder, Person\n        because we supplied\n        an IEnumerable Person as the value for RowItems, so I can write ");
        builder2.OpenElement(9, "b");
        builder2.AddContent(10, item.FirstName);
        builder2.CloseElement();
        builder2.AddContent(11, "\n\n        ");
        builder2.OpenComponent<StandaloneApp.Pages.testtemplated.MyListWithHeader>(12);
// line 43
        builder2.AddAttribute(13, "RowTemplate", (Microsoft.AspNetCore.Blazor.RenderFragment<StandaloneApp.Pages.testtemplated.example.Person>)((builder3, item) => {
            builder3.AddContent(14, "\n                ");
            builder3.AddContent(15, item.FirstName);
            builder3.AddContent(16, "\n            ");
        }
        ));
        builder2.CloseComponent();
        builder2.AddContent(17, "\n\n    ");
    }
    ));
    builder.CloseComponent();
}

साथ

Error   CS0136  A local or parameter named 'item' cannot be declared in this scope because that name is used in an enclosing local scope to define a local or parameter

StandaloneApp\obj\Debug\netstandard2.0\Pages\testtemplated\example.g.cs line 43

हां, निश्चित रूप से, आपको इसे कोडजेन के दौरान हल करना होगा।
लेकिन ... मुझे लगता है कि टेम्पलेट एक करने के लिए संकलित किया जाना है component के बजाय (संभवतः एक विशेष घटक) RenderFragment हम अपने राज्य के साथ StateHasChanged आह्वान करने के लिए उदाहरण के लिए, का प्रबंधन करने की जरूरत है क्योंकि () जब @item.FirstName बदलता रहता है।

हां, निश्चित रूप से, आपको इसे कोडजेन के दौरान हल करना होगा।

मुझे नहीं लगता कि यह संभव है।
कोडजन के दौरान (जो कि रेज़र संशोधित है) सभी नोड्स पार हो गए हैं, कुछ एचटीएमएल हैं, अन्य सी # नोड हैं: सी # वाले लोग गलत होंगे क्योंकि चर परिभाषित नहीं किए जाएंगे और इसलिए परिवर्तनीय प्रकार ज्ञात नहीं होगा (और हमें पुनर्प्राप्त करने की आवश्यकता है प्रकार का एक चर T का RenderFragment<T> , क्योंकि हम जानते हैं T ) ... इसलिए मुझे नहीं पता कि उपयोग किए जाने वाले चर का नाम क्या है।
आप शायद उस अपरिभाषित चर की तलाश कर सकते हैं, लेकिन यह एक गड़बड़ लगता है

लेकिन... मुझे लगता है कि टेम्पलेट को रेंडरफ्रैगमेंट के बजाय एक घटक (संभवतः एक विशेष घटक) में संकलित किया जाना चाहिए क्योंकि हमें इसके राज्य के साथ प्रबंधन करने की आवश्यकता है, उदाहरण के लिए StateHasChanged() जब @item.FirstName उत्परिवर्तित होता है।

मुझे नहीं लगता कि किसी और चीज का परिचय देना जरूरी है।
यदि आपको एक घटक की आवश्यकता है तो BlazorComponent , यदि आपको "टेम्पलेट संपत्ति" की आवश्यकता है तो RenderFragment<T>
आखिरकार, RenderFragment के लिए StateHasChanged() अंतर्निहित घटक के StateHasChanged() द्वारा लागू किया जाता है, मुझे किसी अन्य तरीके से परिवर्तनों को लागू करने की आवश्यकता नहीं है

यहाँ बात करने के लिए क्षमा करें क्योंकि यह एक अच्छी बातचीत की तरह लगता है - लेकिन -

क्या इसे डेटा संदर्भ अवधारणा जैसे डब्ल्यूपीएफ/यूडब्ल्यूपी के साथ हल नहीं किया जाएगा? फिर अपने टेम्पलेट में आप हमेशा this.DataContext.[Member] संदर्भ देंगे।

@ पीटर0302 मुझे व्यक्तिगत रूप से यह विचार पसंद है ...

चुनौती दृढ़ता से टाइप की जा रही है। बेशक इसे एक्सएएमएल में रन टाइम पर बाध्यकारी द्वारा संबोधित किया जाता है। यहां डेटा टेम्प्लेट को शायद जेनरिक के माध्यम से टाइपिंग का समर्थन करना होगा। लेकिन निश्चित रूप से करने योग्य।

तो फिर मैं पूरी तरह से गतिशील रनटाइम बाध्यकारी तंत्र का भी समर्थन करता हूं।

आप किसी भी तरह घोषणा के माध्यम से डेटा प्रकार बताने के लिए जा सकते हैं। एक्सएएमएल पर कुछ हद तक x:DataType समान, हालांकि इसका उल्लेख करना अधिक आदर्श और त्रुटियों से कम प्रवण होना चाहिए।

@uazo मेरी प्रतिक्रिया यह है कि यह बहुत अच्छा लग रहा है! यहाँ मेरे विचार हैं ...

१) यह कि RenderFragment प्रकार की संपत्ति को टैग में किसी संपत्ति के योग्य नाम के साथ असाइन किया गया है जैसे <MyListWithHeader.Title /> मुझे ठीक लगता है, लेकिन हैंडलिंग मेरे पूर्व अंतर्ज्ञान को तोड़ देती है कि ParameterAttribute वाले गुण सेट हैं html-विशेषताओं के माध्यम से। उस व्यवहार को अलग करने के लिए उन गुणों के लिए एक और सी # -विशेषता रखने के बारे में कैसे? [ContentParameter] ?

2) यह कि RenderFragment<Person> प्रकार की एक संपत्ति को विशेषताओं के साथ एक संपत्ति टैग के साथ सौंपा गया है
<MyListWithHeader.RowTemplate WithParams="item" /> पहले तो थोड़ा अजीब लगा। यह एक विशेषता नहीं है जो एक पैरामीटर संपत्ति सेट कर रही है, लेकिन यह है कि उस टेम्पलेट के लिए कोड जनरेशन लोकल के दौरान लैम्ब्डा एक्सप्रेशन में किस चर नाम का उपयोग करना है। यहां फिर से अंतर बताने के लिए एक और वाक्यविन्यास होना अच्छा होगा। लेकिन मैं अनिश्चित हूं कि टूलिंग और कंपाइलर के अनुरूप होने के लिए कोई कितना रचनात्मक हो सकता है। <MyListWithHeader.RowTemplate params(item) /> शायद?

3) अगर मैं <MyListWithHeader RowItems=<strong i="16">@PeopleOnline</strong> /> और <MyListWithHeader RowItems=<strong i="18">@PeopleOffline</strong> /> दिखाना चाहता हूं, तो क्या मुझे फिर से टेम्प्लेट निर्दिष्ट करने होंगे? क्या उनका पुन: उपयोग करने का कोई तरीका है? मैं सोच रहा था कि शायद इस तंत्र के माध्यम से कुछ मॉडल-संचालित प्रारंभिकरण, संपादक के समान ही समान टेम्पलेट्स का उपयोग करके विभिन्न संपत्ति-चयनकर्ताओं के साथ।

जब मैं ढांचे में नया हूं तो कार्यान्वयन पर चर्चा करना थोड़ा जोखिम भरा हो सकता है लेकिन…

यदि आप ऊपर दिए गए बिंदु 1 के तहत चर्चा किए गए टेम्पलेट्स को निर्दिष्ट करने के लिए एक अलग पैरामीटर विशेषता के साथ जाते हैं, तो आप यह कहने के लिए एक बूलियन ध्वज (डिफ़ॉल्ट सत्य) जोड़ सकते हैं कि क्या कोई डिफ़ॉल्ट मान (यदि स्पष्ट रूप से नहीं दिया गया है) लागू किया जाना चाहिए। फिर आप ऊपर दिए गए बिंदु 3 को IDefaultTemplateProvider जैसे इंटरफ़ेस के साथ हल कर सकते हैं जिसका उपयोग कोई भी टेम्प्लेट-प्रॉपर्टी-टैग के लिए अलग से परिभाषाएँ प्रदान करने के लिए कर सकता है। फिर उन्हें प्रतिबिंब के माध्यम से उसी तरह खोजा जा सकता है जैसे आप आईकंपोनेंट (ओं) को खोजते हैं और उन मामलों में उनका उपयोग करते हैं जहां उपयोग-डिफ़ॉल्ट ध्वज सेट होता है, और उपयोगकर्ता एक प्रदान नहीं करता है। आप इंटरफ़ेस को लागू करने वाले कई टेम्प्लेट घटकों को अनुमति दे सकते हैं, लेकिन अगर कोई प्रॉपर्टी टैग कई बार मिलता है तो एक स्पष्ट अपवाद फेंक दें। इस तरह आप किसी ऐप के लिए विशिष्ट सामान्य घटक को मानकीकृत टेम्पलेट प्रदान कर सकते हैं जो कई बार उपयोग किए जाते हैं और डिज़ाइन-समय पर संकल्प प्राप्त करते हैं, शायद?

मुझे लगता है कि इसके आसपास मेरे सीखने के अनुभव का वर्णन करने से आपको एक अच्छी पृष्ठभूमि मिलती है…, और मेरे पास चर्चा करने के लिए कुछ विचार हैं…

मैं स्थिर अनुवादित पाठ, सत्यापन और इसी तरह की पुनर्प्राप्ति के लिए मेटा-डेटा और संसाधन फ़ाइलों के माध्यम से घटकों का मॉडल-संचालित कॉन्फ़िगरेशन बनाना चाहता हूं। मैं सोच रहा था कि टेम्पलेटिंग का यह तंत्र ऐसा करने की चीज हो सकता है। इसका मूल्यांकन करने के लिए मैंने एक इंटरफ़ेस public interface IRenderFragment<T> { RenderFragment UsingDataItem(T item); } बनाया और एक साधारण घटक बनाया जो उस इंटरफ़ेस को टेम्पलेट के रूप में उपयोग करने के लिए भी लागू करता है। फिर इस तरह इसका उपयोग करके एक सामान्य घटक बनाया

  <InputField For=@DataSource(Model, x => x.NewTodo) Template="@InputBasic.Template" />

तो, इस तरह से InputField घटक में मेटा-डेटा आदि को पुनः प्राप्त करने के बारे में जानकारी होती है और इसे आपके द्वारा प्रदान किए गए टेम्पलेट में प्रस्तुत किए गए मॉडल में फीड कर सकते हैं। ये अच्छी तरह काम करता है।

एक्सएएमएल में चीजों को प्रस्तुत करने का एकमात्र तंत्र है जब किसी घटक में आसपास के व्यवहार को लागू किया जाता है, जैसे सूची-दृश्य में आपको एक आइटम-टेम्पलेट प्रदान करने की आवश्यकता होती है। Blazor में यह आवश्यक नहीं है क्योंकि आप इसके बजाय उस आसपास के व्यवहार के लिए लूप के साथ कोड का उपयोग कर सकते हैं। तब मुझे एहसास हुआ कि मैं यहाँ भी ऐसा ही कर सकता था। मैं इसके बजाय कोड में मेटा-डेटा से एक मॉडल पुनर्प्राप्त कर सकता था और उसे सामान्य घटक में फ़ीड कर सकता था। @{ var inputModel = InputModelHelper.GetFor(ViewModel, x => x.NewTodo); } <InputBasic DataItem="@inputModel"/>

शायद कुछ के लिए स्पष्ट ... इसलिए मेरे उपयोग-मामले के लिए टेम्पलेट्स वास्तव में बिल्कुल जरूरी नहीं हैं। लेकिन इसने मुझसे सवाल किया कि मैं वास्तव में क्या चाहता हूं। हो सकता है कि यह मौजूदा तत्वों में विशेषताओं और सामग्री को इंजेक्ट करने की तर्ज पर अधिक हो? और शायद एक कस्टम विशेषता को परिभाषित करने में सक्षम होने के कारण ऐसा कर रहे हैं जैसे:

  <label For=”@DataSource(Model, x => x.NewTodo)”></label>
  <input For=”@DataSource(Model, x => x.NewTodo)” />

यह जांचने के लिए कि क्या किसी मौजूदा तत्व में विशेषता नोड्स जोड़ना संभव है, मैंने खुले टैग <label>@For(x => x.NewTodo)</label> बाद एक फ़ंक्शन (उस सामग्री नोड के लिए खाली स्ट्रिंग देता है) बनाया है जो विशेषता नोड्स (और एक सामग्री) जोड़कर प्रतिपादन प्रक्रिया को बढ़ाता है लेबल तत्व के मामले में नोड) बिल्डर को। (बिल्डर को BuildRenderTree विधि में कैप्चर किया गया था।) बिल्डर के पास लेबल नोड की स्थिति होती है, इसलिए कोई आसानी से इसके बफर में देख सकता है कि क्या कोई विशेषता सेट की गई है और इस तंत्र द्वारा ओवरराइड नहीं किया जाना चाहिए। यह वास्तव में काम करता है। इनपुट तत्व के लिए यह थोड़ा कठिन है क्योंकि यह एक शून्य तत्व है (इसे फिर से खोलने की आवश्यकता है और फ़ंक्शन को विशेषताओं के बीच नहीं रखा जा सकता है), लेकिन अवधारणा के सबूत के रूप में यह काम करता प्रतीत होता है। कोई इसे कैसे समर्थित कर सकता है और क्या इसका कोई मतलब है?

मुझे लगता है कि यह रेंडर निरंतरता/विस्तार समारोह कई स्थानों पर लगाया जा सकता है। आपको सोचने के लिए ... शायद "RenderElementExtensionHandler" इंजेक्ट करने की क्षमता है और यदि किसी घटक में ऐसी संपत्ति है तो उस पर कॉल को उस स्थिति में संकलित किया जाता है जब सभी विशेषताओं को जोड़ा गया हो और उन तत्वों पर जेनरेट कोड में बंद होने के बाद कस्टम हो विशेषताएँ, जैसे For इस मामले में।
क्या यह ऐसा कुछ है जिसका उपयोग अन्य सामानों के लिए किया जा सकता है या यह एक किनारे का मामला है? क्या मौजूदा तत्वों के व्यवहार को विस्तारित करने के अन्य विचार हैं?

क्षमा करें अगर यह थोड़ा लंबा हो गया …

सहारा क्यों नहीं देते?

<List RenderHeader={(text) => (<h4>{text}</h4>)}>
    {({ item, index }) => (
        <li value={index} class={item.Type}>
            {item.Content}
        </li>)}
</List>

किया हुआ:
b2c8b1aec98e65054c590d356fdf15e6a5e6a822
409026c2f41926d85d18ea2abf345453fa083e34
ce11f517d370b501433a62a56fbd4be1704000ad