यह खोज समस्या Ember.js में ग्लिमर घटकों के कार्यान्वयन को ट्रैक करती है।

योजना

Glimmer.js घटकों में निम्नलिखित विशेषताएं हैं:

1. "बाहरी HTML" टेम्प्लेट (कोई tagName , attributeBindings , आदि)
2. टेम्प्लेट में तर्क @ पहले से लगे होते हैं, जैसे {{@firstName}}
3. घटक पर तर्क this.args रूप में सेट किए गए हैं
4. घटक वर्ग जावास्क्रिप्ट वर्ग सिंटैक्स का उपयोग करते हैं
5. परिवर्तनीय घटक स्थिति @tracked गुणों के साथ एनोटेट की गई है
6. घटकों को <AngleBracket /> सिंटैक्स के माध्यम से लागू किया जाता है
7. गुणों को …attributes माध्यम से "विभाजित" किया जा सकता है

एम्बर की वृद्धिशीलता की भावना को ध्यान में रखते हुए, हम इस कार्यक्षमता टुकड़े को एक एडऑन के माध्यम से टुकड़े-टुकड़े करना चाहते हैं। यह समुदाय को सुविधाओं का उपयोग शुरू करने और प्रक्रिया में जल्दी प्रतिक्रिया प्रदान करने की अनुमति देता है।

वास्तव में, हमने पहले ही एम्बर में ग्लिमर घटकों के लिए सड़क शुरू कर दी है। पहली दो विशेषताएं पहले ही उतरना शुरू हो चुकी हैं:

1. केवल-टेम्पलेट घटकों में, टेम्प्लेट "बाहरी HTML" होते हैं ( template-only-glimmer-components वैकल्पिक सुविधा को सक्षम किया गया है।)
2. टेम्पलेट में @ उपसर्ग (जैसे {{@firstName}} ) के माध्यम से तर्कों तक पहुँचा जा सकता है।

यह मुद्दा वैकल्पिक घटक कार्यान्वयन प्रदान करने के लिए एडॉन्स को अनुमति देकर ग्लिमर घटकों को एम्बर में लाने की प्रक्रिया को समाप्त करने का प्रस्ताव करता है, फिर @glimmer/component पैकेज को एम्बर एडऑन में परिवर्तित करता है जो ग्लिमर.जेएस घटक एपीआई को लागू करता है।

हम उस काम को चरणों में तोड़ देंगे, हर एक मौजूदा एम्बर ऐप्स और एडऑन के लिए लाभ अनलॉक कर रहा है। चरण 0 वैकल्पिक घटक कार्यान्वयन का समर्थन करने के लिए आवश्यक आदिम को Ember.js में जोड़ने के बारे में है। चरण 1, 2 और 3 Glimmer.js घटक API को क्रमिक रूप से सक्षम करने के बारे में हैं।

जबकि हम चरण 0 और 1 की गहराई में जाते हैं, हम बाद के चरणों के तकनीकी विवरणों की खोज को तब तक के लिए टाल देंगे जब तक कि पहले चरण पूरा होने के करीब न हों।

चरण 0: घटक व्यवहार को अनुकूलित करना

TL; DR: Addons को कस्टम कंपोनेंट API लागू करने की अनुमति देने के लिए Ember.js में CustomComponentManager API जोड़ें।

वर्तमान में, एम्बर ऐप के सभी घटकों को Ember.Component उपवर्ग माना जाता है। एम्बर में वैकल्पिक घटक एपीआई का समर्थन करने के लिए, हमें एम्बर को यह बताने का कोई तरीका चाहिए कि घटक व्यवहार कब और कैसे बदलना चाहिए।

जब हम "कस्टम घटक व्यवहार" कहते हैं, तो हमारा विशेष रूप से मतलब होता है:

1. घटक उदाहरण कैसे बनाए जाते हैं।
2. घटक उदाहरण कैसे नष्ट हो जाते हैं।
3. घटक उदाहरण के लिए तर्क कैसे प्रदान किए जाते हैं।
4. इन जीवनचक्र परिवर्तनों के बारे में घटक को कैसे सूचित किया जाता है।

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

इसके बजाय, हम CustomComponentManager नामक एक नया एम्बर एपीआई प्रस्तावित करते हैं जो एक प्रतिनिधि पैटर्न को लागू करता है। CustomComponentManager पूर्ण विकसित ComponentManager ग्लिमर वीएम एपीआई की तुलना में एक छोटा एपीआई सतह क्षेत्र प्रदान करता है, जो एडऑन लेखकों को "सफलता के गड्ढे" में गिरने की अनुमति देता है।

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

ComponentDefinition दृष्टिकोण के प्रमुख लाभों में से एक यह है कि घटक प्रबंधक संकल्प निर्माण समय पर हो सकता है। दुर्भाग्य से, इसका मतलब है कि हमें एक एपीआई डिजाइन करना होगा कि ये कैसे पंजीकृत होते हैं, और संभावित रूप से बिल्ड पाइपलाइन के साथ किसी प्रकार का एकीकरण होता है।

इसके बजाय, हम घटक वर्ग पर एनोटेशन के माध्यम से एक घटक के प्रबंधक को रनटाइम पर सेट करने के लिए एक एपीआई का प्रस्ताव करते हैं। यह वृद्धिशील कदम कस्टम घटक प्रबंधकों पर काम जारी रखने की अनुमति देता है जबकि एक दीर्घकालिक समाधान तैयार किया गया है।

कस्टम घटक प्रबंधक डिस्कवरी

इस पुनरावृत्ति में, घटकों को वैकल्पिक घटक प्रबंधकों के लिए स्पष्ट रूप से ऑप्ट-इन करना होगा। वे एम्बर द्वारा निर्यात किए गए एक विशेष componentManager फ़ंक्शन के माध्यम से ऐसा करते हैं, जो रनटाइम पर एनोटेट करता है कि किसी विशेष घटक वर्ग के लिए कौन से घटक प्रबंधक का उपयोग किया जाना चाहिए:

import { componentManager } from '@ember/custom-component-manager';
import EmberObject from '@ember/object';

export default componentManager(EmberObject.extend({
  // ...
}), 'glimmer');

आखिरकार, यह क्लास डेकोरेटर बन सकता है:

import { componentManager } from '@ember/custom-component-manager';

export default @componentManager('glimmer') class {
  // ...
}

पहली बार इस घटक को लागू किया जाता है, एम्बर यह देखने के लिए कक्षा का निरीक्षण करता है कि क्या इसमें एक कस्टम घटक प्रबंधक एनोटेशन है। यदि ऐसा है, तो यह कंटेनर पर लुकअप करने के लिए स्ट्रिंग मान का उपयोग करता है। ऊपर के उदाहरण में, एम्बर कंटेनर कुंजी के साथ ऑब्जेक्ट के लिए कंटेनर से पूछेगा component-manager:glimmer ।

इस प्रकार Addons कस्टम घटक प्रबंधक प्रदान करने के लिए सामान्य रिज़ॉल्यूशन शब्दार्थ का उपयोग कर सकते हैं। हमारा ग्लिमर कंपोनेंट एडऑन addon/component-managers/glimmer.js से एक कंपोनेंट मैनेजर को एक्सपोर्ट कर सकता है जो सामान्य रिज़ॉल्यूशन नियमों के माध्यम से स्वचालित रूप से खोजा जाएगा।

हालांकि यह एपीआई वर्बोज़ है और विशेष रूप से एर्गोनोमिक नहीं है, ऐप्स और एडॉन्स एनोटेशन के साथ अपने स्वयं के बेस क्लास को पेश करके इसे दूर कर सकते हैं। उदाहरण के लिए, यदि turbo-component नामक एक ऐडऑन एक कस्टम घटक प्रबंधक प्रदान करना चाहता है, तो वह इस तरह एक बेस क्लास निर्यात कर सकता है:

// addon/index.js
import EmberObject from '@ember/object';
import { componentManager } from '@ember/custom-component-manager';

export default componentManager(EmberObject.extend({
  // ...
}), 'turbo');

इस ऐडऑन के उपयोगकर्ता सही घटक प्रबंधक का उपयोग करने वाले घटकों को परिभाषित करने के लिए TurboComponent आधार वर्ग को उपवर्गित कर सकते हैं:

import TurboComponent from 'turbo-component';

export default TurboComponent.extend({
  didInsertElementQuickly() {
    // ...
  }
});

कस्टम घटक API

कोई भी घटक द्वीप नहीं है, और पश्चगामी संगतता कारणों से, यह महत्वपूर्ण है कि नए घटक API की शुरूआत मौजूदा घटकों को भंग न करे।

इसका एक उदाहरण मौजूदा दृश्य पदानुक्रम API है। एम्बर घटक parentView संपत्ति के माध्यम से अपने मूल घटक का निरीक्षण कर सकते हैं। यहां तक ​​​​कि अगर माता-पिता Ember.Component , तो बच्चे के एम्बर घटकों में अभी भी एक गैर-शून्य parentView संपत्ति होनी चाहिए।

वर्तमान में, एम्बर में CurlyComponentManager इस स्थिति को बनाए रखने के लिए जिम्मेदार है, साथ ही अन्य परिवेश "स्कोप स्टेट" जैसे कार्यों का लक्ष्य।

मौजूदा सिस्टम में खराब तरीके से लागू किए गए घटक प्रबंधकों को इनवेरिएंट का उल्लंघन करने से रोकने के लिए, हम अंतर्निहित एपीआई के तेज कोनों को छिपाते हुए व्यवहार को अनुकूलित करने के लिए एक संरचना पैटर्न का उपयोग करते हैं।

import CustomComponentManager from "@ember/custom-component-manager";

export default new CustomComponentManager({
  // major and minor Ember version this manager targets
  version: "3.1",
  create({ ComponentClass, args }) {
    // Responsible for instantiating the component class and passing provided
    // component arguments.
    // The value returned here is passed as `component` in the below hooks.
  },
  getContext(component) {
    // Returns the object that serves as the root scope of the component template.
    // Most implementations should return `component`, so the component's properties
    // are looked up in curly expressions.
  },
  update(component, args) {
    // Called whenever the arguments to a component change.
  },
  destroy(component) {
  }
});

चरण 1: एम्बर ऑब्जेक्ट ग्लिमर घटक

एम्बर में Component बेस क्लास सुविधाओं की एक लंबी सूची का समर्थन करता है, जिनमें से कई अब भारी उपयोग नहीं किए जाते हैं। ये सुविधाएँ अप्रयुक्त होने पर भी प्रदर्शन लागत लगा सकती हैं।

पहले चरण के रूप में, हम @glimmer/component पैकेज के माध्यम से सरलीकृत Glimmer.js घटक API में ऑप्ट इन करने का एक तरीका प्रदान करना चाहते हैं। माइग्रेशन को आसान बनाने के लिए, हम ग्लिमर Component बेस क्लास का कार्यान्वयन प्रदान करेंगे जो Ember.Object से @glimmer/component/compat पर इनहेरिट होता है।

"एम्बर-ग्लिमर घटक" कैसा दिखता है इसका एक उदाहरण यहां दिया गया है:

// src/ui/components/user-profile/component.js
import Component from '@glimmer/component/compat';
import { computed } from '@ember/object';

export default Component({
  fullName: computed('args.firstName', 'args.lastName', function() {
    let { firstName, lastName } = this.args
    return `${firstName} ${lastName}`;
  })

  isAdmin: false,

  toggleAdmin() {
    this.set('isAdmin', !this.isAdmin);
  }
});

{{!-- src/ui/components/user-profile/template.hbs --}}
<h1>{{fullName}}</h1>
<p>
  Welcome back, {{@firstName}}!
  {{#if isAdmin}}
    <strong>You are an admin.</strong>
  {{/if}}
</p>
<button {{action toggleAdmin}}>Toggle Admin Status</button>

इन घटकों की उल्लेखनीय विशेषताएं:

• टेम्प्लेट बाहरी HTML हैं । चूंकि ऊपर दिए गए उदाहरण टेम्पलेट में एक भी मूल तत्व नहीं है, इसलिए यह "टैग रहित घटक" के रूप में प्रस्तुत होता है।
• क्रियाएं घटक पर actions हैश में नेस्टेड होने की आवश्यकता नहीं है।
• घटक पर अलग-अलग गुणों को सीधे सेट करने के बजाय args संपत्ति पर तर्क सेट किए जाते हैं।
• वे एम्बर ऑब्जेक्ट मॉडल का उपयोग करते हैं । इसका मतलब है कि गणना किए गए गुण और मिश्रण जैसे उपकरण जो एम्बर डेवलपर्स पहले से ही काम करना जारी रखते हैं।

उतना ही महत्वपूर्ण है जो शामिल नहीं है :

• चरण 3 तक @tracked गुण समर्थित नहीं होंगे।
• घटक पर कोई layout या template गुण नहीं हैं।
• दृश्य पदानुक्रम से संबंधित कोई विधि या गुण नहीं है, जैसे childViews , parentView , nearestWithProperty , आदि।
• मूल तत्व को संशोधित करने के लिए कोई tagName , attributeBindings , या अन्य कस्टम JavaScript DSL नहीं।
• ईवेंट भेजने के लिए कोई send या sendAction ।
• कोई अनिवार्य ember-view क्लास या ऑटो-जेनरेटेड गाइड एलिमेंट आईडी नहीं।
• कोई मैन्युअल rerender() विधि नहीं।
• कोई attrs संपत्ति नहीं (इसके बजाय args उपयोग करें)।
• पारित तर्क "यूनिडायरेक्शनल" हैं और दो-तरफा बाइंडिंग नहीं बनाते हैं।
• हार्ड-टू-डीबग नामकरण टकराव की संभावना से बचने के लिए, पारित तर्कों को घटक उदाहरण पर गुणों के रूप में सेट नहीं किया जाता है।
• घटक तत्व के लिए jQuery ऑब्जेक्ट बनाने के लिए कोई this.$() ।
• DOM में कोई मैन्युअल appendTo घटकों का नहीं।
• निम्नलिखित जीवनचक्र घटनाओं के लिए कोई समर्थन नहीं:
  
  
  
  • willInsertElement
  
  
  • didRender
  
  
  • willRender
  
  
  • willClearRender
  
  
  • willUpdate
  
  
  • didReceiveAttrs
  
  
  • didUpdateAttrs
  
  
  • parentViewDidChange
  
  
• घटक जीवनचक्र की घटनाओं के लिए कोई on() ईवेंट श्रोता नहीं; हुक को विधियों के रूप में लागू किया जाना चाहिए।

सुविधाओं के इस सेट का एक दिलचस्प साइड इफेक्ट यह है कि यह जावास्क्रिप्ट कक्षाओं को ES Classes RFC में प्रस्तावित डिज़ाइन के संयोजन के साथ, हम उपरोक्त घटक का एक वैकल्पिक कार्यान्वयन प्रदान कर सकते हैं:

// src/ui/components/user-profile/component.js
import Component from '@glimmer/component/compat';
import { computed } from 'ember-decorators/object';

export default class extends Component {
  isAdmin = false;

  @computed('args.firstName', 'args.lastName')
  get fullName() {
    let { firstName, lastName } = this.args;
    return `${firstName} ${lastName}`;
  })

  toggleAdmin() {
    this.set('isAdmin', !this.isAdmin);
  }
});

चरण 2 - कोण ब्रैकेट सिंटैक्स

चरण 2 कर्ली ( {{my-component user=currentUser}} ) के अलावा कोण कोष्ठक ( <UserAvatar @user={{currentUser}} /> ) के माध्यम से घटकों को लागू करने में सक्षम बनाता है। चूंकि यह सिंटैक्स घटक तर्कों और HTML विशेषताओं के बीच स्पष्ट नहीं है, इसलिए यह सुविधा …attributes माध्यम से घटक टेम्पलेट में "स्प्लैटिंग" पारित विशेषताओं को भी सक्षम बनाती है।

{{! src/ui/components/UserAvatar/template.hbs }}
<div ...attributes> {{! <-- attributes will be inserted here }}
  <h1>Hello, {{@firstName}}!</h1>
</div>

<UserAvatar @user={{currentUser}} aria-expanded={{isExpanded}} />

यह निम्न के समान आउटपुट प्रस्तुत करेगा:

<div aria-expanded="true">
  <h1>Hello, Steven!</h1>
</div>

चरण 3 - ट्रैक किए गए गुण

चरण 3 एम्बर में @tracked डेकोरेटर के माध्यम से ट्रैक की गई संपत्तियों को सक्षम करता है। एम्बर के ऑब्जेक्ट मॉडल और ट्रैक की गई संपत्तियों के बीच इंटरऑप के विवरण पर काम किया जा रहा है। एक बार संपत्तियों पर नज़र रखने के बाद, उपयोगकर्ता @glimmer/component/compat मॉड्यूल को छोड़ने और सामान्य, गैर-Ember.Object घटक आधार वर्ग का उपयोग करने में सक्षम होंगे।

हाल ही में मर्ज की गई "ऑटोट्रैक" सुविधा (जो स्वचालित रूप से गणना की गई संपत्ति निर्भरता का अनुमान लगाती है) के साथ मिलकर, इसके परिणामस्वरूप एप्लिकेशन कोड का और सरलीकरण होना चाहिए:

import Component, { tracked } from '@glimmer/component';

export default class extends Component {
  <strong i="24">@tracked</strong> isAdmin = false;

  <strong i="25">@tracked</strong> get fullName() {
    let { firstName, lastName } = this.args;
    return `${firstName} ${lastName}`;
  }

  toggleAdmin() {
    this.isAdmin = !this.isAdmin;
  }
}

प्रश्नोत्तर:

क्या मैं मौजूदा सीएसएस के साथ संगतता के लिए ग्लिमर घटकों में ember-view वर्ग नाम या ऑटो-जेनरेटेड id विशेषता जैसी चीजें वापस जोड़ सकता हूं?

हां। उदाहरण:

<div class="ember-view" id="{{uniqueId}}">
  Component content goes here.
</div>

import Component from '@glimmer/component';
import { guidFor } from '@ember/object/internals';

export default class extends Component {
  get uniqueId() {
    return guidFor(this);
  }
}

साधन

• एम्बर समुदाय पर #st-glimmer-components चैनल स्लैक
  
  
  
  • हम यहां काम का समन्वय कर रहे हैं।
  
  
• कस्टम घटक आरएफसी
• custom-component-manager शाखा
  
  
  
  • Ember.js की इन-प्रोग्रेस शाखा CustomComponentManager एक फीचर फ्लैग के पीछे कार्यान्वयन के साथ
  
  
• tracked शाखा
  
  
  
  • Ember.js की इन-प्रोग्रेस ब्रांच @tracked प्रॉपर्टीज और एम्बर ऑब्जेक्ट्स के बीच इंटरऑप पर काम करती है
  
  

कार्य

चल रहे कार्य को ट्रैक करने के लिए हम नीचे दी गई सूचियों का उपयोग करेंगे। जैसा कि हम कार्यान्वयन के दौरान और अधिक सीखते हैं, हम सूची में आइटम जोड़ेंगे या हटा देंगे।

कस्टम घटक प्रबंधक API

• [x] उपरोक्त परिवर्तनों को दर्शाने के लिए कस्टम घटक RFC अपडेट करें (@chancancode)
  
  
  
  • https://github.com/emberjs/rfcs/pull/213#issuecomment -370494713
  
  
• [x] glimmer-custom-component-manager फीचर फ्लैग जोड़ें
• [x] componentManager फ़ंक्शन लागू करें
  
  
  
  • [x] { componentManager } from '@ember/custom-component-manager' रूप में एक्सपोज़ करें
  
  
• [x] रिज़ॉल्वर को एनोटेट कक्षाओं का पता लगाने की जरूरत है
• [x] रिज़ॉल्वर को निर्दिष्ट घटक प्रबंधक को देखने की आवश्यकता है
  
  
  
  • [ ] एडऑन लेखकों के लिए मार्गदर्शन कि घटक प्रबंधकों को कहां रखा जाए ताकि उन्हें खोजा जा सके
  
  
  • [ ] यह मॉड्यूल एकीकरण के साथ कैसे काम करता है? (@मिक्सोनिक)
  
  
• [x] CustomComponentManager एपीआई लागू करें
  
  
  
  • [x] CustomComponentManagerDelegate इंटरफ़ेस को परिभाषित करें
  
  
  • [एक्स] version
  
  
  • [एक्स] create()
  
  
  • [एक्स] getContext()
  
  
  • [एक्स] update()
  
  
  • [एक्स] destroy?()
  
  
  • [एक्स] didCreate?()
  
  
  • [एक्स] didUpdate?()
  
  
  • [एक्स] getView?()
  
  
  • [x] निर्माण पर version संपत्ति को मान्य करें
  
  
  • [x] आंतरिक
  
  
  • [x] मौजूदा घटकों में childViews और parentView को सुरक्षित रखें
  
  
  • [ ] प्रदर्शन प्रदान करने के लिए उपकरण
  
  
  • [] एम्बर इंस्पेक्टर के साथ संगतता के लिए साधन
  
  

ग्लिमर कंपोनेंट एडऑन

• [x] sparkles-components एडऑन का उपयोग करके समर्थन
  
  
  
  • [x] एम्बर . से खपत होने पर बेस क्लास को आयात करना चाहिए और componentManager एनोटेशन जोड़ना चाहिए
  
  
  • [x] CustomComponentManager कार्यान्वयन एम्बर के कंटेनर के माध्यम से खोजने योग्य होना चाहिए
  
  
• [ ] एम्बर एडऑन के रूप में @glimmer/component का उपयोग करके समर्थन करें
  
  
  
  • [ ] Glimmer.js . से उपभोग किए जाने पर मौजूदा व्यवहार को सुरक्षित रखें
  
  
  • [ ] import Component from '@glimmer/component' सादा जावास्क्रिप्ट बेस क्लास प्रदान करता है
  
  
  • [ ] import Component from '@glimmer/component/compat' Ember.Object आधार वर्ग प्रदान करता है
    
    खोजें
  
  
• [] जीवनचक्र हुक
  
  
  
  • [x] स्थिर create(injections)
  
  
  • [एक्स] didInsertElement()
  
  
  • [एक्स] willDestroy()
  
  
  • [एक्स] didUpdate()
  
  
  • [x] इवेंट डेलिगेशन-आह्वान विधियों ( click() आदि) को ट्रिगर नहीं किया जाना चाहिए
  
  
• [ ] एलिमेंट एक्सेस
  
  
  
  • [ ] this.bounds
  
  
  • [ ] this.element परिकलित संपत्ति उपनाम this.bounds
  
  
  • [] तत्वों को उजागर करने के लिए तत्व संशोधक-आधारित एपीआई
  
  
• [ ] तर्क
  
  
  
  • [x] this.args कंस्ट्रक्टर में उपलब्ध है
  
  
  • [x] this.args को didUpdate कहे जाने से पहले अपडेट किया जाता है
  
  
  • [ ] this.args एक अनंत पुन: प्रस्तुत चक्र को ट्रिगर नहीं करना चाहिए (सत्यापित करने की आवश्यकता है)
  
  
• [ ] दस्तावेज़ीकरण
  
  
  
  • [ ] स्थापित करने के लिए कैसे
  
  
  • [ ] चेतावनी
  
  
  • [ ] कैनरी-ओनली
  
  
  • [] प्री-1.0
  
  
  • [ ] एम्बर-ग्लिमर "कॉम्पेट" घटक
  
  
  • [ ] बाहरी HTML टेम्प्लेट
  
  
  • [] जीवनचक्र हुक
  
  
  • [ ] परिकलित गुणों को परिभाषित करना
    
    
    
    
    
    • [ ] args पर कैसे निर्भर रहें
    
    
    
  
  
  • [ ] माइग्रेशन गाइड / ग्लिमर कंपोनेंट्स के लिए…
  
  
  • अन्य पुस्तकालयों से परिचित लोगों के लिए प्रभावी ग्लिमर घटकों को लिखने के लिए मार्गदर्शिका
  
  
  • [ ] एम्बर डेवलपर्स के लिए ग्लिमर कंपोनेंट्स
  
  
  • [ ] रिएक्ट डेवलपर्स के लिए ग्लिमर कंपोनेंट्स
  
  
  • [ ] कोणीय डेवलपर्स के लिए ग्लिमर घटक
  
  
  • [ ] COBOL डेवलपर्स के लिए ग्लिमर कंपोनेंट्स
  
  

प्रश्न खोलें

1. कार्यों के लिए सर्वोत्तम अभ्यास क्या हैं? क्या यह कुछ ऐसा है जो हमें घटक प्रबंधकों को हुक करने की अनुमति देने की आवश्यकता है?
2. आप घटक वर्गों के रूप में नंगे जावास्क्रिप्ट वर्गों (जिनके पास कोई स्थिर create() विधि नहीं है) का उपयोग कैसे करते हैं? एक घटक को प्रारंभ करने के लिए प्रोटोकॉल सरल लगता है लेकिन आश्चर्यजनक रूप से मुश्किल है।
3. CustomComponentManager जैसे "ऐडऑन एपीआई" को दस्तावेज करने के लिए सबसे अच्छी जगह कहां है?
4. हम CustomComponentManager वर्जनिंग को कैसे हैंडल करते हैं?