संक्रमण की लागत को कम करने का एक तरीका यह होगा कि एडऑन को सांख्यिकीय रूप से संकेत देने की अनुमति दी जाए कि उनके कौन से तर्क घटक के कॉलर द्वारा पारित एक स्थिर स्ट्रिंग से मेल खाते हैं।

एक स्पिटबॉल के रूप में (जहां better-component स्थिर घटक कीवर्ड के नाम के लिए एक प्लेसहोल्डर है)।

{{better-component <strong i="8">@arg</strong> staticString=true}}

इससे एडऑन को संकेत मिलता है कि एक विशेष "डायनेमिक इनवोकेशन" केवल तभी काम करता है जब कॉलर स्टैटिक स्ट्रिंग की आपूर्ति करता है।

हमें केवल यह करना चाहिए यदि बहुत सारे गतिशील घटक मामले व्यवहार में हैं, सीधे स्ट्रेट-फॉरवर्ड "स्ट्रिंग लॉजिक टू एऑनोन" के कारण होता है।

Idk अगर यह इस मुद्दे के लिए विषय पर है, लेकिन मैं समय-समय पर emberclear पर पूरी तरह से स्थैतिकता का पता लगाने की कोशिश कर रहा हूं, और मुद्दों और उनके समाधानों का एक पेपर ट्रेल रख रहा हूं।

https://github.com/NullVoxPopuli/emberclear/pull/784

इसलिए, अगर लोग मुद्दों पर भागते हैं, तो शायद अबे प्रलेखन मदद कर सकता है? idk

इसके अलावा, मैं कढ़ाई के लिए सुपर उत्साहित हूं, और पहले से ही बड़ी योजनाएं पूरी तरह से स्थिर होने के बाद हासिल की हैं
https://github.com/emberjs/rfcs/issues/611

हमारे आवेदन एक गतिशील सामग्री वितरण प्रणाली है। सामग्री निर्माता "गतिविधि तत्वों" से सामग्री इकट्ठा करते हैं, जिनमें से प्रत्येक में एक संगत एम्बर घटक होता है, जिसका नाम एम्बर डेटा मॉडल पर परिभाषित किया गया है। इस प्रणाली का दिल कमोबेश ऐसा दिखता है:

// example model definition
export default class TextElement extends Model {
  _componentName = 'text-element';
}

  {{#each (sort-by "position" @activityElements) as |activityElement|}}
    {{component (get activityElement "_componentName")}}

उपरोक्त मेरे पढ़ने से पता चलता है कि यह (component dynamicString) परिदृश्य है। क्या यह सही है?

उपरोक्त मेरे पढ़ने से पता चलता है कि यह एक (घटक डायनामिकस्ट्रिंग) परिदृश्य है। क्या यह सही है?

@activityElements क्या है और इसे कहां परिभाषित किया गया है?

यह एक एम्बर डेटा मॉडल उदाहरण है जो एक नियंत्रक घटक में पारित हो जाएगा।

हमने डायनेमिक कंपोनेंट्स, FYI में भी थोड़ा बहुत निवेश किया है। मैंने इसके बारे में पिछले साल यहां पूछा था: https://discuss.emberjs.com/t/the-perils-of-dynamic-component-invocation/16784।

तो हम करते है। हम शाब्दिक रूप से उन घटकों को नहीं जानते हैं जो पहले से ऐप में उपयोग किए जा रहे हैं। वे एक डेटाबेस में बैठते हैं (जो निश्चित रूप से उन्हें परिवर्तनशील बनाता है), बैकएंड पर संकलित किया जाता है और फ्रंटएंड पर ऑन-डिमांड भेजा जाता है। हमारे लिए डायनेमिक component हेल्पर का उपयोग न कर पाना उसी तरह है जैसे किसी एरे पर प्रत्येक के लिए सक्षम न होना। मैं वास्तव में आशा करता हूं कि इस तरह के मामलों के उपयोग के लिए आगे कोई रास्ता है। मैं निश्चित रूप से कोड बंटवारे / पेड़ के हिलने की परवाह नहीं करता अगर मेरा ऐप काम नहीं करता क्योंकि मेरे पास वह गतिशीलता नहीं है जिसकी मुझे आवश्यकता है।

क्या उस परिदृश्य के लिए सभी वैध घटकों के मानचित्र का उपयोग किया जा सकता है?

उदाहरण के लिए:

{{#let (hash
   Foo=(import 'path/to/foo')
   Etc=...
) as |validComponents|
}}
  {{component (get validComponents @someDynamicValue)}}
{{/let}}

?

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

क्या उस परिदृश्य के लिए सभी वैध घटकों के मानचित्र का उपयोग किया जा सकता है?

यह निश्चित रूप से हमारे उपयोग के मामले को कवर करेगा।

@NullVoxPopuli @jherdman बहुत बढ़िया!

सामान्य तौर पर, लोगों को (component dynamicString) बजाय क्या करने की आवश्यकता होगी, यह सोचने का तरीका है कि उन्हें कहीं जाने के लिए import या (component "staticString") की आवश्यकता है ।

विकल्पों में शामिल हैं:

• घटक का कॉलर (component "staticString")
• गतिशीलता के साथ कोड संभावनाओं की गणना करेगा, उन्हें एक मानचित्र में डाल देगा, और आपको प्राप्त करने के लिए (get componentMap dynamicString) का उपयोग करेगा।

अब आप सोच रहे होंगे: (get components dynamicString) किसी भी (component dynamicString) से बेहतर कैसे हो सकता है? इसका उत्तर यह है कि componentMap का निर्माण कहीं और किया जाना था, और नियम पुनरावर्ती रूप से लागू होते हैं।

तो मान लें कि आप एक घटक लिख रहे हैं, जो आपको <InputField @type="text" /> या <InputField @type="checkbox" /> (जैसे <input> HTML में) लिखने की अनुमति देता है।

input-field लिए आपका टेम्पलेट कुछ इस तरह दिखाई देगा:

{{#let (hash text=(component "inputs/text-field") checkbox=(component "inputs/checkbox")) as |components|}}
  {{component (get components @type)}}
{{/let}}

जब आप इस तरह से कोड लिखते हैं, तो कढ़ाई यह देख सकती है कि इसे बंडल में केवल दो घटकों को शामिल करना है। क्या आपने इसे इस तरह लिखा था:

{{component (concat "inputs/" <strong i="33">@type</strong> "-field")}}

(हां, इस तरह की चीजें आश्चर्यजनक रूप से आम हैं)

फिर एम्ब्रायडर आसानी से कोड का विश्लेषण नहीं कर सकता है और उन घटकों को सीमित कर सकता है जिन्हें बंडल में शामिल किया जाएगा। यह और भी बदतर है यदि आप जावास्क्रिप्ट में काम (जो भी बहुत आम है) किया था:

export default class extends Component {
  get innerComponent() {
    return `inputs/${this.args.type}-field`;
  }
}

इस टेम्पलेट के साथ:

{{component this.innerComponent}}

यह एक छोटा मोड़ है, लेकिन यह कढ़ाई के लिए यह निर्धारित करना संभव बनाता है कि कौन से घटक वास्तव में उपयोग किए जाते हैं।

मैं दो अन्य इन-फ़्लाइट सुविधाओं के कनेक्शनों को अधिक सावधानी से वर्तनी करना चाहता हूं।

1. टेम्पलेट आयात
2. घटक वर्गों को इनवोकबल्स के रूप में उपयोग करना

यदि हम उन दो विशेषताओं का उपयोग करके पिछले उदाहरण को फिर से लिखते हैं, तो ऐसा लगता है:

---
import TextField from "./text-field";
import Checkbox from "./checkbox";
---
{{#let (hash text=TextField checkbox=Checkbox) as |components|}}
  {{component (get components @type)}}
{{/let}}

इसमें एक विशेष नियम को समाप्त करने की अच्छी संपत्ति है जिसे एम्ब्रोइडर्स को समझना होगा, और कोड के लिए उपयोगकर्ता मॉडल को मॉड्यूल से और भी अधिक विभाजित करना होगा।

घटक वर्गों को इनवोकबल्स के रूप में उपयोग करना

RFC # 481 के बाद से, एक घटक वर्ग एक पूरी तरह से आत्म-निहित इकाई है, जिसमें सभी जानकारी है जो एक घटक के रूप में इसे लागू करने के लिए ग्लिमर वीएम के लिए आवश्यक है।

नोट: यह उन वर्गों के बारे में सही नहीं है जो @ember/component या @glimmer/component से वारिस हैं। आरएफसी 481 के बाद से, एम्बर की "घटक" की परिभाषा "एक वस्तु है जो एक टेम्पलेट और घटक प्रबंधक से जुड़ी है", जिसमें हुक-घटकों जैसे कस्टम घटक शामिल

चूंकि RFC # 432 (प्रासंगिक सहायक और संशोधक) और RFC # 496 (हैंडलबार सख्त मोड), एम्बर के टेम्पलेट सिंटैक्स के भविष्य के लिए डिज़ाइन है: सहायक, घटक या संशोधक युक्त अभिव्यक्तियों को सहायक, घटक या संशोधक के रूप में आमंत्रित किया जा सकता है।

स्वीकृत RFC के वर्तमान संग्रह का निहितार्थ यह है कि <SomeComponentClass /> (या <this.componentClass> जहाँ this.componentClass एक घटक वर्ग का समाधान होता है) "बस काम करेगा"। यह कार्यान्वयन कार्य के लिए रिकॉर्ड की योजना भी है।

कहा कि, स्पष्टता के लिए, हमें एक नया RFC बनाना चाहिए जो स्पष्ट रूप से इस व्यवहार को निर्दिष्ट करता है।

एचबीएस में मान्य घटकों की एक सूची निर्दिष्ट करना कहीं न कहीं हमारे लिए उचित है, लेकिन एक युगल को बाहर बुलाए जाने के लायक है:

1. वर्तमान में, हम JS समाधान @wycats को इंगित करते हैं। एक एचबीएस प्रदाता में ऐसा करने योग्य है, लेकिन जैसा कि हम सभी जानते हैं कि एचबीएस में तर्क थोड़ा अधिक कठिन है। यह भी इकाई परीक्षण के लिए _much_ कठिन है कि एक प्रदाता घटक सही फ़ंक्शन का उपयोग करके सही घटक की पैदावार देता है।

2. यह जेएस (सार्वजनिक एपीआई के साथ वैसे भी) अस्तित्व में नहीं है, लेकिन हमारे लाभ के लिए निर्देशिका संरचना का उपयोग करना यहां बहुत अच्छा होगा। उदाहरण के लिए:

   {{#let (lookup-directory "components/inputs/") as |components|}}
   {{/let}}
   

   इस तरह की चीज को समय के साथ बनाए रखना आसान हो सकता है अगर आपको निर्देशिका संरचना द्वारा एक साथ समूहीकृत पॉलीमॉर्फिक प्रकार ज्ञात हो।

किसी भी मामले में, मुझे लगता है कि गतिशील घटकों को इस, feel को लेने के बजाय चर्चा करने के लिए अपने स्वयं के मुद्दे की आवश्यकता है

किसी भी मामले में, मुझे लगता है कि गतिशील घटकों को इस, feel को लेने के बजाय चर्चा करने के लिए अपने स्वयं के मुद्दे की आवश्यकता है

मैं सहमत हूं, और आरएफसी रेपो में शीघ्र ही एक को खोलेंगे, और यहां एक लिंक पोस्ट करेंगे।

@mehulkar @wycats @jherdman क्या उपयोगकर्ताओं को गतिशील रूप से अदृश्य घटकों की अपनी सूची आयात करने की अनुमति देता है? एक सहायक की तुलना में पालन करने के लिए बहुत आसान लगता है जिसमें अप्रत्यक्ष का एक अतिरिक्त स्तर शामिल है।

import Component1 from './dynamic/component-1';
import Component2 from './dynamic/component-2';
import Component3 from './dynamic/component-3';

export default class extends Component {
  get innerComponent() {
    switch(this.args.type) {
      case 'one':
        return Component1;
      case 'two':
        return Component2;
      case 'three':
        return Component3;
      default:
        // handle invalid type
    }
  }
}

तब टेम्पलेट बस कर सकता है: {{#let (component this.innerComponent) as |DynamicComponent|}} या कुछ इसी तरह का।

मैं बहुत कुछ इस तरह से पसंद करूंगा जो कि आसान खोज / रीड / एनालिसिस हो, और आसानी से पता लग सके कि इन घटकों का उपयोग कहां किया जा रहा है। विचार?

@ उत्कृष्ट हाँ मुझे लगता है कि यह विचार है। एचबीएस में सहायक ज्यादातर सिंटैक्टिक शुगर और टेम्पलेट-केवल घटकों के लिए उपयोगी होगा।

@ समसामयिक मूल रूप से जो मैंने निकट-अवधि के निर्धारण (टेम्पलेट आयात से पहले) के रूप में प्रस्तावित किया था।

इसके लिए हमें घटक वर्गों को इनवोकेबल बनाने की अनुमति देनी होगी, जो कि मैं इस टिप्पणी के बारे में बात कर रहा था।

चलो इसे करते हैं!

आह, कि केवल घटक के लिए समझ में आता है, गलत समझ के लिए खेद है :)। मुझे भी केवल घटकों के टेम्पलेट के लिए वाक्यविन्यास पसंद है:

---
import TextField from "./text-field";
import Checkbox from "./checkbox";
---
{{#let (hash text=TextField checkbox=Checkbox) as |components|}}
  {{component (get components @type)}}
{{/let}}

के रूप में अच्छी तरह से, वास्तव में, मैं शायद यह केवल टेम्पलेट और जेएस समर्थित घटकों के लिए उपयोग करता हूं, जो कि टीम के अन्य लोगों के लिए पढ़ना आसान है।