लंबे समय तक पढ़ने के लिए माफ़ी, लेकिन मैं यह सुनिश्चित करना चाहता था कि मैं प्रत्येक विकल्प को अच्छी तरह से तलाश रहा था। मैं अपनी राय के साथ चीजों को बहुत ज्यादा पूर्वाग्रह नहीं करना चाहता, लेकिन अगर मैं चुनने की स्थिति में था, तो मुझे लगता है कि मैं विकल्प 3 के साथ जाऊंगा।

विकल्प 3 पश्चगामी संगत, घोषणात्मक और स्पष्ट है। फ़ॉलबैक ह्युरिस्टिक को बनाए रखने की कोई आवश्यकता नहीं है, और अन्य पुस्तकालय पहले से ही समान सिगिल/संशोधक प्रदान करते हैं।

लंबे समय तक पढ़ने के लिए माफ़ी, लेकिन मैं यह सुनिश्चित करना चाहता था कि मैं प्रत्येक विकल्प को अच्छी तरह से तलाश रहा था। मैं अपनी राय के साथ चीजों को बहुत ज्यादा पूर्वाग्रह नहीं करना चाहता, लेकिन अगर मैं चुनने की स्थिति में था, तो मुझे लगता है कि मैं विकल्प 3 के साथ जाऊंगा।
विकल्प 3 पश्चगामी संगत, घोषणात्मक और स्पष्ट है। फ़ॉलबैक ह्युरिस्टिक को बनाए रखने की कोई आवश्यकता नहीं है, और अन्य पुस्तकालय पहले से ही समान सिगिल/संशोधक प्रदान करते हैं।

मैं विकल्प 2 और विकल्प 3 के बीच हूं, मुझे लगता है कि प्रतिक्रिया ने व्यवहार को संभाला है और एपीआई अतीत में बहुत अच्छी तरह से बदलता है। डॉक्स के लिए चेतावनियां और लिंक पेश करने से डेवलपर्स को यह समझने में मदद मिल सकती है कि हुड के तहत क्या हो रहा है।

विकल्प 3 इसकी घोषणात्मक प्रकृति के कारण आकर्षक दिखता है, JSX कोड को पढ़ते समय नए आने वाले डेवलपर्स को तुरंत पता चल जाएगा कि तत्व को प्रस्तुत करते समय रिएक्ट क्या करेगा।

विकल्प 2 पर टिप्पणियाँ

डेवलपर्स भ्रमित हो सकते हैं जब रिएक्ट किसी संपत्ति के बजाय एक विशेषता सेट करता है, इस पर निर्भर करता है कि उन्होंने अपने तत्व को लोड करने के लिए कैसे चुना है।

क्या कस्टम तत्व के उपभोक्ताओं को इस अंतर को समझने की आवश्यकता है? या यह केवल कस्टम तत्व के लेखक के लिए महत्वपूर्ण है? ऐसा लगता है कि तत्व के लेखक को HTML में उपयोग की जाने वाली किसी भी चीज़ के लिए विशेषताओं को संभालने की आवश्यकता होगी (चूंकि HTML उपयोग से डेटा पास होने का यही एकमात्र तरीका है) और गुण यदि वे जटिल मूल्यों या संपत्ति का समर्थन करना चाहते हैं तो DOM से प्राप्त/सेट करें। यह भी संभव है कि एक लेखक ने शुरू में एक विशेषता के रूप में कुछ लागू किया हो और फिर बाद में अधिक लचीले डेटा प्रकारों का समर्थन करने के लिए उसी नाम के साथ एक संपत्ति जोड़ सके और फिर भी गुणों में संग्रहीत मूल्य के साथ संपत्ति को वापस कर सके।

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

यदि किसी तत्व में एक अपरिभाषित संपत्ति है, और प्रतिक्रिया इसे एक वस्तु/सरणी पास करने का प्रयास कर रही है, तो यह इसे एक संपत्ति के रूप में सेट कर देगी। ऐसा इसलिए है क्योंकि some-attr="[ऑब्जेक्ट ऑब्जेक्ट]" उपयोगी नहीं है।

ऐसा लगता है कि मूल्य के आधार पर अलग-अलग बांधना भ्रमित है। यदि तत्व के लेखक ने मूल्य को संभालने के लिए एक संपत्ति गेटर/सेटर निर्दिष्ट नहीं किया है तो संपत्ति को सेट करने से तत्व ऐसा व्यवहार करेगा जैसे मान कभी निर्दिष्ट नहीं किया गया था जो डीबग करना कठिन हो सकता है।

विकल्प 3 पर टिप्पणियाँ

विकल्प 3 के साथ एक और संभावित नुकसान यह है कि कस्टम तत्व के उपभोक्ता को यह जानने की आवश्यकता है कि तत्व ने संपत्ति के रूप में या विशेषता के रूप में कुछ लागू किया है या नहीं। यदि आप रिएक्ट घटकों और कस्टम तत्वों के मिश्रण का उपयोग कर रहे हैं, तो एक अलग सिंटैक्स का उपयोग करके एक सिंटैक्स और कस्टम तत्व गुणों का उपयोग करके रिएक्ट प्रॉप्स को सेट करना भ्रामक हो सकता है।

क्या कस्टम तत्व के उपभोक्ताओं को इस अंतर को समझने की आवश्यकता है? या यह केवल कस्टम तत्व के लेखक के लिए महत्वपूर्ण है?

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

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

मैं सहमत हूं लेकिन मुझे यकीन नहीं है कि यह कुछ ऐसा है जिसे रिएक्ट को अपने पुस्तकालय में काम करने की कोशिश करने की आवश्यकता है। यह एक ऐसी समस्या की तरह लगता है जिसे कस्टम एलिमेंट स्पेक के हिस्से के रूप में हल करने की आवश्यकता है। मैं देख सकता हूं कि क्या हम आगामी टीपीएसी मानकों की बैठक के हिस्से के रूप में इस पर चर्चा कर सकते हैं।

मुझे जोड़ना चाहिए, गुणों के लिए यह _as_ खराब नहीं है क्योंकि तत्व-परिभाषित संपत्ति HTMLElement में जोड़े गए भविष्य की संपत्ति को छाया देगी। तो यदि आप एक कस्टम तत्व को जेएस प्रॉपर्टी के रूप में डेटा पास कर रहे थे, तो यह काम करना जारी रखेगा। मुख्य मुद्दा विशेषताओं के आसपास लगता है क्योंकि वे वैश्विक हैं।

ऐसा लगता है कि मूल्य के आधार पर अलग-अलग बांधना भ्रमित है। यदि तत्व के लेखक ने मूल्य को संभालने के लिए एक संपत्ति गेटर/सेटर निर्दिष्ट नहीं किया है तो संपत्ति को सेट करने से तत्व ऐसा व्यवहार करेगा जैसे मान कभी निर्दिष्ट नहीं किया गया था जो डीबग करना कठिन हो सकता है।

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

यह सच है कि यदि लेखक मूल्य के लिए गेटटर/सेटर को परिभाषित नहीं करता है तो यह बहुत उपयोगी नहीं होगा। लेकिन my-attr=[object Object] भी उपयोगी नहीं है। और चूंकि आप नहीं जानते कि संपत्ति वास्तव में अपरिभाषित है या यदि वे परिभाषा केवल आलसी लोड हो रही है, तो संपत्ति को सेट करना सबसे सुरक्षित लगता है।

विकल्प 3 के साथ एक और संभावित नुकसान यह है कि कस्टम तत्व के उपभोक्ता को यह जानने की आवश्यकता है कि तत्व ने संपत्ति के रूप में या विशेषता के रूप में कुछ लागू किया है या नहीं।

मुझे लगता है कि आप अनिवार्य रूप से आज एक ही नाव में हैं क्योंकि ऐसा कुछ भी नहीं है जो एक कस्टम तत्व लेखक को संपत्ति के बजाय एक विशेषता को परिभाषित करने के लिए मजबूर करता है। इसलिए मेरे पास केवल एपीआई के गुणों वाला एक तत्व हो सकता है जो रिएक्ट के वर्तमान सिस्टम से कोई डेटा प्राप्त नहीं करेगा और मुझे जेएस गुणों को सीधे सेट करने के लिए ref का उपयोग करने के लिए जानना होगा।

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

[संपादित करें]

जैसा कि आपने अपने पहले बिंदु में कहा था:

ऐसा लगता है कि तत्व के लेखक को HTML में उपयोग की जाने वाली किसी भी चीज़ के लिए विशेषताओं को संभालने की आवश्यकता होगी (चूंकि HTML उपयोग से डेटा पास होने का यही एकमात्र तरीका है) और गुण यदि वे जटिल मूल्यों या संपत्ति का समर्थन करना चाहते हैं तो DOM से प्राप्त/सेट करें।

क्योंकि आप कभी नहीं जानते कि कोई उपयोगकर्ता आपके तत्व को डेटा पास करने का प्रयास कैसे करेगा, फिर भी आपको विशेषता-संपत्ति पत्राचार की आवश्यकता होती है। मुझे लगता है कि अगर विकल्प 3 भेज दिया जाता है कि ज्यादातर लोग @ सिगिल का उपयोग करके सब कुछ बांध देंगे क्योंकि यह सबसे आसान होगा। इस तरह मैं आज Vue में कस्टम तत्वों के साथ काम करता हूं क्योंकि वे .prop संशोधक को उजागर करते हैं।

कस्टम तत्व के उपभोक्ता को यह जानने की आवश्यकता है कि क्या तत्व ने संपत्ति के रूप में या एक विशेषता के रूप में कुछ लागू किया है

ऐसा कुछ नहीं है, प्रतिक्रिया को चिंता करनी चाहिए क्योंकि रॉब ने मेरी राय में कहा, यह कस्टम तत्व लेखक की जिम्मेदारी है कि वह उपयोगकर्ता को यह बताए कि तत्व कैसे काम करता है।

और यह वास्तव में वह तरीका है जिसे हमें आज करने की आवश्यकता है, उदाहरण के लिए <video> तत्व के बारे में सोचें, मान लें कि आपको इसे म्यूट करने या किसी घटक के अंदर वर्तमान समय को बदलने की आवश्यकता है।

muted एक बूलियन विशेषता के रूप में काम करता है

render() {
  return (
    <div className="video--wrapper">
      <video muted={ this.state.muted } />
    </div>
  );
}

वर्तमान समय के लिए आपको वीडियो तत्व की ओर इशारा करते हुए ref बनाना होगा और संपत्ति को बदलना होगा।

render() {
  return (
    <div className="video--wrapper">
      <video ref={ el => this.video = el } muted={ this.state.muted } />
    </div>
  );
}

फिर एक ईवेंट हैंडलर, एक इंस्टेंस विधि बनाएं और संपत्ति को मैन्युअल रूप से DOM तत्व पर सेट करें।

onCurrenTimeChange(e) {
  this.video.currentTime = e.value;
}

यदि आप इसके बारे में सोचते हैं तो यह घोषणात्मक मॉडल को तोड़ देता है, प्रतिक्रिया स्वयं अपने एपीआई और जेएसएक्स अमूर्त परत के साथ लागू होती है क्योंकि currentTime यह स्पष्ट रूप से रैपर घटक में एक राज्य है, संपत्ति बाध्यकारी के साथ हमें अभी भी ईवेंट हैंडलर की आवश्यकता होगी लेकिन JSX एब्स्ट्रैक्शन मॉडल अधिक घोषणात्मक होगा और इसके लिए केवल refs आवश्यक नहीं होंगे:

render() {
  return (
    <div className="video--wrapper">
      <video muted={ this.state.muted } @currentTime={ this.state.currentTime } />
    </div>
  );
}

मेरा मुद्दा यह है कि चाहे आप देशी या कस्टम तत्वों पर भरोसा कर रहे हों, फिर भी आपको दस्तावेज़ीकरण के आधार पर उनके आसपास अपना रास्ता जानने की जरूरत है, अंतर यह है कि दूसरे मामले में यह कस्टम तत्व के लेखक से आना चाहिए।

@cjorasch मेरे दो सेंट :)

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

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

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

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

शायद मैं अपग्रेड प्रक्रिया को नहीं समझता। तत्वों में आमतौर पर क्लास प्रोटोटाइप में गेटर्स/सेटर्स के रूप में परिभाषित गुण होते हैं। propName in element जांच गेटटर/सेटर के अस्तित्व के कारण सत्य वापस आ जाएगी, भले ही संपत्ति मूल्य अभी भी अपरिभाषित था। अपग्रेड के दौरान क्या संपत्ति मूल्य कुछ अस्थायी उदाहरण पर सेट हो जाते हैं और बाद में आलसी लोड पूरा होने के बाद वास्तविक उदाहरण में कॉपी हो जाते हैं?

उन्नयन वह प्रक्रिया है जिसके द्वारा कस्टम तत्व अपनी कक्षा प्राप्त करता है। इससे पहले, यह उस वर्ग का उदाहरण नहीं है, इसलिए संपत्ति प्राप्त करने वाले/सेटर उपलब्ध नहीं हैं।

@jeremenichelli

म्यूट एक बूलियन विशेषता के रूप में काम करता है

अभी जाँच की गई है और इसकी एक संबंधित संपत्ति भी है, हालांकि यह MDN पर प्रलेखित नहीं प्रतीत होता है: P

वर्तमान समय के लिए आपको वीडियो तत्व की ओर इशारा करते हुए एक रेफरी बनाने और संपत्ति को बदलने की जरूरत है।

हाँ कभी-कभी आपको आधुनिक HTML तत्वों पर गुण-केवल API का सामना करना पड़ेगा। currentTime उच्च आवृत्ति पर अपडेट होते हैं, इसलिए इसे HTML विशेषता में प्रतिबिंबित करने का कोई मतलब नहीं होगा।

मेरा कहना यह है कि जिस मौसम में आप देशी या कस्टम तत्वों पर भरोसा कर रहे हैं, आपको अभी भी दस्तावेज़ीकरण के आधार पर उनके आसपास अपना रास्ता जानने की जरूरत है

हां दुर्भाग्य से कोई एक आकार-फिट-सभी गुण/गुण नियम नहीं है। लेकिन मुझे लगता है कि आम तौर पर बोलते हुए आप गुणों पर भारी पड़ सकते हैं और वाक्यविन्यास प्रदान कर सकते हैं ताकि डेवलपर्स विशेष मामलों में विशेषताओं का उपयोग कर सकें।

@robdodson हाँ , मैं म्यूट संपत्ति के बारे में भी जानता था 😄 मैंने इन दोनों का उपयोग यह साबित करने के लिए किया था कि पहले से ही _in the wild_ एक आकार-फिट-सभी नियम नहीं है जैसा आपने उल्लेख किया है।

हमें मूल और कस्टम दोनों तत्वों पर दस्तावेज़ीकरण पर भरोसा करना होगा, इसलिए यह कुछ ऐसा है जिसे मैं इस निर्णय के लिए बुरा नहीं मानूंगा।

आखिरी कोड स्निपेट लिखते समय मुझे संपत्ति बाध्यकारी पसंद आई, हालांकि

@effulgentsia

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

मुझे लगता है कि यह पहले से ही आज मामला है। चूंकि प्रमुख कस्टम तत्व पुस्तकालय (बहुलक, स्केट, संभवतः अन्य?) स्वचालित रूप से सभी उजागर विशेषताओं के लिए बैकिंग गुण बनाते हैं, डेवलपर्स केवल कस्टम तत्व पर प्रत्येक संपत्ति के लिए सिगिल का उपयोग कर सकते हैं। उनके लिए एक विशेषता का उपयोग करने के लिए स्विच करने की आवश्यकता शायद एक दुर्लभ घटना होगी।

@cjorasch

आरई: अपग्रेड। जैसा कि @effulgentsia ने उल्लेख किया है, पृष्ठ पर एक कस्टम तत्व होना संभव है लेकिन बाद में इसकी परिभाषा लोड करें। <x-foo> शुरू में HTMLElement का एक उदाहरण होगा और जब मैं इसकी परिभाषा को बाद में लोड करता हूं तो यह "अपग्रेड" होता है और XFoo वर्ग का उदाहरण बन जाता है। इस बिंदु पर इसके सभी जीवनचक्र कॉलबैक निष्पादित हो जाते हैं। हम इस तकनीक का उपयोग पॉलिमर स्टार्टर किट परियोजना में करते हैं। इस प्रकार है:

<app-router>
  <my-view1></my-view1>
  <my-view2></my-view2>
</app-router>

उपरोक्त उदाहरण में, हम my-view2 की परिभाषा को तब तक लोड नहीं करेंगे जब तक कि राउटर उसमें परिवर्तन न कर दे।

किसी प्रॉपर्टी को अपग्रेड करने से पहले उस पर सेट करना पूरी तरह से संभव है, और एक बार परिभाषा लोड हो जाने के बाद तत्व उस डेटा को अपने जीवनचक्र कॉलबैक में से एक के दौरान हड़प सकता है।

डेवलपर्स कस्टम तत्व पर प्रत्येक संपत्ति के लिए केवल सतर्क का उपयोग कर सकते हैं

यदि डेवलपर्स ने ऐसा करना शुरू कर दिया है, तो यह किसी संपत्ति का उपयोग करने में अंतर कैसे करेगा क्योंकि आप किसी संपत्ति का उपयोग करने से "कर सकते हैं" क्योंकि आपको "जरूरी" है? और क्या यह सर्वर-साइड रेंडरिंग के लिए आवश्यक भिन्नता नहीं है?

यदि डेवलपर्स ने ऐसा करना शुरू कर दिया है, तो यह किसी संपत्ति का उपयोग करने में अंतर कैसे करेगा क्योंकि आप किसी संपत्ति का उपयोग करने से "कर सकते हैं" क्योंकि आपको "जरूरी" है?

क्षमा करें, शायद मैंने इसे गलत बताया। मेरा मतलब था कि डेवलपर्स संभवतः सतर्क का उपयोग करेंगे क्योंकि यह सबसे सुसंगत परिणाम देगा। आप इसका उपयोग आदिम डेटा या वस्तुओं और सरणियों जैसे समृद्ध डेटा को पास करने के लिए कर सकते हैं और यह हमेशा काम करेगा। मुझे लगता है कि रनटाइम पर गुणों के साथ काम करना आमतौर पर विशेषताओं के साथ काम करना पसंद किया जाता है क्योंकि प्रारंभिक कॉन्फ़िगरेशन के लिए विशेषताओं का अधिक उपयोग किया जाता है।

और क्या यह सर्वर-साइड रेंडरिंग के लिए आवश्यक भिन्नता नहीं है?

ऐसा हो सकता है कि सर्वर पर सिगिल एक विशेषता सेट करने के लिए वापस आ जाए।

ऐसा हो सकता है कि सर्वर पर सिगिल एक विशेषता सेट करने के लिए वापस आ जाए।

मुझे नहीं लगता कि यह काम करेगा यदि सतर्क का कारण यह है कि यह एक ऐसी संपत्ति है जो एक विशेषता के रूप में मौजूद नहीं है, जैसे कि वीडियो का currentTime ।

एक संपत्ति का उपयोग करके अंतर करें क्योंकि आप संपत्ति का उपयोग करने से "कर सकते हैं" क्योंकि आपको "जरूरी"

मुझे लगता है कि यह भेदभाव महत्वपूर्ण है, क्योंकि एक विशेषता या संपत्ति को अनुकूलन के रूप में उपयोग करने के लिए चुनने के लिए पूरी तरह से अलग कारण हैं (उदाहरण के लिए, एसएसआर पसंद करने वाले गुण बनाम क्लाइंट-साइड प्रतिपादन पसंद करने वाले गुण) बनाम कुछ ऐसा जो या तो केवल एक विशेषता के रूप में मौजूद है या केवल सम्पत्ति।

सर्वर-साइड रेंडरिंग के संबंध में, क्या उस समस्या को एप्लिकेशन कोड के लिए एपीआई प्रदान करके हल किया जा सकता है ताकि रिएक्ट को सूचित किया जा सके कि विशेषताओं के लिए कस्टम तत्व गुणों को कैसे मैप किया जाए?

अधिक विशिष्ट होने के लिए, मैं कुछ इस तरह का सुझाव दे रहा हूं:

ReactDOM.defineCustomElementProp(elementName, propName, domPropertyName, htmlAttributeName, attributeSerializer)

उदाहरण:

// 'muted' can be set as either a property or an attribute.
ReactDOM.defineCustomElementProp('x-foo', 'muted', 'muted', 'muted')

// 'currentTime' can only be set as a property.
ReactDOM.defineCustomElementProp('x-foo', 'currentTime', 'currentTime', null)

// 'my-attribute' can only be set as an attribute.
ReactDOM.defineCustomElementProp('x-foo', 'my-attribute', null, 'my-attribute')

// 'richData' can be set as either a property or an attribute.
// When setting as an attribute, set it as a JSON string rather than "[object Object]".
ReactDOM.defineCustomElementProp('x-foo', 'richData', 'richData', 'richdata', JSON.stringify)

किसी ऐसी चीज़ के लिए जो केवल एक संपत्ति हो सकती है (जहां htmlAttributeName शून्य है), SSR इसे रेंडर करना छोड़ देगा और फिर इसे क्लाइंट पर हाइड्रेट करेगा।

किसी ऐसी चीज़ के लिए जो केवल एक विशेषता हो सकती है (जहां domPropertyName शून्य है), रिएक्ट setAttribute() को वर्तमान में v16.

किसी ऐसी चीज के लिए जो दोनों हो सकती है, रिएक्ट चुन सकता है कि कौन सी रणनीति सबसे इष्टतम है। शायद इसका मतलब है कि हमेशा क्लाइंट-साइड पर एक संपत्ति के रूप में सेट करना, लेकिन एक विशेषता सर्वर-साइड के रूप में। शायद इसका मतलब है कि शुरुआत में तत्व बनाते समय एक विशेषता के रूप में सेट करना, लेकिन बाद में vdom से पैचिंग करते समय एक संपत्ति के रूप में सेट करना। शायद इसका मतलब केवल एक विशेषता के रूप में सेट करना है जब मान एक आदिम प्रकार है। आदर्श रूप से, जब भी वह आंतरिक कार्यान्वयन विवरण के रूप में चाहे तो प्रतिक्रिया रणनीति को बदलने में सक्षम होना चाहिए।

जब रिएक्ट एक ऐसे प्रोप का सामना करता है जिसके लिए defineCustomElementProp() को कॉल नहीं किया गया है और जिसे HTML स्पेक द्वारा वैश्विक संपत्ति या विशेषता के रूप में परिभाषित नहीं किया गया है, तो रिएक्ट कुछ डिफ़ॉल्ट तर्क को लागू कर सकता है। उदाहरण के लिए, शायद:

• संस्करण 17 में, BC को v16 के साथ बनाए रखें और एक विशेषता के रूप में सेट करें।
• संस्करण 18 में, मान लें कि यह या तो हो सकता है और उसके लिए सबसे इष्टतम रणनीति का पालन करें।

लेकिन किसी भी स्थिति में, इसे एक अलग एपीआई रखकर, JSX और props वस्तुओं को साफ और एक ही नाम स्थान के भीतर रखा जाता है, जैसे वे रिएक्ट घटकों और गैर-कस्टम HTML तत्वों के लिए हैं।

अत्यधिक टिप्पणियों के लिए खेद है, लेकिन मैंने ऊपर अपने प्रस्ताव के लिए एक और लाभ के बारे में सोचा जिसे मैं साझा करना चाहता हूं:

उन ReactDOM.defineCustomElementProp() कॉल कस्टम तत्व लेखक द्वारा बनाए गए जेएस फ़ाइल में प्रदान किए जा सकते हैं (उसी भंडार में जहां कस्टम तत्व बनाए रखा/वितरित किया जाता है)। संपत्ति/विशेषता के सख्त 1:1 पत्राचार वाले कस्टम तत्वों के लिए इसकी आवश्यकता नहीं होगी, जो इस मुद्दे के पृष्ठभूमि विवरण के अनुसार वैसे भी सिफारिश और बहुमत का मामला है। इसलिए केवल कस्टम तत्व लेखकों को इस अनुशंसा का पालन नहीं करने के लिए प्रतिक्रिया एकीकरण फ़ाइल प्रदान करने की आवश्यकता होगी। यदि लेखक इसे प्रदान नहीं करता है (उदाहरण के लिए, क्योंकि कस्टम तत्व लेखक प्रतिक्रिया के बारे में परवाह नहीं करता है), तो उन लोगों का समुदाय जो उस कस्टम तत्व का उपयोग रिएक्ट ऐप्स के भीतर करते हैं, उस एकीकरण फ़ाइल के आवास के लिए केंद्रीय भंडार को स्वयं व्यवस्थित कर सकते हैं।

मुझे लगता है कि इस तरह के केंद्रीकरण की संभावना एक ऐसे समाधान के लिए बेहतर है जिसके लिए कस्टम तत्व के प्रत्येक उपयोगकर्ता को हमेशा एक सतर्क के साथ स्पष्ट होना चाहिए।

विकल्प 3 मेरा पसंदीदा होगा लेकिन यह एक बहुत बड़ा ब्रेकिंग बदलाव है... उलटा क्या होगा? विशेषताएँ एक उपसर्ग है सहारा नहीं?

प्रतिक्रिया में सिगिल, मुझे नहीं पता कि मैं इसके बारे में कैसा महसूस करता हूं। JSX युक्ति को सार्वभौमिक माना जाना चाहिए, न कि अत्यधिक निर्भर या ब्राउज़र की बारीकियों पर निर्भर, विशेष रूप से पिछड़े संगतता के कारण अनियमितताओं पर नहीं। obj[prop] = value और obj.setAttributes(props, value) अलग व्यवहार करना दुर्भाग्यपूर्ण है लेकिन पूरी तरह से ब्राउज़र एपीआई को देखकर आश्चर्य की बात नहीं है। @ : [] सतह पर कार्यान्वयन विवरण लीक कर देगा और जावास्क्रिप्ट केंद्रित दृष्टिकोण का खंडन करेगा। इसलिए जब तक हमारे पास एक युक्ति नहीं है जो निम्नलिखित करता है, मुझे लगता है कि यह एक बुरा विचार है: const data = <strong i="8">@myFunction</strong> // -> "[object Object]"

अगर मुझे एक वेब घटक पर भरोसा करना है, तो मुझे खुशी होगी अगर शब्दार्थ को रिएक्ट और JSX से दूर छिपाया जाए और साथ ही यह सुनिश्चित किया जाए कि वे ब्रेकिंग परिवर्तन नहीं पेश करते हैं। सभी विकल्पों में से, ref => ... को जगह पर छोड़ना मेरे लिए अनुकूल प्रतीत होता है। ref को विशेष रूप से ऑब्जेक्ट तक पहुंचने के लिए डिज़ाइन किया गया है। और कम से कम डेवलपर जानता है कि वास्तव में क्या हो रहा है, कोई सतर्क-रिसाव नहीं है, न ही नई विशेषताएं जो मौजूदा परियोजनाओं को तोड़ सकती हैं।

@लीचेनेलर

विकल्प 3 मेरा पसंदीदा होगा लेकिन यह एक बहुत बड़ा ब्रेकिंग बदलाव है... उलटा क्या होगा? विशेषताएँ एक उपसर्ग है सहारा नहीं?

यह एक तोड़ने वाला बदलाव क्यों होगा? डिफ़ॉल्ट होने के कारण विशेषताओं का वर्तमान व्यवहार बना रहेगा। सिगिल ऑप्ट-इन होगा और डेवलपर्स इसका उपयोग अपने कोड में स्पॉट को बदलने के लिए करेंगे जहां वे वर्तमान में जेएस प्रॉपर्टी के रूप में कस्टम तत्व को डेटा पास करने के लिए ref का उपयोग करते हैं।

@drcmda

न तो नई विशेषताएँ जो मौजूदा परियोजनाओं को तोड़ सकती हैं।

क्या आप स्पष्ट कर सकते हैं कि आपका इससे क्या मतलब था?

एफवाईआई चर्चा के बाद किसी के लिए भी, मैंने आरएफसी को रिएक्ट टीम के सदस्यों द्वारा सुझाए गए 5 वें विकल्प के साथ अपडेट किया है।

@robdodson

मैं इसका जिक्र कर रहा था:

विकल्प 4: एक विशेषता वस्तु जोड़ें
दोष
यह एक तोड़ने वाला बदलाव हो सकता है

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

पॉलिमर के पेपर-इनपुट तत्व में 37 गुण हैं, इसलिए यह एक बहुत बड़ा कॉन्फिग तैयार करेगा। यदि डेवलपर्स अपने ऐप में बहुत सारे कस्टम तत्वों का उपयोग कर रहे हैं, तो वे बहुत सारे कॉन्फिग के बराबर हो सकते हैं जिन्हें उन्हें लिखने की आवश्यकता होती है।

मेरी धारणा यह है कि प्रतिक्रिया में कस्टम तत्व उपयोगकर्ता अंततः ऐप-विशिष्ट व्यवहार/अनुकूलन के लिए कुछ कस्टम तत्वों को प्रतिक्रिया घटकों में लपेटना चाहते हैं। यदि सब कुछ पहले से ही एक प्रतिक्रिया घटक है, तो यह इस मामले के लिए एक बेहतर प्रवासन रणनीति

import XButton from './XButton';

और जो उत्पन्न होता है

export default ReactDOM.createCustomElementType(...)

यह उन्हें एक कस्टम घटक के साथ एक रिएक्ट घटक को बदलने देता है जो किसी भी समय कस्टम तत्वों का उपयोग करता है (या उपयोग नहीं करता है)।

इसलिए, यदि लोग इंटरऑप बिंदुओं पर रिएक्ट घटक बनाने जा रहे हैं, तो हम ऐसा करने के लिए एक शक्तिशाली सहायक भी प्रदान कर सकते हैं। यह भी संभावना है कि लोग उन कॉन्फ़िगरेशन को उनके द्वारा उपयोग किए जाने वाले कस्टम तत्वों के लिए साझा करेंगे।

और अंत में, यदि हम पारिस्थितिकी तंत्र को स्थिर होते देखते हैं, तो हम एक विन्यास-रहित दृष्टिकोण अपना सकते हैं।

मुझे लगता है कि यहां अगला कदम एक विस्तृत प्रस्ताव लिखना होगा कि सभी सामान्य उपयोग के मामलों को पूरा करने के लिए कॉन्फ़िगरेशन कैसा दिखना चाहिए। यह कस्टम तत्व + प्रतिक्रिया उपयोगकर्ताओं के लिए पर्याप्त रूप से सम्मोहक होना चाहिए, क्योंकि यदि यह सामान्य उपयोग के मामलों (जैसे ईवेंट हैंडलिंग) का उत्तर नहीं देता है, तो हम अधर में लटकने जा रहे हैं जहां सुविधा वर्बोसिटी को ऑफसेट करने के लिए पर्याप्त लाभ प्रदान नहीं करती है .

मेरी पिछली टिप्पणी से निर्माण, कैसे के बारे में:

const XFoo = ReactDOM.createCustomElementType('x-foo', {
  propName1: {
    propertyName: string | null,
    attributeName: string | null,
    attributeSerializer: function | null,
    eventName: string | null,
  }
  propName2: {
  }
  ...
});

XFoo उदाहरण पर प्रत्येक रिएक्ट प्रोप के लिए तर्क तब होगा:

1. यदि उस प्रोप के लिए eventName शून्य नहीं है, तो इसे एक ईवेंट हैंडलर के रूप में पंजीकृत करें जो प्रोप मान (एक फ़ंक्शन माना जाता है) को आमंत्रित करता है।
2. अन्यथा यदि क्लाइंट-साइड रेंडर करना और propertyName शून्य नहीं है, तो एलीमेंट प्रॉपर्टी को प्रोप वैल्यू पर सेट करें।
3. अन्यथा यदि attributeName शून्य नहीं है, तो तत्व विशेषता को कड़े प्रोप मान पर सेट करें। यदि attributeSerializer शून्य नहीं है, तो इसका उपयोग प्रोप वैल्यू को स्ट्रिंग करने के लिए करें। अन्यथा, बस '' + propValue ।

पॉलिमर के पेपर-इनपुट तत्व में 37 गुण हैं, इसलिए यह एक बहुत बड़ा कॉन्फिग तैयार करेगा।

मैं सुझाव देना चाहता हूं कि कॉन्फ़िगरेशन केवल बाहरी प्रोप के लिए आवश्यक हो। XFoo इंस्टेंस पर किसी भी प्रोप के लिए जो कि कॉन्फिग में शामिल नहीं था, इसे इसके लिए डिफ़ॉल्ट करें:

• यदि मान एक फ़ंक्शन है:

eventName: the prop name,

• अन्यथा:

propertyName: the prop name,
attributeName: camelCaseToDashCase(the prop name),

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

<XFoo prop1={propValue1} prop2={propValue2} events={event1: functionFoo, event2: functionBar}>
</XFoo>

@gaearon @effulgentsia आप विकल्प 1 और विकल्प 5 के संयोजन के बारे में क्या सोचते हैं?

विकल्प 1 कस्टम तत्व के आकस्मिक उपयोगकर्ता के लिए समृद्ध डेटा पास करना आसान बना देगा। मैं उस परिदृश्य की कल्पना कर रहा हूं जहां मैं एक ऐप बना रहा हूं और मैं बस कुछ कस्टम तत्वों का उपयोग करना चाहता हूं। मुझे पहले से ही पता है कि वे कैसे काम करते हैं और मैं इतना निवेशित नहीं हूं कि मैं उनके लिए एक कॉन्फ़िगरेशन लिखना चाहता हूं।

विकल्प 5 उन लोगों के लिए होगा जो अपने पूरे ऐप में पेपर-इनपुट जैसी किसी चीज़ का उपयोग करना चाहते हैं और वास्तव में अपनी टीम के सभी लोगों के लिए इसके संपूर्ण एपीआई का खुलासा करना चाहते हैं।

विकल्प 1 के एसएसआर के लिए सर्वर पर प्रतिपादन करते समय अनुमानी हमेशा एक विशेषता का उपयोग कर सकता है। एक कैमलकेस संपत्ति डैश-केस विशेषता में परिवर्तित हो जाती है। यह वेब घटक पुस्तकालयों में एक बहुत ही सामान्य पैटर्न प्रतीत होता है।

मुझे विकल्प 1 + विकल्प 5 संयोजन का विचार बहुत पसंद है। इसका मतलब है कि अधिकांश कस्टम तत्वों के लिए:

<x-foo prop1={propValue1}>

उम्मीद के मुताबिक काम करेगा: प्रॉप1 एक संपत्ति क्लाइंट-साइड के रूप में और एक (डैश-केसेड) विशेषता सर्वर-साइड के रूप में सेट है।

और लोग किसी भी चीज़ के लिए विकल्प 5 पर स्विच कर सकते हैं जिसके लिए उपरोक्त उनके अनुरूप नहीं है।

हालांकि रिएक्ट 16 के काम करने के तरीके से यह एक बड़ा बदलाव होगा। किसी भी व्यक्ति के लिए जो उस टूटने का अनुभव करता है (उदाहरण के लिए, वे विशेषताओं के साथ एक कस्टम तत्व का उपयोग कर रहे थे जो गुणों द्वारा समर्थित नहीं हैं), वे विकल्प 5 पर स्विच कर सकते हैं, लेकिन यह अभी भी एक ब्रेक है। यह स्वीकार्य है या नहीं, यह तय करने के लिए मैं इसे रिएक्ट टीम पर छोड़ता हूं।

आह, ट्रेन में इसे जल्दी से पढ़ने के लिए मुझे यही मिलता है @robdodson 🤦‍♂️ ... वास्तव में अब विकल्प 3 का प्रशंसक नहीं है मैंने इसे प्रीफ़िक्स किए जा रहे सभी प्रॉप्स के रूप में पढ़ा, इसलिए मेरी झिझक।

विकल्प 5 उचित और सीधा लगता है।

मुझे पसंद है जहां @effulgentsia जा रहा है। क्या ऐसा कोई कारण नहीं हो सकता है:

const XFoo = ReactDOM.createCustomElementType('x-foo', {
  propName1: T.Attribute,
  propName2: T.Event,
  propName3: T.Prop
})

या एक ही प्रोप पर कई प्रकारों का समर्थन करना मूल्यवान है?

मैं इस प्रवाह से हिचकिचाऊंगा हालांकि

यदि मान एक फ़ंक्शन है:
इवेंटनाम: प्रोप नाम,
अन्यथा:
संपत्ति का नाम: प्रोप नाम,
विशेषता नाम: कैमलकेस टोडैशकेस (प्रोप नाम),

मुझे नहीं लगता कि मैं किसी ईवेंट के लिए डिफ़ॉल्ट रूप से एक फ़ंक्शन प्रोप चाहता हूं, और संपत्ति नाम और विशेषता नाम दोनों को समझदार बता रहा हूं? आप दोनों को उपरोक्त प्रश्न की नकल करने के लिए कब समर्थन देना चाहेंगे? मैं

@लीचेनेलर :

समस्या सारांश के विकल्प 1 पेशेवरों से उद्धरण:

पॉलिमर या स्केट जैसे पुस्तकालयों के साथ बनाया गया कोई भी तत्व अपनी उजागर विशेषताओं को वापस करने के लिए स्वचालित रूप से गुण उत्पन्न करेगा। इन तत्वों को उपरोक्त दृष्टिकोण के साथ "बस काम" करना चाहिए। डेवलपर्स हाथ से लिखने वाले वेनिला घटकों को गुणों के साथ विशेषताओं को <input> जैसे ऑडबॉल नहीं) HTML5 तत्व ( <video> , <audio> , आदि) क्रियान्वित किया गया है।

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

आपके प्रस्ताव के साथ, यह संभावित रूप से झंडे को मिलाकर किया जा सकता है, जैसे:

propName1: T.Property | T.Attribute,

हालांकि, यह व्यक्त करने का कोई तरीका प्रदान नहीं करेगा कि विशेषता नाम संपत्ति के नाम से अलग है (उदाहरण के लिए, कैमलकेस से डैश-केस)। न ही यह एसएसआर के दौरान एक विशेषता के लिए एक समृद्ध वस्तु को क्रमबद्ध करने के तरीके को व्यक्त करने का एक तरीका प्रदान करेगा ("[ऑब्जेक्ट ऑब्जेक्ट]" का वर्तमान व्यवहार उपयोगी नहीं है)।

मुझे नहीं लगता कि मैं किसी ईवेंट के लिए डिफ़ॉल्ट रूप से एक फ़ंक्शन प्रोप चाहता हूं

हाँ, मुझे लगता है कि मैं भी इससे सहमत हूँ, इसलिए अनुवर्ती टिप्पणी । इसके साथ मेरी झिझक को प्रमाणित करने के लिए धन्यवाद!

मेरे पहले के सुझाव के कम वर्बोज़ संस्करण के लिए यहां एक विचार है:

const XFoo = ReactDOM.createCustomElementType('x-foo', {
  UNREFLECTED_ATTRIBUTES: [
    'my-attr-1',
    'my-attr-2',
  ],
  UNREFLECTED_PROPERTIES: [
    'myProp1',
    'myProp2',
  ],
  REFLECTED_PROPERTIES: {
    // This is default casing conversion, so could be omitted.
    someVeryLongName1: 'some-very-long-name-1',

    // In case anyone is still using all lowercase without dashes.
    someVeryLongName2: 'someverylongname2',

    // When needing to define a function for serializing a property to an attribute.
    someRichData: ['some-rich-data', JSON.stringify],
  },
});

और उपरोक्त कोड टिप्पणी के अनुसार, मैं दृढ़ता से आग्रह करता हूं कि प्रत्येक प्रतिबिंबित संपत्ति को परिभाषित करने की आवश्यकता न हो, बल्कि कुछ भी डिफ़ॉल्ट रूप से परिभाषित नहीं किया जाता है जिसे स्वचालित रूप से एक प्रतिबिंबित संपत्ति के रूप में परिभाषित नहीं किया जाता है जिसका विशेषता नाम डैश-केस संस्करण है।

समझ में आता है @effulgentsia

मुझे आपका दूसरा उदाहरण पसंद है लेकिन क्या यह संयोजन विस्फोट के लिए खुला नहीं है यदि अधिक प्रकार जोड़े जाते हैं, अला घटनाएं + जो कुछ भी समझ में आता है?

- UNREFLECTED_ATTRIBUTES
- UNREFLECTED_PROPERTIES
- UNREFLECTED_EVENTS
- REFLECTED_PROPERTIES_ATTRIBUTES
- REFLECTED_PROPERTIES_EVENTS
- REFLECTED_ATTRIBUTES_EVENTS
- REFLECTED_PROPERTIES_ATTRIBUTES_EVENTS
...

हालांकि मुझे लगता है कि आप किसी घटना को किसी प्रोप या विशेषता के साथ मिश्रित नहीं करना चाहेंगे 🤔 विशेषता और प्रोप शायद केवल वही चीजें हैं जिनकी आप नकल करना चाहते हैं।

मुझे लगता है कि यहां रिएक्ट और वेब कंपोनेंट समुदाय दोनों के लिए एक सर्वोत्तम अभ्यास पर संरेखित करने का अवसर है। प्रतिक्रिया यहाँ एक राय रखने से कस्टम तत्व लेखकों को सही दिशा में निर्देशित किया जा रहा है क्योंकि इसके व्यापक रूप से अपनाने और वजन के कारण इसकी राय है।

हालांकि मैंने विकल्प 4 के कार्यान्वयन को लिखा है, मैं हमेशा गुणों और घटनाओं को गुणों से अलग करने के द्वारा पकड़ा जाता हूं। आदर्श रूप से, मैं विकल्प 1 पसंद करूंगा। व्यावहारिक रूप से, मुझे लगता है कि मैं एस्केप हैच के साथ विकल्प 2 पसंद करूंगा।

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

विकल्प 2 बेहतर है क्योंकि यह एक गैर-तोड़ने वाला परिवर्तन है। यह उन सभी परिस्थितियों के लिए काम करेगा जहां कस्टम तत्व परिभाषा एक उदाहरण बनने से पहले पंजीकृत है (या गुण सेट होने से पहले लोड किया गया है)। इस विकल्प के लिए पूर्व कला Preact (cc @developit) है और इसने अब तक अच्छी तरह से काम किया है। इस पथ पर नीचे जाने से एक यथोचित रूप से मजबूत, गैर-ब्रेकिंग कार्यान्वयन मिलता है जो एक सफल रिएक्ट संस्करण द्वारा सिद्ध किया गया है और यह ज्यादातर स्थितियों में काम करता है। यदि कुछ भी हो, तो यह रिएक्ट को एक अल्पकालिक समाधान देता है जबकि दीर्घावधि के लिए बेहतर समाधानों का मूल्यांकन किया जाता है।

उस स्थिति के लिए (स्थिति s ?) जहां यह काम नहीं करता है - कस्टम तत्व परिभाषाओं की स्थगित लोडिंग और कोई अन्य जिसे हमने कवर नहीं किया है - एक एस्केप हैच जैसे कि वृद्धिशील डोम ने क्या किया जा सकता है। यह वही है जो @effulgentsia प्रस्तावित कर रहा है, लेकिन कस्टम तत्वों की संख्या x लिए बेहतर होगा। यदि उपभोक्ता इसे प्रति-कस्टम-तत्व के आधार पर करना चाहते हैं, तो वे अभी भी कर सकते हैं, क्योंकि यह केवल एक कार्य है। यह रिएक्ट को एक राय रखने, हैच से बचने और सभी एज-केस के लिए उपभोक्ता को जिम्मेदारी सौंपकर सभी उपयोग-मामलों को संतुष्ट करने की अनुमति देता है। यह भी कुछ ऐसा है जिसे मैंने पहले @Developit के साथ Preact में लागू करने के बारे में चर्चा की है। Preact/React के बीच संरेखण यहाँ एक बड़ी जीत होगी।

भविष्य के HTML विशेषताओं के साथ चिंता के बारे में, यह कुछ ऐसा है जिसे हम हल नहीं कर सकते हैं, इसलिए मुझे नहीं लगता कि हमें इसके बारे में यहाँ पर ध्यान देना चाहिए।

उन ReactDOM.defineCustomElementProp() कॉल को कस्टम तत्व लेखक द्वारा बनाए गए JS फ़ाइल में प्रदान किया जा सकता है

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

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

यहां तक ​​​​कि अगर एक पुस्तकालय लेखक प्रतिक्रिया का उपयोग नहीं करता है, तो मैं तर्क दे रहा हूं कि यह उन वेब घटकों के क्लाइंट के लिए एक बेहतर यूएक्स है जो एक बार संपत्ति कॉन्फ़िगरेशन को परिभाषित करता है और फिर इसका उपयोग करता है।

पहली बार जब आप एक वेब घटक का उपयोग करते हैं जिसके लिए एक संपत्ति की आवश्यकता होती है, तो यह एक सिगिल (अधिक वर्बोज़, लेकिन अधिक स्पष्ट) जोड़ने जितना कठिन होता है, लेकिन बाद के उपयोगों के लिए यह आसान होता है क्योंकि आपको इसके बारे में सोचने की आवश्यकता नहीं होती है उस घटक की हर एक कॉलसाइट। किसी भी मामले में आपको एक नया वेब घटक अपनाने के दौरान गुणों/विशेषताओं के अंतर को समझने की आवश्यकता होती है, लेकिन एकल साझा कॉन्फ़िगरेशन के साथ आपको इसके बारे में सोचने के लिए उसी ऐप के भीतर उस घटक के प्रत्येक उपयोगकर्ता की आवश्यकता नहीं होती है।

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

मूल रूप से: यदि लोगों के लिए हर बार किसी घटक का उपयोग करने पर संपत्ति कॉन्फ़िगरेशन के बारे में नहीं सोचना संभव है, तो मैं उस दृष्टिकोण को पसंद करूंगा। इसलिए मैंने विकल्प 5 का सुझाव दिया। मुझे लगता है कि यह समान रूप से लचीला होने के साथ-साथ 3 और 4 की तुलना में अधिक एर्गोनोमिक है।

विकल्प 1 और 2 सर्वर रेंडरिंग (एचटीएमएल पीढ़ी) के साथ बहुत अच्छी तरह से काम नहीं करते हैं, और विकल्प 2 वेब घटक लेखकों के लिए अपग्रेड खतरे भी पैदा करता है जहां अब मौजूदा विशेषता के समान नाम के साथ एक संपत्ति जोड़ना एक ब्रेकिंग परिवर्तन है। यदि हम तय करते हैं कि SSR उपयोगी नहीं है, तो प्रतिक्रिया के दृष्टिकोण से विकल्प 1 बहुत आकर्षक है। मैं परिचित नहीं हूँ अगर यह व्यवहार में पर्याप्त व्यापक होगा - क्या घटक लेखक गुणों के माध्यम से सब कुछ उजागर करते हैं?

bikeshedding में बहुत गहरा हो रही बिना @treshugart, आपको लगता है कि आप दिखा सकते हैं कि कैसे आप काम करने के लिए "अब बचने का" उम्मीद थी हैं? छद्म कोड ठीक है। बस इसलिए हम सब एक ही पृष्ठ पर हैं।

क्षमा करें @sophiebits अभी आपका उत्तर देख रहे हैं। मैं कुछ बिंदुओं को कुछ और बार पढ़ने के बाद उनका जवाब देना चाहता हूं लेकिन इस पर तुरंत प्रतिक्रिया देना चाहता हूं:

मैं परिचित नहीं हूँ अगर यह व्यवहार में पर्याप्त व्यापक होगा - क्या घटक लेखक गुणों के माध्यम से सब कुछ उजागर करते हैं?

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

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

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

हो सकता है कि तब सबसे अच्छा तरीका यह है कि गुण हमेशा क्लाइंट पक्ष पर करें और फिर उन लोगों के लिए नाम विशेषता के लिए आदिम संपत्ति नामों के विकल्प 5-शैली कॉन्फ़िगरेशन मानचित्र का समर्थन करें जो अपने ऐप्स में एसएसआर का समर्थन करना चाहते हैं।

@ सोफीबिट्स : मुझे लगता है कि यह एक अच्छा विचार है, सिवाय इसके कि यह उन लोगों के लिए एक ब्रेकिंग बदलाव है जिन्होंने विशेषता नामों का उपयोग करके अपने रिएक्ट ऐप्स लिखे हैं। उदाहरण के लिए:

<x-foo long-name={val} />

लेकिन "गुण करें" के लिए एक नियम के बारे में क्या है यदि प्रोपनाम में डैश नहीं है और यदि ऐसा होता है तो "विशेषताएं करें"?

@robdodson : क्या आप वहां किसी भी कस्टम तत्व ढांचे या प्रथाओं से अवगत हैं जहां लोगों के पास संबंधित संपत्ति से विशेषताओं के अलग-अलग आवरण होंगे, बिना डैश के? यानी, longname विशेषता के साथ longName संपत्ति? यह वास्तव में अंतर्निहित HTML तत्वों और वैश्विक विशेषताओं (जैसे, contenteditable => contentEditable ) के साथ अधिक सामान्य पैटर्न प्रतीत होता है, लेकिन मैं स्पष्ट नहीं हूं कि क्या यह अब पर्याप्त रूप से हतोत्साहित है कस्टम तत्व विशेषताओं के लिए पॉलिमर और स्केट के लिए धन्यवाद। यदि यह अभी भी एक मुद्दा है, तो मौजूदा JSX के साथ:

<x-foo longname={val} />

संपत्ति सेट के रूप में विफल हो जाएगा यदि संपत्ति longName ।

@effulgentsia मैं केवल स्केट के लिए बोल सकता हूं, लेकिन हम केवल HTML लिखते समय विशेषता API का उपयोग करने की सलाह देते हैं, जो - सभी उद्देश्यों और उद्देश्यों के लिए - सर्वर प्रतिपादन के रूप में भी वर्गीकृत किया जा सकता है। यदि आप JS के माध्यम से कुछ भी कर रहे हैं, तो आपको प्रॉप्स सेट करना चाहिए। हमारा props एपीआई स्वचालित रूप से विशेषताओं से एक-तरफ़ा सिंक / डिसेरिएलाइज़ेशन करता है, और संपत्ति के नाम को डैश-केस करके विशेषता नाम प्राप्त करता है (CamelCase ऊंट-केस बन जाता है, आदि)। यह व्यवहार समग्र रूप से कॉन्फ़िगर करने योग्य है लेकिन हम उपरोक्त सर्वोत्तम अभ्यास को प्रोत्साहित करते हैं।

जैसा कि कई लोगों ने कहा है, प्रॉप्स SSR को कठिन बनाते हैं, और यह एक वैध चिंता का विषय है। चूंकि ऐसा लगता है कि अधिकांश विकल्प 1 को पसंद करेंगे, हो सकता है कि हम फ़ॉलबैक/मैपिंग प्रदान करते हुए क्लाइंट पर प्रॉप्स सेट करने के @sophiebits के प्रस्ताव के साथ प्रयास करें और आगे

एक उदाहरण के लिए, यहां बताया गया है कि आप स्केट के साथ सर्वर से क्लाइंट तक ले जाने की स्थिति और प्रॉप्स को कैसे लागू कर सकते हैं (और कोई भी कस्टम तत्व जो renderedCallback() और props और / या state बसता है। कस्टम तत्व स्तर पर ऐसा करना तुच्छ है। यदि प्रतिक्रिया सर्वर पर विशेषताओं को सेट करने की सड़क से नीचे चली गई, तो पुनर्जलीकरण अनिवार्य रूप से समान होगा। स्केट घटक लेखकों को वास्तव में कुछ भी नहीं करना होगा जैसा कि हम करते हैं ' पहले से ही उनके लिए अक्रमांकन तर्क प्रदान करेगा।

@robdodson मैं

const isBrowser = true; // this would actually do the detection
const oldAttributeHook = ReactDOM.setAttribute;

// This is much like the IDOM impl but with an arguably more clear name.
ReactDOM.setAttribute = (element, name, value) => {
  // This is essentially option 2, but with the added browser check
  // to keep attr sets on the server.
  if (isBrowser && name in element) {
    element[name] = value;
  } else {
    oldAttributeHook(element, name, value);
  }
};

@ सोफीबिट्स

विकल्प 2 वेब घटक लेखकों के लिए अपग्रेड खतरे भी पैदा करता है, जहां अब मौजूदा विशेषता के समान नाम वाली संपत्ति जोड़ना एक महत्वपूर्ण परिवर्तन है।

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

मुझे यकीन नहीं है कि यह आपके विचार को विकल्प 2 के बारे में बिल्कुल बदल देता है, लेकिन मैं इसका उल्लेख करना चाहता था क्योंकि विकल्प 2 में कुछ अच्छे बोनस हैं और प्रीएक्ट इसे व्यवहार में साबित कर रहा है।

हो सकता है कि तब सबसे अच्छा तरीका यह है कि गुण हमेशा क्लाइंट पक्ष पर करें और फिर उन लोगों के लिए नाम विशेषता के लिए आदिम संपत्ति नामों के विकल्प 5-शैली कॉन्फ़िगरेशन मानचित्र का समर्थन करें जो अपने ऐप्स में एसएसआर का समर्थन करना चाहते हैं।

+1, मैं इस दिशा में आगे बढ़ने का समर्थन करता हूं।

@effulgentsia

मुझे लगता है कि यह एक अच्छा विचार है, सिवाय इसके कि यह उन लोगों के लिए एक ब्रेकिंग बदलाव है जिन्होंने विशेषता नामों का उपयोग करके अपने रिएक्ट ऐप्स लिखे हैं।

विकल्प 2 इसे हल करेगा :)
अन्यथा शायद विकल्प 1 के साथ एक अनुमानी युग्मित होने की आवश्यकता होगी जो कि डैश-आवरण वाले गुणों को कैमलकेसेड गुणों में मैप करता है।

लेकिन "गुण करें" के लिए एक नियम के बारे में क्या है यदि प्रोपनाम में डैश नहीं है और यदि ऐसा होता है तो "विशेषताएं करें"?

ऐसा लगता है कि नाम में डैश होने पर Preact विशेषता सेट कर देगा । मुझे लगता है कि ऐसा इसलिए है क्योंकि वे विकल्प 2 का उपयोग करते हैं और long-name in चेक पास नहीं करते हैं, इसलिए यह एक विशेषता ( स्रोत ) पर वापस आ जाता है।

मुझे व्यक्तिगत रूप से यह व्यवहार पसंद है, लेकिन यह विशेषता और संभावित भविष्य के संघर्षों को स्थापित करने के दायरे में वापस आ जाता है, इसलिए मुझे लगता है कि @ सोफीबिट्स का वजन होना चाहिए।

क्या आप किसी ऐसे कस्टम तत्व ढांचे या प्रथाओं के बारे में जानते हैं जहां लोगों के पास संबंधित संपत्ति से विशेषताओं के अलग-अलग आवरण होंगे, बिना डैश के?

मेरी जानकारी में नहीं। पुस्तकालय के लिए यह जानने का एक आसान तरीका है कि ऊंट का मामला कहां है। यदि आप एक वेनिला वेब घटक को हाथ से लिख रहे थे तो आप longname/longName और केवल विकल्प 2 आपको बचाएगा क्योंकि इसे longname संपत्ति नहीं मिलेगी, लेकिन यह पहले इस्तेमाल किए गए पर वापस आ जाएगा longname विशेषता।

इसके लायक क्या है, ऐसा लगता है कि प्रीएक्ट, अंतिम उपाय के रूप में, उस संपत्ति पर toLowerCase() कॉल करेगा जिसे वह विशेषता सेट करने से पहले <x-foo longName={bar}/> SSR'ing कर रहे थे तो यह longname="" विशेषता पर भी वापस आ जाएगा।

@treshugart

हो सकता है कि हम फ़ॉलबैक/मैपिंग प्रदान करते हुए क्लाइंट पर प्रॉप्स सेट करने के @sophiebits के प्रस्ताव के साथ कोशिश करें और आगे

हाँ, और हाँ।

मैं वही काम करूंगा जो वृद्धिशील डोम कर रहा है

क्या यह विचार है कि प्रत्येक तत्व (या उनके आधार वर्ग) को इसमें मिश्रण करने की आवश्यकता होगी?

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

सुनिश्चित नहीं है कि मैं https://github.com/facebook/react/issues/11347#issuecomment -339858314 में अंतिम उदाहरण को समझता हूं, लेकिन यह अत्यधिक संभावना नहीं है कि हम इस तरह एक वैश्विक अतिव्यापी हुक प्रदान करेंगे।

@gaearon मुझे लगता है कि ट्रे सिर्फ बंदर-पैच के रूप में शुद्ध परिवर्तन दिखा रहा था, संभवतः इसे रिएक्टडॉम कार्यान्वयन में ही लिखा जाएगा।

हाल की टिप्पणियों के आधार पर, आप सभी इस प्रस्ताव के बारे में क्या सोचते हैं?

1. बीसी के लिए, रिएक्ट में लोअरकेस कस्टम तत्व कैसे काम करते हैं, इसके बारे में कुछ भी न बदलें। दूसरे शब्दों में, JSX जैसे <x-foo ... /> , React 17 में उसी तरह काम करना जारी रखेगा जैसा कि 16 में था। या, यदि _minor_ बग फिक्स इसके लिए आवश्यक हैं, तो उन पर चर्चा करने के लिए एक अलग मुद्दा खोलें।

2. बेहतर कस्टम एलिमेंट सेमेन्टिक्स के साथ रिएक्ट कंपोनेंट बनाने के लिए कॉन्फिग-लेस एपीआई जोड़ें। जैसे, const XFoo = ReactDOM.customElement('x-foo'); ।

3. ऊपर बनाए गए घटक के लिए, निम्नलिखित शब्दार्थों को नियोजित करें:

4. XFoo पर किसी भी प्रोप के लिए जो एक आरक्षित रिएक्ट प्रोप नाम है ( children , ref , कोई अन्य?), इसके लिए सामान्य रिएक्ट शब्दार्थ लागू करें (इसे एक विशेषता या संपत्ति के रूप में सेट न करें कस्टम तत्व डोम नोड पर)।
5. HTML कल्पना द्वारा परिभाषित किसी भी HTMLElement वैश्विक विशेषता या संपत्ति के लिए ( data-* और aria-* ), उन प्रॉप्स के साथ वही करें जो React उनके साथ करेगा यदि वे div पर थे <XFoo data-x={} className={} contentEditable={} /> पर DOM नोड पर प्रॉप्स को कैसे लागू करता है, यह <div data-x={} className={} contentEditable={} /> (क्लाइंट-साइड और SSR दोनों के लिए) के समान होना चाहिए।
6. XFoo पर किसी भी प्रोप के लिए जिसमें डैश (ऊपर अनुमत वैश्विक विशेषताओं के अलावा) शामिल है, एक चेतावनी उत्सर्जित करें (डेवलपर को सूचित करने के लिए कि XFoo एक संपत्ति-केंद्रित है, न कि विशेषता-केंद्रित, API) और इसके साथ कुछ भी नहीं करें (न तो इसे एक संपत्ति और न ही एक विशेषता के रूप में सेट करें)।
7. XFoo पर किसी भी प्रोप के लिए जो अंडरस्कोर या ऊपरी ASCII अक्षर से शुरू होता है, इसके साथ कुछ भी नहीं करें (और शायद चेतावनी छोड़ दें?) कस्टम तत्वों के लिए गुणों को नाम देने का कोई अनुशंसित तरीका नहीं है, इसलिए भविष्य के शब्दार्थ के लिए उन नामस्थानों को आरक्षित करें (उदाहरण के लिए, नीचे #4 देखें)।

8. XFoo पर अन्य सभी प्रॉप्स के लिए, क्लाइंट-साइड रेंडर करते समय, इसे DOM नोड पर एक प्रॉपर्टी के रूप में सेट करें। SSR के लिए, यदि मान आदिम है, तो इसे एक विशेषता के रूप में प्रस्तुत करें; यदि गैर-आदिम है, तो रेंडरिंग छोड़ें और इसे हाइड्रेशन के दौरान एक प्रॉपर्टी क्लाइंट-साइड के रूप में सेट करें। एक विशेषता के रूप में SSR प्रतिपादन के लिए, camelCaseToDashCase नाम।

9. ऊपर #2 में एपीआई के माध्यम से बनाए गए घटकों के लिए, इवेंट श्रोताओं के लिए उपयोग करने के लिए एक प्रोप नाम आरक्षित करें। जैसे, 'events' या 'eventListeners' । या, यदि उन संभावित कस्टम तत्व संपत्ति नामों के साथ विरोध नहीं करना चाहते हैं, तो '_eventListeners' या 'EventListeners' । XFoo का रिएक्टडॉम-निर्मित कार्यान्वयन स्वचालित रूप से इन ईवेंट श्रोताओं को DOM नोड पर पंजीकृत करेगा।

10. किनारे के मामलों के लिए (उदाहरण के लिए, एक कस्टम तत्व का उपयोग करना जिसके लिए उपरोक्त कार्यान्वयन वांछित या पर्याप्त नहीं है), ऐप डेवलपर अपने स्वयं के रिएक्ट घटक को लागू कर सकता है ताकि वे जो भी विशेष काम कर सकें उसे करने के लिए। यानी, उन्हें ReactDOM.customElement() का उपयोग करने की आवश्यकता नहीं है या वे इसे बढ़ा सकते हैं।

11. उन लोगों के लिए जो उपरोक्त सभी व्यवहार चाहते हैं, लेकिन चाहते हैं कि उनका JSX लोअरकेस कस्टम एलिमेंट नामों ( <x-foo /> बजाय <XFoo /> , इसी कारण से HTML लिखने से परिचित लोग <div> पसंद करते हैं <Div> ), वे बंदर-पैच React.createElement() कर सकते हैं। यह एक बहुत ही सरल बंदर पैच होगा: बस पहला तर्क लें और यदि यह एक कस्टम तत्व नाम से मेल खाता है जिसके लिए आप इसे चाहते हैं (चाहे वह एक विशिष्ट सूची हो या सभी लोअरकेस अक्षरों और कम से कम एक डैश के साथ कोई स्ट्रिंग हो), तो ReactDOM.customElement() आह्वान करें उस नाम पर React.createElement() पर अग्रेषित करें।

@Developit @gaearon यह या तो हो सकता है। यदि "मानचित्रण" आवश्यक था, तो मुझे लगता है कि एक हुक अधिक टिकाऊ है। हालाँकि, इसका उद्देश्य शुद्ध परिवर्तन को दिखाना भी था यदि इसे ReactDOM के मूल में लागू किया जाना था, जैसा कि जेसन ने बताया।

बीसी के लिए, रिएक्ट में लोअरकेस कस्टम तत्व कैसे काम करते हैं, इसके बारे में कुछ भी न बदलें। दूसरे शब्दों में, JSX पसंद करता है रिएक्ट 17 में उसी तरह काम करना जारी रखेगा जैसा कि 16 में था। या, यदि इसके लिए मामूली बग फिक्स की आवश्यकता है, तो उन पर चर्चा करने के लिए एक अलग मुद्दा खोलें।

व्यक्तिगत रूप से मैं अपने <x-foo> तत्व का उपयोग करने में सक्षम होना पसंद करूंगा, और इसे आसानी से इसे लपेटने की आवश्यकता के बिना गुणों को पास कर दूंगा।

यदि संभव हो तो मैं विकल्प 1 (क्लाइंट-साइड गुण) और 5 (एसएसआर के लिए कॉन्फ़िगरेशन) के @sohpiebits ' सुझाव के साथ जाऊंगा । मैं अभी भी उम्मीद कर रहा हूं कि शायद लोग पश्चगामी संगतता बोनस के लिए विकल्प 2 (शायद विकल्प 2 + 5?) पर पुनर्विचार करेंगे।

@gaearon क्या आपकी राय ट्रे के प्रस्ताव पर बदल जाती है यदि यह ReactDOM कोर का हिस्सा है? हो सकता है कि अगर हम मदद करेंगे तो हम उदाहरण को और बढ़ा सकते हैं?

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

मैं वास्तव में प्यार करता था कि कैसे रिएक्ट टीम ने रेपो में अंतिम परिवर्तनों को संभाला, जैसे कि _PropTypes_, केवल एक से अधिक स्विच को शामिल करने वाली योजना के बारे में सोचना अच्छा होगा, डेवलपर्स को भविष्य में कस्टम के लिए संभावित परिवर्तनों में शिक्षित करने के लिए और कस्टम के लिए नहीं तत्व

मुझे लगता है कि समाधान जो हम सभी को संतुष्ट करेगा, वह होगा इनमें से कुछ विकल्पों को _steps_, एपीआई जोड़, चेतावनी और बहिष्करण या व्यवहार परिवर्तन के रूप में जोड़ना।

शायद विकल्प 5, चेतावनी के साथ, बाद में विकल्प 2 आवश्यक आवरण के बहिष्करण के साथ।

शायद विकल्प 5, चेतावनी के साथ, बाद में विकल्प 2 आवश्यक आवरण के बहिष्करण के साथ।

मैं वास्तव में सोच रहा था कि इसके विपरीत करना कदमों की एक बेहतर श्रृंखला होगी। विकल्प 1 या 2 क्योंकि यह कम नाटकीय परिवर्तन है। और यह मापना कि यह कैसे जाता है और वेब घटकों के लिए SSR कहानी कैसी दिखने लगती है। फिर विकल्प 5 के साथ अनुसरण करना क्योंकि यह एक नया एपीआई और प्रॉक्सी/रैपर घटकों की धारणा जोड़ता है।

विकल्प 1 के साथ मुख्य समस्या यह है कि यह काफी बड़ा BC ब्रेक है। विकल्प 2 के साथ मुख्य समस्या यह है कि तत्व को अपग्रेड करने के समय के आधार पर इसकी दौड़ की स्थिति होती है। मुझे यकीन नहीं है कि उनमें से कोई भी एक परियोजना के लिए वास्तव में स्वीकार्य है जिसका व्यापक रूप से रिएक्ट के रूप में उपयोग किया जाता है।

विकल्प 5 की उपलब्धता को देखते हुए, मुझे आश्चर्य है कि क्या हम इसके बजाय अधिक सुरक्षित, लेकिन फिर भी उपयोगी, गैर-विकल्प -5 उपयोगों में सुधार कर सकते हैं। उदाहरण के लिए, विकल्प 4 के व्युत्क्रम के बारे में कैसे: बस domProperties और eventListeners प्रोप का परिचय दें, ताकि आप सामान कर सकें:

<x-foo 
  my-attr1={...} 
  domProperties={{myRichDataProperty: ...}} 
  eventListeners={{'a-custom-element-event':  e => console.log('yo')}} 
/>

यह पूरी तरह से पीछे की ओर संगत है, क्योंकि उनके अपरकेस अक्षरों के कारण, domProperties और eventListeners मान्य विशेषता नाम नहीं हैं। सिवाय इसके कि रिएक्ट 16 वर्तमान में सेटएट्रिब्यूट () को ऊपरी अल्फ़ाज़ वाले प्रोप नामों के लिए भी कॉल करता है, नाम को आंतरिक रूप से कम करने के लिए ब्राउज़र पर निर्भर करता है; हालांकि, क्या रिएक्ट 16 की भविष्य की मामूली रिलीज कस्टम एलिमेंट प्रॉप्स का सामना करते समय एक चेतावनी का उत्सर्जन कर सकती है जो मान्य विशेषता नाम नहीं हैं, ताकि लोग रिएक्ट 17 में अपग्रेड करने से पहले अपनी केसिंग गलतियों को ठीक कर सकें?

बीसी को संरक्षित करने के अलावा, इस दृष्टिकोण को समझना आसान है: यह विशेषता-केंद्रित है (अर्थात् रिएक्ट प्रोप को तत्व विशेषताओं के रूप में माना जाता है), जो फिट बैठता है कि तत्व का नाम सभी लोअरकेस है और इसमें डैश है और इसलिए HTML-केंद्रित है। हालांकि, domProperties अपेक्षाकृत दुर्लभ मामलों के लिए प्रदान किया जाता है जहां आपको गुण पारित करने की आवश्यकता होती है, जैसे समृद्ध डेटा पास करने के लिए।

जो लोग अपने मानसिक मॉडल को संपत्ति-केंद्रित (अला विकल्प 1) में बदलना चाहते हैं, उनके लिए एक विकल्प 5 स्टाइल एपीआई आ सकता है:

const XFoo = ReactDOM.customElement('x-foo');
<XFoo prop1={} prop2={} data-foo={} aria-label={} />

इस सिंटैक्स के साथ, प्रत्येक प्रोप को एक संपत्ति (विकल्प 1) के रूप में माना जाता है। जो फिट बैठता है, क्योंकि तत्व "नाम" (एक्सफू) भी जेएस-केंद्रित सम्मेलन का पालन कर रहा है। मुझे लगता है कि हम अभी भी न्यूनतम समर्थन data-* और aria-* प्रोप को विशेषताओं के रूप में माना जाना चाहते हैं, जिसे हम या तो केवल उन तक सीमित कर सकते हैं, या किसी भी प्रोप को डैश के साथ व्यवहार करने के लिए सामान्यीकृत कर सकते हैं। गुण।

इस बीच, SSR के विकल्प 5 कॉन्फ़िगरेशन का समर्थन करने के लिए, हम एक कॉन्फ़िगरेशन API को ReactDOM.customElement जोड़ सकते हैं, जैसे:

const XFoo = ReactDOM.customElement('x-foo', ssrConfiguration);

शायद ssrConfiguration @treshugart की टिप्पणी में ReactDOM.setAttribute समान कॉलबैक फ़ंक्शन हो सकता है?

तुम क्या सोचते हो?

@effulgentsia मुझे पसंद है कि आपके विचार कहाँ जा रहे हैं। नामों को थोड़ा सा बाइकशेड करना: domProps / domEvents । यह विकल्प 4 के बहुत करीब है।

डब्लूआरटी एसएसआर, मुझे लगता है कि एसएसआर को कस्टम तत्वों द्वारा स्वयं तब तक संभाला जा सकता है जब तक रिएक्ट उन गुणों का सम्मान कर सकता है जो घटक स्वयं को बदलता है यदि यह उन्हें ट्रैक नहीं कर रहा है। मैंने पहले एक सार पोस्ट किया था, लेकिन यहाँ यह फिर से सुविधा के लिए है: https://gist.github.com/treshugart/6eff0da3c0bea886bb56589f743b78a6। अनिवार्य रूप से घटक सर्वर पर रेंडर करने के बाद विशेषताओं को लागू करता है और क्लाइंट पर उन्हें रीहाइड्रेट करता है। वेब घटकों के लिए SSR संभव है, लेकिन समाधान पर अभी भी मानक स्तर पर चर्चा की जा रही है, इसलिए प्रस्ताव के इस भाग पर प्रतीक्षा करना सबसे अच्छा हो सकता है।

@effulgentsia मुझे यह भी पसंद है कि आप कहाँ जा रहे हैं। @sophiebits , @gaearon do
आप सभी के पास इस दिशा में विचार हैं?

मंगलवार, 31 अक्टूबर, 2017 को शाम 7:33 बजे ट्रे शुगार्ट नोटिफिकेशन @github.com ने लिखा:

@effulgentsia https://github.com/effulgentsia मुझे पसंद है जहां आपका
विचार जा रहे हैं। नामों को थोड़ा सा बाइकशेड करना, यह उपयोगी हो सकता है
उनके नामकरण को संरेखित करें: domProps / domEvents, या कुछ और।

डब्लूआरटी विकल्प 2, यह कम से कम पिछड़ा संगत है और अधिकांश उपयोग-मामलों को हल करता है,
लेकिन मैं विकल्पों के आसपास आ रहा हूँ।

मुझे लगता है कि एसएसआर को कस्टम तत्वों द्वारा स्वयं तब तक संभाला जा सकता है जब तक
प्रतिक्रिया उन गुणों का सम्मान कर सकती है जो घटक अपने आप में उत्परिवर्तित होते हैं यदि यह है
उन्हें ट्रैक नहीं कर रहा है। मैंने पहले एक सार पोस्ट किया था, लेकिन यहाँ यह फिर से है, क्योंकि
सुविधा:
https://gist.github.com/treshugart/6eff0da3c0bea886bb56589f743b78a6।
अनिवार्य रूप से घटक सर्वर पर प्रतिपादन के बाद विशेषताओं को लागू करता है
और उन्हें क्लाइंट पर रीहाइड्रेट करता है। वेब घटकों के लिए SSR संभव है, लेकिन
समाधान अभी भी मानक स्तर पर चर्चा की जा रही है, इसलिए यह हो सकता है
यहां प्रस्ताव के इस हिस्से पर इंतजार करना सबसे अच्छा है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/facebook/react/issues/11347#issuecomment-340960798 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABBFDeiQhBWNGXNplbVV1zluYxT-ntFvks5sx9hngaJpZM4QD3Zn
.

नामों को थोड़ा सा बाइकशेड करना: डोमप्रॉप्स / डोमइवेंट्स।

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

और फिर मैंने सोचा, क्या होगा यदि this.props अंदर नए विशेष नामों को पेश करने के बजाय, हम मौजूदा ref JSX विशेषता को अधिभारित कर दें। वर्तमान में, "रेफरी" एक फ़ंक्शन है जिसे रिएक्ट घटक माउंट और अनमाउंट होने पर कहा जाता है। क्या होगा अगर हम इसे एक वस्तु के रूप में भी अनुमति दें:

<x-foo my-attr-1={}
  ref={{
    props: ...
    events: ...
    mounted: ...
    unmounted: ...
  }}
/>

एक विचार है।

मुझे वास्तव में यह दृष्टिकोण पसंद है :)

इस पर दोस्ताना पिंग। @gaearon @sophiebits क्या आप @effulgentsia के नवीनतम प्रस्ताव पर कोई विचार

हमने अभी एक RFC प्रक्रिया खोली है। क्या हम आप में से किसी को इसे RFC के रूप में जमा करने के लिए कह सकते हैं?
https://github.com/reactjs/rfcs

मैं इसके बजाय domProperties और eventListeners "props" (या ref={{}} ऑब्जेक्ट के बराबर) नहीं जोड़ूंगा क्योंकि यह कस्टम तत्वों का उपयोग बहुत ही अप्राकृतिक और अन्य सभी रिएक्ट घटकों के विपरीत करता है। यदि घटक उपयोगकर्ता को गुणों और विशेषताओं आदि के बीच अंतर को गहराई से जानने की आवश्यकता है, तो मैं इसे एक ReactDOM.createCustomElementType- शैली समाधान के रूप में करना पसंद करूंगा। फिर यदि आप घटक का उपयोग ठीक एक बार करते हैं तो यह एक तुलनीय मात्रा में काम है (कॉन्फ़िगरेशन निर्दिष्ट करना और फिर इसे एक बार उपयोग करना), लेकिन यदि आप कई बार घटक का उपयोग करते हैं तो आपको हर बार कॉन्फ़िगरेशन ऑब्जेक्ट के बारे में सोचने की आवश्यकता नहीं होती है। यह आवश्यक है कि कॉन्फ़िगरेशन को हर बार निर्दिष्ट किया जाए, जब तक कि मुझे कुछ याद नहीं आ रहा है, एक स्वच्छ कस्टम तत्व एकीकरण होने के लक्ष्यों को हराने लगता है।

@sophiebits ठीक है, मैं ऐसा कुछ के लिए एक आरएफसी लिखने का प्रयास कर सकता था। आप उस विचार के बारे में क्या सोचते हैं जो आपने 26 अक्टूबर को क्लाइंट साइड पर सबसे पहले संपत्तियों के बारे में शुरू किया था और लोगों को एसएसआर के लिए ReactDOM.createCustomElementType लिखने की इजाजत दी थी और/या यदि वे क्लाइंट मैप्स/गुणों पर वास्तव में बढ़िया नियंत्रण चाहते हैं तो आप क्या सोचते हैं ?

कम से कम createCustomElementType शैली के साथ, पुस्तकालय आसानी से अपने एपीआई को उसमें मैप कर सकते हैं। यानी, हमारे स्केटज/रेंडरर-रिएक्शन आसानी से props ले सकते हैं और रिएक्ट के लिए कस्टम तत्व को कॉन्फ़िगर कर सकते हैं। इस प्रकार की पत्तियां वेनिला लोगों को बिना किसी अमूर्तता या थोड़ा सा काम करने के उच्च और शुष्क छोड़ देती हैं। ठीक-ठाक नियंत्रण की अनुमति देते हुए, मुझे रॉब का एक सुरक्षित डिफ़ॉल्ट का सुझाव पसंद है। क्या ऐसा कुछ है जो काम करेगा?

@robdodson मुझे लगता है कि मैं इसके साथ बोर्ड पर हूं। मैं वादा नहीं कर सकता कि कोई अन्य चिंता नहीं आएगी, लेकिन मुझे लगता है कि यह एक अच्छा संतुलन है।

विकल्प 3 अब तक का सबसे अच्छा विकल्प है, और यह SSR के साथ काम कर सकता है, मैं इसका एक विचार बताऊंगा कि कैसे।

अब तक सभी विकल्प अपने आप में, 3 को छोड़कर,

• या तो रिएक्ट स्रोत के बाहर सभी के लिए उच्च रखरखाव बोझ बनाएं
• या वे पूरे ब्रह्मांड में सभी कस्टम तत्व लेखकों को प्रतिक्रिया-विशिष्ट नियमों का पालन करने के लिए मजबूर करते हैं।

यहाँ सार्वभौमिक नियम हैं जिन पर हम सभी सहमत हैं:

• setAttribute साथ विशेषताओं को सेट करना ब्रह्मांड में तत्वों को डेटा पास करने का सबसे मानक तरीका है जो घोषणात्मक HTML विशेषताओं के साथ 1-से-1 से मेल खाता है। इसे ब्रह्मांड के नियम के रूप में 100% समय काम करना है, इसलिए तत्वों को डेटा पास करने का यह एकमात्र 100% गारंटीकृत तरीका है।
• कुछ लोग खुश नहीं हैं कि यह केवल तारों के लिए बनाया गया था।
• कुछ तत्व (मैं दोहराता हूं, _only some element_ ), ऑब्जेक्ट गुणों के माध्यम से मान स्वीकार करते हैं जो कुछ विशेषताओं के लिए मैप करते हैं। यह _not_ कुछ ऐसा है जिस पर 100% समय भरोसा किया जा सकता है।
• कुछ लोग वस्तु गुणों को पसंद करते हैं क्योंकि वे गैर-तार स्वीकार कर सकते हैं

तो, कम से कम, अगर रिएक्ट ब्रह्मांड में _हर एक कस्टम तत्व के साथ 100% काम करना चाहता

• प्रतिक्रिया को यह महसूस करने की आवश्यकता है कि यह भगवान नहीं है, अन्य कई पुस्तकालय हैं जिनका लोग प्रतिक्रिया के अलावा उपयोग करते हैं,
• इसलिए रिएक्ट _by default_ केवल setAttribute माध्यम से डेटा पास करें क्योंकि यह 100% मानक है।
• प्रतिक्रिया को इस तथ्य को स्वीकार करना चाहिए कि कस्टम तत्व लेखक अपनी कक्षा परिभाषाओं में setAttribute विधियों का विस्तार/ओवरराइड कर सकते हैं, जिससे setAttribute स्ट्रिंग के अलावा अन्य चीजों को स्वीकार कर सकते हैं। एक प्रमुख उदाहरण ए-फ्रेम जैसे पुस्तकालय हो सकते हैं।
• प्रतिक्रिया को यह स्वीकार करना चाहिए कि यदि एक कस्टम तत्व लेखक चाहता है कि एक कस्टम तत्व हर संभव पुस्तकालय के साथ काम करे, _न केवल React_ के साथ , तो वह लेखक अपने तत्व को डिफ़ॉल्ट रूप से हर चीज के साथ संगत बनाने के लिए setAttribute पर निर्भर करेगा, और यदि डिफ़ॉल्ट रूप से सभी पुस्तकालय गुणों पर निर्भर हैं, तो पूरा ब्रह्मांड एक दूसरे के साथ काम करेगा। _इस बारे में कोई ifs, ands, या buts नहीं है!_ (जब तक कि w3c/whatwg कुछ बड़े बदलाव नहीं करता)

Sooooooooo , कहा जा रहा है, हमें कम से कम होना चाहिए

• https://github.com/facebook/react/issues/10070 ठीक
• महसूस करें कि ऐसा करने से हम मानकों के और करीब पहुंच जाते हैं

फिर, हम कभी-कभी ऑब्जेक्ट-प्रॉपर्टी एपीआई वाले तत्वों के प्रभावों के बारे में सोच सकते हैं:

• डेवलपर्स के पास setAttribute का उपयोग करने का विकल्प है, यह जानते हुए कि यह हर समय काम करेगा।
• डेवलपर्स कभी-कभी ऑब्जेक्ट गुणों का लाभ उठा सकते हैं।
• डेवलपर्स को हमेशा यह पता होना चाहिए कि किसी दिए गए तत्व (कस्टम या नहीं) के लिए ऑब्जेक्ट-प्रॉपर्टी इंटरफ़ेस मौजूद है या नहीं।
• ऑब्जेक्ट-प्रॉपर्टी इंटरफेस एक वैकल्पिक इंटरफ़ेस है जो आवश्यक रूप से विशेषताओं के साथ 1-टू-1 मैप नहीं करता है।

तो, गुणों बनाम गुणों के इस ज्ञान के साथ, रिएक्ट में एक समाधान जो _ब्रह्मांड के १००% मानक और सम्मान कानूनों को बढ़ाना चाहता है_ चाहिए:

1. विशेषताओं को डिफ़ॉल्ट रूप से 100% समय काम करने दें। इसका मतलब यह है कि <x-foo blah="blah" /> को _डिफ़ॉल्ट रूप से_ मैप करके setAttribute जाना चाहिए और मान को _unchanged_ के साथ पास करना "[object Object]" स्ट्रिंग को पारित कर देगा।
2. यदि उपयोगकर्ता इस बारे में जागरूक है कि कौन सा ऑब्जेक्ट-प्रॉपर्टी इंटरफेस मौजूद है और उन इंटरफेस का स्पष्ट रूप से उपयोग करना चाहता है, तो प्रतिक्रिया उपयोगकर्ता को _वैकल्पिक रूप से प्रॉप्स का उपयोग करने देने के लिए एक वैकल्पिक तरीके के साथ आओ।

यह विकल्प 3 की तरह लगता है, एक सतर्क का उपयोग करना (जो अतिरिक्त वाक्यविन्यास ईमानदारी से सीखना मुश्किल नहीं है), एक ऐसा समाधान है जो आदर्श के सबसे करीब हो जाता है। इस SO प्रश्न के आधार पर, केवल उपलब्ध प्रतीक = , हालांकि & (एक बचने योग्य रूप के साथ, शायद \& ) पर बसना अधिक पठनीय है। उदाहरण के लिए, यदि मुझे विशेष रूप से एक प्रोप चाहिए:

<x-foo &blah="blah" />

WHATWG HTML सिंटैक्स स्पेक द्वारा कवर किए गए अधिकांश अन्य पात्रों को काम करना चाहिए, और मुझे आशा है कि वे करते हैं लेकिन यह एक और विषय है।

विकल्प 3 अब तक का सबसे अच्छा विकल्प है।

यदि क्लाइंट पर हाइड्रेशन का उपयोग नहीं किया जा रहा है और इसलिए एसएसआर में प्रॉप्स का कोई मतलब नहीं है, तो, ओह ठीक है। इसने पहले कभी काम नहीं किया, और इसे अब काम करने की आवश्यकता नहीं है। PHP-शैली या जावा-शैली SSR बिना हाइड्रेशन के स्थिर HTML भेजता है और वे विशेषताओं पर 100% भरोसा करते हैं। यह कहने के लिए जाता है, अगर हम रिएक्ट एसएसआर का उपयोग करते हैं, तो हम शायद क्लाइंट-साइड हाइड्रेशन का उपयोग करेंगे, और यदि हम हाइड्रेशन नहीं चाहते हैं, तो हमें बस इस तथ्य से अवगत होना चाहिए कि हमें इस मामले में प्रोप का उपयोग नहीं करना चाहिए। _यह सरल है। केवल प्रतिक्रिया करने के लिए दस्तावेज़ीकरण में इस चेतावनी को स्पष्ट करना है।_

परंतु!!! वह सब कुछ नहीं हैं! लोगों को अधिक नियंत्रण देने के लिए हम अभी भी विकल्प 5 की सुविधाओं को शामिल कर सकते हैं। विकल्प 5 जैसे एपीआई के साथ,

• कुछ लोग कॉन्फ़िगर कर सकते हैं कि कैसे कुछ विशेषताएँ प्रॉप्स में मैप कर सकती हैं
• और कैसे कुछ प्रॉप्स विशेषताओं को मैप कर सकते हैं। यह लोगों को SSR को गैर-हाइड्रेटिंग प्रकार के SSR के लिए भी काम करने में मदद कर सकता है!
• हम लोगों को परिभाषित कर सकते हैं "यदि यह विशेषता लिखी गई है, तो वास्तव में इसे इस प्रोप में पास करें, लेकिन यदि यह एसएसआर है, तो इसे प्रोप को पास न करें", या "इस प्रोप को केवल एसएसआर के दौरान इस विशेषता को पास करें, अन्यथा क्या करें मैंने सिगिल का उपयोग करके निर्दिष्ट किया", आदि

अंत में, निम्नलिखित एक समाधान की तरह लगता है जो काम करेगा:

• विकल्प 3 setAttribute डिफ़ॉल्ट रूप से पर्दे के पीछे उपयोग किया जाता है,
• #10070 के लिए एक फिक्स के साथ ताकि प्रतिक्रिया लोगों के रास्ते में न आए,
• और एसएसआर, क्लाइंट, या दोनों को ट्यून करने के तरीकों सहित, उन लोगों के लिए आगे ट्यूनिंग के लिए विकल्प 5 की तरह एक एपीआई, जिन्हें वास्तव में इसकी आवश्यकता है।

नववर्ष की शुभकामनाएं!

मैं उपरोक्त कुछ बिंदुओं पर प्रतिक्रिया देना चाहता हूं, लेकिन डर है कि यह धागा पहले से ही _अविश्वसनीय रूप से_ लंबा है। तो, इसे लंबा करने के लिए खेद है: पी

यहाँ सार्वभौमिक नियम हैं जिन पर हम सभी सहमत हैं:

सेट एट्रिब्यूट के साथ विशेषताएँ सेट करना ब्रह्मांड में तत्वों को डेटा पास करने का सबसे मानक तरीका है जो घोषणात्मक HTML विशेषताओं के साथ 1-से-1 से मेल खाता है। इसे ब्रह्मांड के नियम के रूप में 100% समय काम करना है, इसलिए तत्वों को डेटा पास करने का यह एकमात्र 100% गारंटीकृत तरीका है।

यह पूरी तरह सच नहीं है। यह लागू करने के लिए प्लेटफ़ॉर्म में कुछ भी नहीं है कि एक कस्टम तत्व एक विशेषता इंटरफ़ेस को उजागर करता है। आप उतनी ही आसानी से एक बना सकते हैं जो केवल JS गुणों को स्वीकार करता है। तो यह "डेटा पास करने का गारंटीकृत तरीका" नहीं है। प्रवर्तन तंत्र की कमी का मतलब है कि आप 100% निश्चितता के साथ किसी भी शैली (HTML विशेषताएँ या JS गुण) पर भरोसा नहीं कर सकते।

कुछ लोग खुश नहीं हैं कि यह केवल तारों के लिए बनाया गया था।
कुछ तत्व (मैं दोहराता हूं, केवल कुछ तत्व), ऑब्जेक्ट गुणों के माध्यम से मान स्वीकार करते हैं जो कुछ विशेषताओं को मैप करते हैं। यह ऐसा कुछ नहीं है जिस पर 100% समय पर भरोसा किया जा सकता है।

हम लोगों को प्रोत्साहित करते हैं कि वे उन संपत्तियों के लिए विशेषताएँ बनाने से भी परेशान न हों जो वस्तुओं / सरणियों जैसे समृद्ध डेटा को स्वीकार करती हैं। ऐसा इसलिए है क्योंकि कुछ डेटा को एक विशेषता स्ट्रिंग में वापस क्रमबद्ध नहीं किया जा सकता है। उदाहरण के लिए, यदि आपका कोई ऑब्जेक्ट गुण DOM नोड का संदर्भ है, जिसे वास्तव में स्ट्रिंग नहीं किया जा सकता है। साथ ही, जब आप किसी ऑब्जेक्ट को स्ट्रिंग और रिपार्स करते हैं, तो वह अपनी पहचान खो देता है। मतलब, अगर इसमें किसी अन्य पीओजेओ का संदर्भ है, तो आप वास्तव में उस संदर्भ का उपयोग नहीं कर सकते क्योंकि आपने पूरी तरह से नई वस्तु बनाई है।

कुछ लोग वस्तु गुणों को पसंद करते हैं क्योंकि वे गैर-तार स्वीकार कर सकते हैं

इसलिए रिएक्ट डिफ़ॉल्ट रूप से चिल्लाता है बस डेटा को सेट एट्रिब्यूट के माध्यम से पास करें क्योंकि यह 100% मानक है।

जावास्क्रिप्ट गुण समान रूप से मानक हैं। अधिकांश HTML तत्व एक विशेषता और संबंधित गुण इंटरफ़ेस दोनों को उजागर करते हैं। उदाहरण के लिए, <img src=""> या HTMLImageElement.src ।

रिएक्ट को इस तथ्य को स्वीकार करना चाहिए कि कस्टम एलिमेंट लेखक अपनी वर्ग परिभाषाओं में सेटएट्रिब्यूट विधियों को बढ़ा / ओवरराइड कर सकते हैं, जिससे सेटएट्रिब्यूट स्ट्रिंग्स के अलावा अन्य चीजों को स्वीकार करता है।

लेखक ऐसा कर सकते थे, लेकिन यह वास्तव में जेएस गुणों का उपयोग करने की तुलना में अधिक "गैर-मानक" लगता है। यह आपको तत्व को पार्स करने और क्लोन करने से संबंधित अजीब मुद्दों के बारे में भी बता सकता है।

प्रतिक्रिया को यह स्वीकार करना चाहिए कि यदि कोई कस्टम तत्व लेखक चाहता है कि एक कस्टम तत्व हर संभव पुस्तकालय के साथ काम करे, न कि केवल प्रतिक्रिया के साथ, तो वह लेखक अपने तत्व को डिफ़ॉल्ट रूप से हर चीज के अनुकूल बनाने के लिए सेटएट्रिब्यूट पर निर्भर करेगा, और यदि डिफ़ॉल्ट रूप से सभी पुस्तकालय विशेषताओं पर भरोसा करते हैं , तो पूरा ब्रह्मांड एक दूसरे के साथ काम करेगा। इसके बारे में कोई अगर, और, या लेकिन नहीं है! (जब तक w3c/whatwg कुछ बड़े बदलाव नहीं करता)

मुझे यकीन नहीं है कि आप इस निष्कर्ष पर कैसे पहुंचे क्योंकि अन्य पुस्तकालय हैं जो कस्टम तत्वों पर जेएस गुण सेट करना पसंद करते हैं (उदाहरण के लिए कोणीय)। अधिकतम अनुकूलता के लिए, लेखकों को JS गुणों के साथ अपनी विशेषताओं का समर्थन करना चाहिए। यह संभावित उपयोगों के सबसे बड़े सतह क्षेत्र को कवर करेगा। पॉलिमर के साथ बनाए गए सभी तत्व डिफ़ॉल्ट रूप से ऐसा करते हैं।

विशेषताओं को डिफ़ॉल्ट रूप से 100% समय काम करने दें। इस का मतलब है कि डिफ़ॉल्ट मानचित्र द्वारा सेट एट्रिब्यूट और अपरिवर्तित के साथ मान पास करना चाहिए। यह एक अटूट परिवर्तन है। वास्तव में, यह एक फिक्सिंग परिवर्तन है जो अन्यथा अर्थहीन "[ऑब्जेक्ट ऑब्जेक्ट]" स्ट्रिंग को पारित कर देगा।

मुझे लगता है कि प्रतिक्रिया वास्तव में _is_ अपरिवर्तित मान को पारित कर रही है। कॉलिंग setAttribute('foo', {some: object}) में परिणाम [object Object] । जब तक आप प्रस्तावित नहीं कर रहे हैं कि वे वस्तु पर JSON.stringify() ? लेकिन तब वह वस्तु "अपरिवर्तित" नहीं होती है। मुझे लगता है कि शायद आप setAttribute() को ओवरराइड करने के लिए लेखक पर भरोसा कर रहे हैं? डीओएम को बंदर-पैच करने के बजाय उन्हें संबंधित जेएस गुण बनाने के लिए प्रोत्साहित करना अधिक व्यावहारिक हो सकता है।

मुझे लगता है कि प्रतिक्रिया वास्तव में _is_ अपरिवर्तित मान को पारित कर रही है। कॉलिंग setAttribute('foo', {some: object}) में परिणाम [object Object]

प्रतिक्रिया setAttribute में जाने से पहले एक स्ट्रिंग के लिए मूल्यों को मजबूर कर रही है:

https://github.com/facebook/react/blob/4d6540893809cbecb5d7490a77ec7ad32e2aeeb3/packages/react-dom/src/client/DOMPropertyOperations.js#L136

तथा

https://github.com/facebook/react/blob/4d6540893809cbecb5d7490a77ec7ad32e2aeeb3/packages/react-dom/src/client/DOMPropertyOperations.js#L166

मैं मूल रूप से आपके द्वारा कही गई सभी बातों से सहमत हूं।

हम इस बात से सहमत हैं कि लोग चीजों को दोनों तरह से कर रहे हैं, और ऐसा कोई मानक नहीं है जो हर किसी को इसे सिर्फ एक या दूसरे तरीके से करने के लिए मजबूर करता है, इसलिए मुझे अभी भी लगता है

• विकल्प 3 setAttribute डिफ़ॉल्ट रूप से उपयोग किया जाता है और उदाहरण गुणों का उपयोग करने के लिए निर्दिष्ट करने के लिए एक सतर्क,
• # १००७० के लिए एक फिक्स के साथ ताकि रिएक्ट स्ट्रिंग्स के लिए ज़बरदस्ती न करे,
• और विकल्प 5, ठीक ट्यूनिंग के लिए एक एपीआई

यदि विकल्प 5 अच्छी तरह से किया जाता है, तो एसएसआर समाधानों के लिए हाइड्रेशन डेटा को विशेषताओं या प्रॉप्स में मैप कर सकता है जैसा कि विकल्प 5 एपीआई के उपयोग द्वारा निर्दिष्ट किया जा सकता है।

प्रतिक्रिया setAttribute में जाने से पहले एक स्ट्रिंग के लिए मूल्यों को मजबूर कर रही है

अच्छा ऐसा है। चूंकि अधिकांश लोग एक कस्टम toString() को परिभाषित नहीं करते हैं, यह डिफ़ॉल्ट रूप से [object Object] ।

चूंकि अधिकांश लोग एक कस्टम toString() को परिभाषित नहीं करते हैं, यह डिफ़ॉल्ट रूप से [object Object] ।

ठीक वैसे ही अगर मैं करता हूँ

const div = document.createElement('div')
div.setAttribute('foo', {a:1, b:2, c:3})

परिणाम है

<div foo="[object Object]"></div>

स्पष्ट रूप से एक वेब डेवलपर के रूप में हमें पता होना चाहिए कि जब हम एक गैर-स्ट्रिंग को तत्व विशेषताओं में पास करते हैं तो क्या होता है। उदाहरण के लिए मुझे पता है कि मैं गैर-स्ट्रिंग को ए-फ़्रेम तत्वों में पास कर सकता हूं, और मुझे पुस्तकालय के रास्ते में आने के बिना ऐसा करने के लिए स्वतंत्र होना चाहिए।

प्रतिक्रिया को यह महसूस करने की आवश्यकता है कि यह भगवान नहीं है, अन्य कई पुस्तकालय हैं जिनका उपयोग लोग प्रतिक्रिया के अलावा करते हैं

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

@sebmarkbage इसके बारे में क्षमा करें, मेरा मतलब बिल्कुल भी

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

रिएक्ट वर्तमान में तत्व विशेषताओं को दिए गए सभी मानों को स्ट्रिंग्स में परिवर्तित करता है। अगर रिएक्ट ने ऐसा नहीं किया होता, उदाहरण के लिए, एफ्रेम-रिएक्शन (जो स्ट्रिंग समस्या के आसपास काम करता है) की कोई आवश्यकता नहीं होती।

अगर रिएक्ट हमें इस बारे में कोई विकल्प चुनने की क्षमता दे सकता है कि हम तत्वों को डेटा कैसे पास करते हैं, जैसे कि सादे जावास्क्रिप्ट में, तो यह मुझे सबसे संतुष्ट उपयोगकर्ता बना देगा। मैं

फिर से, वहाँ मेरे शब्दों के चयन के लिए खेद है। मैं अगली बार इसे दोबारा सोचूंगा।

मैंने इसके लिए RFC PR में एक टिप्पणी जोड़ी है। मुझे लगता है कि यह चर्चा के लायक है क्योंकि इसमें प्रस्तावित किया जा रहा है और साथ ही एक कस्टम तत्व और उसके गुणों का विश्वसनीय रूप से अनुमान लगाने के लिए एक सरल मॉडल शामिल है। यह इसे वापस एक हाइब्रिड दृष्टिकोण में बदल देता है, लेकिन अधिकांश उपयोग के मामलों के लिए एकीकरण का एक शून्य-कॉन्फ़िगरेशन तरीका प्रदान करता है।

मैं प्रतिक्रिया में लागू इस सुविधा को देखने के लिए उत्सुक हूं। रिएक्ट को बेहतरीन बनाने के आपके प्रयासों के लिए बहुत-बहुत धन्यवाद।

इस आरएफसी पर कोई अपडेट?

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

इस मुद्दे पर कोई अपडेट?

मैं भी हैक्स का सहारा लिए बिना कस्टम एलिमेंट लाइब्रेरी का उपयोग करना पसंद करूंगा। मैं चाहूंगा कि इस मुद्दे का समाधान हो जाए।

@mgolub2 रिएक्ट टीम इस बात की परवाह नहीं करती कि वेब समुदाय क्या चाहता है। वेब घटक अब व्यापक रूप से समर्थित मानक हैं, और 2 वर्षों के बाद इस मानक का समर्थन करने के लिए टीम की ओर से किसी प्रकार के संकेत नहीं हैं।

सभी को नमस्कार, मैंने दो पंक्तियों को बदलकर इस समस्या को ठीक करने के लिए एक पुल अनुरोध शुरू किया: https://github.com/facebook/react/pull/16899

यह एक कस्टम तत्व लेखक को निम्न की तरह कुछ करने की अनुमति देता है:

class MyElement extends HTMLElement {
  setAttribute(name, value) {
    // default to existing behavior with strings
    if (typeof value === 'string')
      return super.setAttribute(name, value)

    // but now a custom element author can decide what to do with non-string values.
    if (value instanceof SomeCoolObject) { /*...*/ }
  }
}

विस्तारित setAttribute विधि कैसी दिख सकती है, इस पर कई भिन्नताएं हैं, यह केवल एक छोटा सा उदाहरण है।

प्रतिक्रिया टीम, आप तर्क दे सकते हैं कि कस्टम तत्व लेखकों को ऐसा नहीं करना चाहिए, क्योंकि वे कुछ मामलों में डोम की मूल विशेषता हैंडलिंग को बायपास करते हैं (फी जब मान स्ट्रिंग नहीं होते हैं)। यदि आपके पास यह राय है, तो इसका मतलब यह नहीं है कि आपको इस बात में बाधा डालनी चाहिए कि कस्टम तत्व लेखक अपने __ कस्टम __ तत्वों के साथ क्या कर सकते हैं।

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

आप लेखक के डेटा को क्यों बदलना चाहते हैं? आप यह क्यों नहीं मान सकते हैं कि जो व्यक्ति डीओएम में हेरफेर करना चाहता है वह जानता है कि डीओएम को कौन सा डेटा पास करना है?

@trusktr मुझे लगता है कि इस पर https://github.com/facebook/react/issues/10070 में चर्चा की गई थी

मैं वास्तव में कस्टम तत्व लेखकों को setAttribute जैसी अंतर्निहित विधि को ओवरराइड करने के लिए कहने के खिलाफ लोगों को सावधान करता हूं। मुझे नहीं लगता कि यह हमारे लिए मंकी पैच करने का इरादा है। cc @gaearon

इस तरह के उपवर्गों में setAttribute को ओवरराइड करना हानिरहित है (यह बंदर पैचिंग नहीं है)। लेकिन जैसा कि मैंने उल्लेख किया है, रिएक्ट को उस पर निर्देश क्यों देना पड़ता है, अगर यह जरूरी नहीं कि रिएक्ट लिब का काम हो। हम DOM (बिना बाधा के) में हेरफेर करने के लिए रिएक्ट का उपयोग करना चाहते हैं।

अगर मुझे प्रदर्शन को बढ़ावा देने के लिए मैन्युअल रूप से el.setAttribute() करना है, तो यह भी देव अनुभव को और खराब कर देता है।

मुझे नहीं लगता कि रिएक्ट टीम setAttribute में पारित किसी भी चीज़ को स्ट्रिंग्स में परिवर्तित करके कई लोगों को किसी बड़े जोखिम से बचा रही है।

मैं सहमत हूं कि एक और समाधान बेहतर हो सकता है। उदाहरण के लिए, कुछ नए सिंटैक्स के लिए JSX स्पेक को अपडेट करना, लेकिन ऐसा लगता है कि इसमें लंबा समय लगता है।

यदि हम स्वचालित स्ट्रिंग रूपांतरण को हटा देते हैं तो समुदाय क्या खो देता है? रिएक्ट टीम क्या खोती है?

रिएक्ट टीम बेहतर समाधान के साथ बाद में स्थिति में सुधार कर सकती है...

क्यों न कम से कम हमें केवल स्ट्रिंगिफिकेशन को बायपास करने का विकल्प दिया जाए? क्या ऐसा कुछ है जिस पर आप विचार करने को तैयार हो सकते हैं?

मैं वास्तव में कस्टम तत्व लेखकों को setAttribute जैसी अंतर्निहित विधि को ओवरराइड करने के लिए कहने के खिलाफ लोगों को सावधान करता हूं।

क्या आप इसका कोई अच्छा कारण बता सकते हैं कि ऐसा क्यों है?

यह एक लाल हेरिंग की तरह लगता है। "अपने तत्व के लिए विशिष्ट व्यवहार के साथ एक विधि संलग्न करने के लिए कस्टम तत्वों को लिखने वाले सभी को समझाएं" इस मुद्दे का समाधान नहीं है, जो कि डीओएम तत्वों पर गुणों को कैसे सेट करें, इसके बारे में है।

@trusktr

क्या आप इसका कोई अच्छा कारण बता सकते हैं कि ऐसा क्यों है?

वेब घटक एक मानक हैं। इसलिए, मानक के व्युत्पन्न मानक-अनुपालन भी होने चाहिए।

हालांकि, setAttribute को ओवरराइड करना इस शर्त के अनुकूल नहीं है: यह केवल रिएक्ट के लिए एक हैक बनाता है जबकि बहुत सारे अन्य फ्रेमवर्क हैं जो बॉक्स से बाहर वेब घटकों के साथ काम करते हैं। इसलिए, जब वे रिएक्ट के साथ बिल्कुल भी काम नहीं करते हैं, तब भी उन्हें रिएक्ट हैक का उपभोग करने की आवश्यकता होगी। मुझे नहीं लगता कि यह सही समाधान है।

इसके बाद, यह सर्वविदित है कि मानक तरीकों को पैच करना एक गलत तरीका है। setAttribute ओवरराइड करने से मूल व्यवहार बदल जाता है जो अंतिम उपयोगकर्ताओं को भ्रमित कर सकता है जब वे इसका उपयोग करने का प्रयास करते हैं। हर कोई मानक के रूप में काम करने की अपेक्षा करता है, और कस्टम तत्व कोई अपवाद नहीं है क्योंकि यह HTMLElement व्यवहार को इनहेरिट करता है। और जबकि यह रिएक्ट के साथ काम कर सकता है, यह अन्य सभी उपयोगकर्ताओं के लिए एक जाल बनाता है। उदाहरण के लिए, जब वेब घटकों का उपयोग बिना किसी ढांचे के किया जाता है, तो setAttribute को बहुत कुछ कहा जा सकता है। मुझे संदेह है कि कस्टम तत्व डेवलपर्स इस दृष्टिकोण के साथ अपने पैर को शूट करने के लिए सहमत होंगे।

व्यक्तिगत रूप से, मुझे लगता है कि किसी प्रकार का रिएक्ट रैपर अधिक आशाजनक लगता है।

हे दोस्तों, इस बीच जब हम प्रतीक्षा करते हैं, मैंने रिएक्ट में आपके वेब घटक को लपेटने के लिए एक शिम बनाया है https://www.npmjs.com/package/reactify-wc

import React from "react";
import reactifyWc from "reactify-wc";

// Import your web component. This one defines a tag called 'vaadin-button'
import "@vaadin/vaadin-button";

const onClick = () => console.log('hello world');

const VaadinButton = reactifyWc("vaadin-button");

export const MyReactComponent = () => (
  <>
    <h1>Hello world</h1>
    <VaadinButton onClick={onClick}>
      Click me!
    </VaadinButton>
  </>
)

मुझे आशा है कि यह मददगार साबित होगा

(यह ओएसएस में मेरा पहला प्रवेश है, और मेरे कार्यालय से बाहर किसी चीज की पहली ओपन सोर्सिंग में से एक है। रचनात्मक आलोचना स्वागत से अधिक है 😄)

हे दोस्तों, इस बीच जब हम प्रतीक्षा करते हैं, मैंने रिएक्ट में आपके वेब घटक को लपेटने के लिए एक शिम बनाया है https://www.npmjs.com/package/reactify-wc

import React from "react";
import reactifyWc from "reactify-wc";

// Import your web component. This one defines a tag called 'vaadin-button'
import "@vaadin/vaadin-button";

const onClick = () => console.log('hello world');

const VaadinButton = reactifyWc("vaadin-button");

export const MyReactComponent = () => (
  <>
    <h1>Hello world</h1>
    <VaadinButton onClick={onClick}>
      Click me!
    </VaadinButton>
  </>
)

मुझे आशा है कि यह मददगार साबित होगा

(यह ओएसएस में मेरा पहला प्रवेश है, और मेरे कार्यालय से बाहर किसी चीज की पहली ओपन सोर्सिंग में से एक है। रचनात्मक आलोचना स्वागत से अधिक है 😄)

बढ़िया रैपर :)

यह भी उल्लेखनीय है कि स्टैंसिल के साथ वेब घटकों का निर्माण प्रतिक्रिया के साथ इस समस्या को हल करता है: https://stenciljs.com/docs/faq#can -data-be-passed-to-web-components-

@matsgm मुझे खुशी है कि स्टैंसिल के साथ निर्माण ने आपके लिए काम किया है। हालांकि, सावधानी के एक शब्द के रूप में, हमारे अनुभव में स्टैंसिल ने अन्य वेब घटक ढांचे, विशेष रूप से पॉलिमर के साथ अच्छी तरह से खेलने के लिए साबित नहीं किया है, और हम उनके निर्माण उपकरण, समर्थन और सामान्य कार्यक्षमता के बीच आधा दर्जन अन्य मुद्दों से नाराज हैं। आपकी माइलेज भिन्न हो सकती है :)

बस इस सूत्र के साथ अप-टू-डेट रहने की कोशिश कर रहा हूं। अंतिम समाधान क्या है?

एक तरह से मैं जादू के अनुमानों के बजाय स्पष्ट परिभाषित एटीआर, प्रोप, घटना का बहुत बड़ा प्रशंसक हूं जो बहुत भ्रमित हो सकता है।

जैसे snabbdom स्पष्ट शीर्ष स्तरीय नेमस्पेसिंग का उपयोग करता है, इससे यह जानना आसान हो जाता है कि क्या जाता है। कोई स्ट्रिंग हेरफेर नहीं है जो निष्पादित करने के लिए तेज़ है जैसे onClick => click से प्रत्यय को ट्रिम करना अभी भी एक पूर्ण हिट है।

<input attrs={{placeholder: `heyo`}} style={{color: `inherit`}} class={{hello: true, world: false}} on={{click: this.handleClick}} props={{value: `blah`}} />

attr = (attr, val) => elem.setAttribute(attr, val);
prop = (prop, val) => elem[prop] = val;
on  = (event, handler) => elem.addEventListener(event, handler)
style = (prop, val) => elem.style[prop] = val;
class = (name, isSet) => isSet ? elem.classList.add(name) : elem.classList.remove(val)
dataset = (key, val) => elem.dataset[key] = val;

मेरी इच्छा है कि JSX डॉट सिंटैक्स के साथ नेमस्पेसिंग का समर्थन करे। इसका मतलब है कि प्रॉप्स डिफ़ॉल्ट नेमस्पेस होगा और हम बस लिख सकते हैं

<div tabIndex={-1} attr.title={"abcd"} on.click={handler} style.opacity={1} class.world={true} />`

fyi @sebmarkbage ^

const whatever = 'Whatever';
const obj = { a: 1, b: 2 };
const reactComponent = (props) => (
<div>
  ...
  <custom-element attr="{whatever}" someProp={obj} />
  { /* double quotes for attributes */ }
  { /* no quotes for properties */ }
</div>
);

यह रिएक्ट JSX प्राग्मा पार्सर को संशोधित करके प्राप्त किया जा सकता है।

अतिरिक्त विकल्प propeties (या प्रतिक्रिया प्रशंसकों के लिए props ) को संपत्ति पासिंग के लिए निर्दिष्ट शब्द के रूप में रखना है

चूंकि आज १७.० जारी किया गया है, क्या हम इस मुद्दे को अपडेट कर सकते हैं ताकि यह पता चल सके कि इसे कब संबोधित किया जाएगा?

हां। हमने मूल रूप से रिएक्ट 17 को रिलीज़ करने की योजना बनाई थी जिसमें बहुत अधिक पदावनत हटा दिए गए थे (और नई सुविधाओं के साथ)। हालांकि, पुराने कोडबेस के लिए अपने सभी कोड को अपडेट करना बहुत यथार्थवादी नहीं है, और यही कारण है कि हमने रिएक्ट 17 को बाहर निकालने का फैसला किया है जो केवल एक महत्वपूर्ण ब्रेकिंग परिवर्तन पर केंद्रित है (घटनाएं दस्तावेज़ के बजाय रूट तत्व से जुड़ी हैं) ) ऐसा इसलिए है ताकि पुराने ऐप्स हमेशा के लिए रिएक्ट 17 पर बने रह सकें और केवल उनके कुछ हिस्सों को 18+ पर अपडेट कर सकें।

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

मुझे यकीन नहीं है कि WC समुदाय की नवीनतम आम सहमति क्या है जिस पर इनमें से कौन सा विकल्प बेहतर है। हालांकि उन सभी को नीचे लिखा जाना बहुत मददगार है (उस काम को करने के लिए @robdodson के लिए बड़ा सहारा)। मुझे इस बात की उत्सुकता है कि क्या इस धागे के लिखे जाने के बाद से इन विकल्पों पर लोगों की राय विकसित हुई है, और यदि कोई नई जानकारी है जो हमें दिशा चुनने में मदद कर सकती है।

मुझे नहीं लगता कि WC समुदाय ने अपना पसंदीदा विकल्प बदल दिया है, जो अभी भी विकल्प 3 है। @Developit इस बारे में अधिक बात कर सकता है कि Preact कस्टम तत्वों के साथ कैसे संगत है, जो React के लिए भी दिलचस्प हो सकता है। कस्टम तत्वों में पासिंग (जटिल) डेटा के साथ फ्रेमवर्क कैसे संगत हैं, इसके सामान्य अवलोकन के लिए, https://custom-elements-everywhere.com/ में सभी विवरण हैं।

ध्यान दें कि https://github.com/vuejs/vue/issues/7582 में , Vue ने सिगिल का उपयोग करना चुना, और उन्होंने "।" उपसर्ग के रूप में (ग्लिमर का "@" नहीं)।

https://github.com/vuejs/vue/issues/7582#issuecomment -362943450 में, @trusktr ने सुझाव दिया कि सबसे सही SSR कार्यान्वयन SSR'd HTML में विशेषताओं के रूप में sigil'd गुणों को प्रस्तुत नहीं करना होगा, और इसके बजाय उन्हें हाइड्रेशन के दौरान जेएस के माध्यम से गुणों के रूप में सेट करें।

मुझे लगता है कि यह बहुत कम संभावना है कि हम अकेले इस विशेष सुविधा के लिए नया JSX सिंटैक्स पेश करेंगे।

एक सवाल यह भी है कि क्या यह विकल्प (3) करने लायक है, यदि विकल्प का अधिक सामान्य संस्करण (5) संभवतः मेज पर है। यानी विकल्प (5) कस्टम माउंट/अपडेट/अनमाउंट/हाइड्रेशन व्यवहार के साथ कस्टम निम्न-स्तरीय रिएक्ट नोड्स घोषित करने के लिए एक निम्न-स्तरीय तंत्र हो सकता है। कस्टम तत्वों के लिए भी विशिष्ट नहीं है (हालांकि वे उपयोग के मामलों में से एक होंगे)।

इस विशिष्ट सुविधा के लिए पूरी तरह से नया JSX सिंटैक्स पेश करने के बजाय, अधिक सामान्य JSX को पेश करने और कस्टम गुणों को परिभाषित करने के लिए इसका उपयोग करने के बारे में क्या?

मैंने बहुत समय पहले जेएसएक्स में ईसीएमएस्क्रिप्ट की गणना की गई संपत्ति वाक्यविन्यास जोड़ने का प्रस्ताव रखा था (फेसबुक/जेएसएक्स # 108) और लगता है कि यह सामान्य रूप से वाक्यविन्यास के लिए उपयोगी जोड़ होगा।

यदि कंप्यूटेड प्रॉपर्टी सिंटैक्स उपलब्ध था जो कंप्यूटेड प्रॉपर्टी सिंटैक्स और सिंबल या प्रीफ़िक्स्ड स्ट्रिंग्स का उपयोग करके गुणों को परिभाषित करने की संभावना को खुला छोड़ देगा।

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

import {property} from 'react';
// ...
<custom-img [property('src')]="corgi.jpg" [property('hiResSrc')]="[email protected]" width="100%">

@dantman यह प्रस्ताव सर्वर रेंडरिंग और हाइड्रेशन को कैसे हैंडल करता है?

मुझे नहीं लगता कि WC समुदाय में कोई भी विकल्प 5 चाहता है।

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

सर्वर रेंडरिंग और हाइड्रेशन पर आपकी क्या सोच है? यदि कोई स्पष्ट विन्यास नहीं है, तो कौन सा अनुमानी वांछनीय है? क्या डब्ल्यूसी समुदाय में यह आमतौर पर कैसे किया जाता है, इसमें कोई समेकन हुआ है? मैंने इस आरएफसी को फिर से पढ़ा और ऐसा लगता है कि यह इस विषय के बारे में विवरण में नहीं जा रहा है। लेकिन यह बहुत महत्वपूर्ण है, खासकर जब रिएक्ट सर्वर रेंडरिंग पर अधिक जोर देने की ओर बढ़ता है (क्योंकि इसकी अक्सर क्लाइंट-केंद्रित चूक के लिए सही आलोचना की जाती है)।

@gaearon मुझे यह जानने के लिए पर्याप्त जलयोजन और कस्टम गुण नहीं पता हैं कि क्या आवश्यक है, यह मुख्य रूप से एक वाक्यविन्यास प्रस्ताव है।

सामान्य विचार यह है कि property(propertyName) , इस पर निर्भर करते हुए कि आप इसे कैसे कार्यान्वित करना चाहते हैं, एक प्रीफ़िक्स्ड स्ट्रिंग (जैसे '__REACT_INTERNAL_PROP__$' + propertyName ) को आउटपुट कर सकता है या एक सिंबल बना सकता है और इसमें एक "सिंबल => प्रॉपर्टीनाम" एसोसिएशन को सहेज सकता है। नक्षा।

बाद में समस्याग्रस्त हो सकता है यदि आपको उस मानचित्र को क्लाइंट से संवाद करने की आवश्यकता है।

हालाँकि, मेरी समझ में आने वाले गुण कुछ ऐसे नहीं हैं जिन्हें आप सर्वर पर संभाल सकते हैं और हाइड्रेशन में क्लाइंट कोड शामिल है, इसलिए मुझे यकीन नहीं है कि इसके लिए क्या योजना है। जहां तक ​​मेरे प्रस्ताव का सवाल है, उस मुद्दे को हल करने के लिए आपके पास जो भी योजनाएं हैं, उन्हें संभवत: अनुकूलित किया जा सकता है। यदि ऐसा कुछ है जिसे आप सर्वर पर गुणों के साथ प्रतिक्रिया करने की योजना बना रहे हैं तो यह केवल ऐसा कर सकता है जब यह property द्वारा बनाई गई संपत्तियों में से एक को देखता है।

एक वेब घटक पुस्तकालय लेखक के रूप में, विकल्प 5 एक सुविधाजनक विकल्प नहीं है। मैं प्रत्येक ढांचे और घटक के लिए एक स्कीमा को स्पष्ट रूप से परिभाषित किए बिना कस्टम तत्व बनाना चाहता हूं। और कई कस्टम तत्व लेखक ऐसा नहीं करेंगे, जिससे रिएक्ट डेवलपर पर बोझ बढ़ जाएगा।

विकल्प 5 से कोई नहीं जीतता।

@claviska क्या आपके पास इस बारे में कोई राय है कि सर्वर प्रतिपादन और हाइड्रेशन को अधिक निहित दृष्टिकोणों के साथ कैसे काम करना चाहिए?

@gaearon SSR दो स्थितियों में उप-विभाजित होगा: वे जहाँ कस्टम तत्व SSR का समर्थन करता है और जहाँ यह नहीं करता है।

उन तत्वों के लिए जो SSR का समर्थन नहीं करते हैं, सर्वर पर गुण सेट करना कोई मायने नहीं रखता। id और className जैसे अंतर्निहित प्रतिबिंबित गुणों को छोड़कर, उन्हें छोड़ा जा सकता है और केवल क्लाइंट पर लिखा जा सकता है।

एसएसआर गुणों का समर्थन करने वाले तत्वों के लिए मायने रखता है, लेकिन केवल इसलिए कि वे डीओएम पर जो भी परिणाम उत्पन्न करते हैं उन्हें ट्रिगर कर सकते हैं। इसके लिए एक तत्व उदाहरण या किसी प्रकार का SSR प्रॉक्सी/स्टैंड-इन, और SSR'ed DOM स्थिति को संप्रेषित करने के लिए कुछ प्रोटोकॉल की आवश्यकता होती है। इस प्रक्रिया के लिए अभी तक कोई सामान्य सर्वर-साइड इंटरफ़ेस नहीं है, इसलिए यहाँ वास्तव में अभी कुछ भी नहीं करना है। वेब घटक लेखकों और पुस्तकालय अनुरक्षकों को किसी भी पुल का निर्माण करने के लिए रिएक्ट के लिए व्यवहार्य होने से पहले कुछ चीजों का पता लगाने की आवश्यकता होगी।

एसएसआर पर मेरी टीम के काम में हमने createElement को पैच करके और dangerouslySetInnerHTML का उपयोग करके रिएक्ट के साथ एकीकृत किया है। मुझे लगता है कि यह एकीकरण/प्रयोग का स्तर है जिस पर हम थोड़े समय के लिए रहेंगे। जल्द ही मुझे उम्मीद है कि हम SSR सिस्टम के भीतर इंटरऑप के लिए कुछ उपयोगकर्ता-भूमि प्रोटोकॉल पर अभिसरण कर सकते हैं। तब तक _deep_ SSR के बिना कस्टम एलीमेंट प्रॉपर्टी और इवेंट सपोर्ट होना पूरी तरह से सुरक्षित और विवेकपूर्ण है। तत्व का टैग अभी भी एक प्रतिक्रिया घटक के बच्चे के रूप में SSR'ed होगा जैसा कि आज है।

आईडी और क्लासनाम जैसे अंतर्निहित प्रतिबिंबित गुणों को छोड़कर, उन्हें छोड़ा जा सकता है और केवल क्लाइंट पर लिखा जा सकता है।

क्या आप मुझे यह समझने में मदद कर सकते हैं कि यह कैसे काम करता है? उदाहरण के लिए कहें कि <github-icon iconname="smiley" /> । क्या आपका मतलब है कि SSR को HTML प्रतिक्रिया में केवल <github-icon /> शामिल करना चाहिए, और फिर प्रतिक्रिया जलयोजन के दौरान domNode.iconname = ... सेट करेगी? उस स्थिति में, मुझे यकीन नहीं है कि मैं समझता हूं कि क्या होता है यदि कस्टम तत्व कार्यान्वयन प्रतिक्रिया हाइड्रेशन होने से पहले लोड हो जाता है। github-icon कार्यान्वयन को कैसे पता चलेगा कि HTML में iconname मौजूद नहीं होने पर कौन सा आइकन प्रस्तुत करना है?

इस प्रक्रिया के लिए अभी तक कोई सामान्य सर्वर-साइड इंटरफ़ेस नहीं है, इसलिए यहाँ वास्तव में अभी कुछ भी नहीं करना है। वेब घटक लेखकों और पुस्तकालय अनुरक्षकों को किसी भी पुल का निर्माण करने के लिए रिएक्ट के लिए व्यवहार्य होने से पहले कुछ चीजों का पता लगाने की आवश्यकता होगी।

मैं उत्सुक हूं कि क्या विशेष रूप से ऐसा कुछ है जो समुदाय के लिए यहां आम सहमति बनाने के लिए होना चाहिए। क्या रिएक्ट इसे वापस रखने वाला है? मैं 2017 से इस मुद्दे के खुले होने से जुड़ी निराशा को बहुत अच्छी तरह समझता हूं। दूसरी तरफ, तीन साल हो गए हैं, और मुझे लगता है कि आप कह रहे हैं कि यह आम सहमति अभी तक नहीं बनी है। ऐसा होने के लिए पूर्वापेक्षाएँ क्या हैं? क्या यह सिर्फ अधिक प्रयोग की बात है?

@gaearon यदि रिएक्ट हाइड्रेशन होने से पहले कस्टम तत्व कार्यान्वयन लोड होता है, तो यह iconname विशेषता के डैफॉल्ट मान को जो कुछ भी असाइन करेगा। आपका क्या मतलब है if _iconname_ does not exist in the HTML ? यदि HTMLElement प्रकार में कोई विशेषता परिभाषित नहीं है, तो यह इसे अनदेखा कर देगा। एक बार कस्टम तत्व परिभाषा लोड होने के बाद, यह HTMLElement प्रकार का विस्तार करेगा और iconname को परिभाषित करेगा और पारित होने वाले नए मान पर प्रतिक्रिया करने में सक्षम होगा।

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

मेरी अब तक की समझ यह है कि:

1. वे प्रारंभिक रेंडर परिणाम देखते हैं। इसमें सभी सामान्य मार्कअप शामिल होंगे, लेकिन वे <github-icon> कस्टम तत्व बिल्कुल नहीं देखेंगे। संभवतः यह एक खाली डिव की तरह एक छेद होगा। मुझे सही जवाब दो अगर मैं गलत हूँ (?)। इसका कार्यान्वयन अभी तक लोड नहीं हुआ है।

2. <github-icon> कस्टम तत्व कार्यान्वयन लोड होता है और यह पंजीकृत हो जाता है। अगर मैं सही ढंग से समझूं, तो यह "अपग्रेडिंग" नामक प्रक्रिया है। हालाँकि, भले ही इसका JS तैयार है, फिर भी यह कुछ भी नहीं दिखा सकता है क्योंकि हमने HTML में iconname शामिल नहीं किया है। इसलिए हमारे पास यह जानकारी नहीं है कि किस आइकन को प्रस्तुत करना है। ऐसा इसलिए है क्योंकि हमने पहले कहा था कि "गैर-बिलिन गुणों को HTML से हटाया जा सकता है"। तो उपयोगकर्ता अभी भी एक "छेद" देखता है।

3. प्रतिक्रिया और एप्लिकेशन कोड लोड होता है। हाइड्रेशन होता है। हाइड्रेशन के दौरान, रिएक्ट .iconname = संपत्ति को अनुमान के अनुसार सेट करता है। उपयोगकर्ता अब आइकन देख सकता है।

क्या यह उस मामले के लिए एक सही ब्रेकडाउन है जहां कस्टम तत्व जेएस कार्यान्वयन पहले लोड होता है? क्या यह व्यवहार WC समुदाय के लिए वांछनीय है?

@gaearon हाँ, मैं इस स्थिति में ऐसा होने की उम्मीद करूंगा।

दूसरी ओर, तीन साल हो गए हैं, और मुझे लगता है कि आप कह रहे हैं कि यह आम सहमति अभी तक नहीं बनी है

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

मैंने पहले इस अंतर को नहीं देखा है (गहरा बनाम उथला) इसलिए मुझे यह जांचने के लिए इसे पुन: स्थापित करने का प्रयास करें कि क्या मैंने आपको समझा है।

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

"नॉट डीप" एसएसआर द्वारा, मुझे लगता है कि आप कह रहे हैं कि हमने सीई टैग को ही एचटीएमएल में डाल दिया है। यह चिंता किए बिना कि यह क्या हल करता है। यह मुझे भी समझ में आता है। मेरा प्रश्न हालांकि _this_ प्रवाह के बारे में था - "गहरे" SSR के बारे में नहीं।

विशेष रूप से, https://github.com/facebook/react/issues/11347#issuecomment -७१३२३०५७२ एक ऐसी स्थिति का वर्णन करता है जहां हमारे पास _पहले से ही CE लॉजिक डाउनलोड होने पर भी, हम हाइड्रेशन तक उपयोगकर्ता को कुछ भी नहीं दिखा सकते हैं। इसके गुण तब तक अज्ञात रहते हैं जब तक कि पूरे एप्लिकेशन का JS क्लाइंट कोड लोड और हाइड्रेशन नहीं हो जाता। मैं पूछ रहा हूं कि क्या यह वास्तव में वांछित व्यवहार है।

मुझे नहीं लगता कि यह मेरे दृष्टिकोण से एक अस्पष्ट चिंता है। मैं सुविधा अनुरोध को गलत नहीं समझना चाहता। तो निर्दिष्ट सटीक शब्दार्थ प्राप्त करने से मुझे इस प्रस्ताव का मूल्यांकन करने में मदद मिलेगी। उदाहरण के लिए एक व्यावहारिक चिंता यह है कि रिएक्ट वास्तव में आज हाइड्रेशन के दौरान उत्पादन में विशेषताओं/गुणों को अलग नहीं करता है क्योंकि किसी भी अंतर्निर्मित घटकों को इसकी आवश्यकता नहीं होती है। लेकिन यह कुछ ऐसा है जिसे हम इस विशेष मामले के लिए जोड़ सकते हैं यदि इसकी वास्तव में आवश्यकता है।

@gaearon

मुझे लगता है कि https://github.com/facebook/react/issues/11347#issuecomment -713230572 सबसे अच्छा उदाहरण मामला नहीं हो सकता है जिसमें इस सुविधा की आवश्यकता है।

कम से कम मेरे अनुभव में, गुणों के बजाय गुण सेट करना स्ट्रिंग, संख्या या बूलियन जैसे सरल प्रकारों के लिए आवश्यक नहीं है।

आपके द्वारा वर्णित मामले को सीधे एक विशेषता के रूप में iconname का उपयोग करके आसानी से प्राप्त किया जा सकता है और यह अभी भी हाइड्रेशन की प्रतीक्षा किए बिना समान रूप से अंतिम रूप से प्रदान किया गया परिणाम होगा।

NSकस्टम तत्व कार्यान्वयन लोड होता है और यह पंजीकृत हो जाता है। अगर मैं सही ढंग से समझूं, तो यह "अपग्रेडिंग" नामक प्रक्रिया है। हालाँकि, भले ही इसका JS तैयार है, फिर भी यह कुछ भी नहीं दिखा सकता है क्योंकि हमने HTML में iconname शामिल नहीं किया है। इसलिए हमारे पास यह जानकारी नहीं है कि किस आइकन को प्रस्तुत करना है। ऐसा इसलिए है क्योंकि हमने पहले कहा था कि "गैर-बिलिन गुणों को HTML से हटाया जा सकता है"। तो उपयोगकर्ता अभी भी एक "छेद" देखता है।

जैसा कि आप यहां उल्लेख करते हैं, इस पर निर्भर करता है कि घटक कैसे कार्यान्वित किया जाता है, आप "छेद" देखने की इस समस्या से बच सकते हैं।

यह या तो इस मामले में केवल सादा सेटिंग डिफ़ॉल्ट द्वारा या स्लॉट के माध्यम से भाग या यहां तक ​​​​कि अधिकांश सामग्री को स्वीकार करके प्राप्त किया जा सकता है ताकि घटक अपग्रेड होने से पहले ही सामग्री प्रदर्शित हो।

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

एक उदाहरण के लिए, lit-virtualizer वर्चुअल स्क्रोलर घटक लें।

इसके लिए ठीक से काम करने के लिए इसे items सरणी और renderItem फ़ंक्शन की आवश्यकता होती है और आप वैकल्पिक रूप से scrollTarget तत्व भी सेट कर सकते हैं, जिनमें से सभी को केवल रेफरी का उपयोग करके रिएक्ट में सेट किया जा सकता है तुरंत।

इस तरह के मामले के लिए, आप शायद सामग्री को किसी प्रकार के पेजिनेशन या आलसी लोडिंग के साथ लोड कर रहे होंगे, इसलिए किसी भी सामग्री को तब तक नहीं रखना जब तक कि एसएसआर मामले पर हाइड्रेशन चरण समस्याग्रस्त न हो।

@gaearon कृपया ध्यान दें कि कस्टम तत्व एक डीओएम मानक हैं और इसलिए प्रति "डब्ल्यूसी समुदाय" इस अर्थ में नहीं है कि कस्टम तत्वों का उपयोग करने वाले सभी लोग उसी तरह उनका उपयोग करते हैं। कस्टम तत्व प्रत्येक डेवलपर के लिए अपने तरीके से एकीकृत होते हैं, क्योंकि वे स्वाभाविक रूप से एक निम्न-स्तरीय आदिम होते हैं जिन पर लोग निर्माण करते हैं।

उस ने कहा, समय के साथ कई पैटर्न सामने आए हैं और सभी लोकप्रिय ढांचे (रिएक्ट को छोड़कर) इस डोम मानक के लिए संगतता प्रदान करने के लिए कुछ समाधान लागू करते हैं। जैसा कि आप https://custom-elements-everywhere.com/ पर देख सकते हैं, सभी फ्रेमवर्क/लाइब्रेरी (रिएक्ट को छोड़कर) ने अलग-अलग विकल्प चुने हैं। इस अंक में, चुने गए विकल्पों को विकल्प 1, 2 और 3 के रूप में सूचीबद्ध किया गया है। कोई ढांचा/पुस्तकालय नहीं है जो वर्तमान में विकल्प 4 या 5 को लागू करता है और मुझे नहीं लगता कि इन्हें लागू करना वांछनीय है।

इसलिए, मैं प्रस्ताव करता हूं कि रिएक्ट अन्य ढांचे/पुस्तकालयों के अनुरूप है और एक विकल्प चुनता है जो काम कर रहा है, उदाहरण के लिए विकल्प 1-3 में से। मुझे नहीं लगता कि रिएक्ट को विकल्प 4 या 5 चुनकर पहिया को फिर से शुरू करने की आवश्यकता है, जिसके लिए हमारे पास कोई डेटा नहीं है, जो रिएक्ट या डीओएम मानकों पर निर्माण करने वालों के लिए दीर्घकालिक रखरखाव योग्य समाधान है।

इसलिए, उन्मूलन की प्रक्रिया से (नीचे लिंक की गई टिप्पणियों के साथ), चूंकि विकल्प 3 JSX के लिए नहीं किया जा रहा है और विकल्प 4 और 5 को इस धागे में WC लोगों द्वारा अवांछनीय चिह्नित किया गया है, हम 1 या 2 के साथ फंस गए हैं .

और चूंकि 1 ऐसा लगता है कि इसमें अस्थिर कमियां हैं, ऐसा लगता है कि विकल्प 2 एक है? प्रीएक्ट यह कैसे करता है इसके साथ जाओ?

कोई ढांचा/पुस्तकालय नहीं है जो वर्तमान में विकल्प 4 या 5 को लागू करता है और मुझे नहीं लगता कि इन्हें लागू करना वांछनीय है।

( @TimvdLippe https://github.com/facebook/react/issues/11347#issuecomment-713474037) में

मुझे लगता है कि यह बहुत कम संभावना है कि हम अकेले इस विशेष सुविधा के लिए नया JSX सिंटैक्स पेश करेंगे।

( @gaearon https://github.com/facebook/react/issues/11347#issuecomment-713210204 में)

यह मेरे लिए हाँ समझ में आता है। सारांश के लिए धन्यवाद! मैं

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

मैं काफी फॉलो नहीं कर रहा हूं। मेरे काल्पनिक परिदृश्य के लिए एक प्रतिक्रिया थी https://github.com/facebook/react/issues/11347#issuecomment जो एक सुझाव है कि हम नहीं करना चाहिए फेंकना सब पर सर्वर द्वारा जेनरेट HTML में गुण, के अलावा तरह लग रहा था -+७१,३२,२३,६२८

1. मेरे द्वारा वर्णित परिदृश्य में सर्वर-जनरेटेड HTML में वास्तव में क्या क्रमबद्ध होता है
   ए। मामले में <github-icon iconname="smiley" />
   बी। मामले में आप लाए हैं, उदाहरण के लिए <github-icon icon={{ name: "smiley" }} />
2. इनमें से किसी भी मामले में हाइड्रेशन के दौरान क्लाइंट पर DOM API को क्या कहा जाता है

धन्यवाद!

क्या इसे एक कस्टम कार्यान्वयन के साथ React.createElement() जगह एक शिम बनाने का विकल्प माना जाता था, जो अंदर गुण मैपिंग करता है?

उपयोग उदाहरण:

/** <strong i="8">@jsx</strong> h */
import { h } from 'react-wc-jsx-shim';

function Demo({ items }) {
   return <my-custom-list items={items} />
}

मसौदा कार्यान्वयन:

export function h(element, props, children) {
   if(typeof element === 'string' && element.includes('-')) {
      return React.createElement(Wrapper, { props, customElementName: element }, children)
   }
   return React.createElement(element, props, children);

}

function Wrapper({customElementName, props}) {
   const ref = React.useRef();
   React.useEffect(() => {
      for(const prop in props) {
         ref.current[prop] = props[prop];
      }
   });
   return React.createElement(customElementName, { ref, ...props });
}

मुझे पता है कि यह एक अंतर्निहित सुविधा नहीं है, लेकिन मुझे लगता है कि बहुत कम ओवरहेड वाले उपयोगकर्ताओं को अनब्लॉक करना चाहिए।

@ जस्ट-बोरिस जो मूल रूप से ऐप या लाइब्रेरी अब करते हैं, या तो createElement पैच या एक रैपर के साथ। आपको रिएक्ट में विशेष-आवरण वाले संपत्ति नामों को भी बाहर करना होगा। मुझे नहीं लगता कि कोई निर्यात की गई सूची है, इसलिए वे ['children', 'localName', 'ref', 'elementRef', 'style', 'className'] जैसे एक इनकार सूची को हार्ड कोड करते हैं।

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

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

क्या इसे एक कस्टम कार्यान्वयन के साथ React.createElement() की जगह एक शिम बनाने का विकल्प माना जाता था, जो अंदर गुण मैपिंग करता है?

जैसा कि मूल अंक में रॉब द्वारा उल्लेख किया गया है, मैंने अतीत में https://github.com/skatejs/val के माध्यम से इसका प्रयोग किया है, इसलिए एक कस्टम JSX प्राग्मा होना जो React.createElement को लपेटता है एक व्यवहार्य है - संभवतः अल्पकालिक - समाधान।

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

मैं अब ओपन सोर्स में ज्यादा काम नहीं करता, और न ही अब ट्विटर करता हूं, इसलिए बेझिझक मेरी राय नमक के दाने के साथ लें।

विकल्प 1 ऐसा महसूस करता है कि यह विकल्प 2 के लिए शैतान के वकील के रूप में मौजूद है।

विकल्प 2 जाने का रास्ता लगता है। यह प्रीएक्ट ने जो किया है, उसके करीब है, इसलिए एक मिसाल और एक सामुदायिक मानक की संभावना है (जो मुझे लगता है कि वैसे भी करना शानदार होगा; JSX ने दिखाया है कि यह काम कर सकता है), और यह रिएक्ट के लिए अपग्रेड करने में आसान होने के लिए एक व्यावहारिक कदम भी है। (विकल्प 1 के विपरीत)।

विकल्प 3 कागज पर अच्छा दिखता है, लेकिन मुझे लगता है कि तार्किक रूप से यह संज्ञानात्मक ओवरहेड के कारण विकल्प 2 की तुलना में बहुत अधिक कठिन होगा, उक्त ओवरहेड के आसपास का दस्तावेजीकरण, और एसएसआर के साथ अज्ञात।

जैसा कि उल्लेख किया गया है, मैंने मूल रूप से विकल्प 4 प्रस्तुत किया था लेकिन प्रतिबिंब के बाद, मुझे यकीन नहीं है कि मुझे अब यह पसंद है। आप इसे अधिक ऑप्ट-इन करने के लिए बदल सकते हैं, जहां आप स्पष्ट props और events ( attrs बजाय) निर्दिष्ट करते हैं, लेकिन फिर भी विकल्प 2 को कार्यान्वयन विवरण के कम ज्ञान की आवश्यकता होती है और इसे अपनाने के लिए किसी को बदलने के लिए कुछ भी नहीं है।

विकल्प 5 ऐसा लगता है कि हम मूल मुद्दे को पूरी तरह से अनदेखा कर रहे हैं।

एक तरफ, मैं इस पर कर्षण देखकर बहुत खुश हूं और आशा करता हूं कि आप सब अच्छा कर रहे होंगे!

यदि प्रयोक्ता भूमि में कोई संभावित समाधान है, तो क्या इसे समुदाय द्वारा समेकित किया जा सकता है और फिलहाल के लिए अनुशंसित किया जा सकता है?

यदि यह पहले से ही एक लोकप्रिय और व्यवहार्य तृतीय-पक्ष मॉड्यूल के रूप में मौजूद है, तो रिएक्ट कोर टीम को एक सुविधा जोड़ने के लिए राजी करना बहुत आसान होगा।

यदि प्रयोक्ता भूमि में कोई संभावित समाधान है, तो क्या इसे समुदाय द्वारा समेकित किया जा सकता है और फिलहाल के लिए अनुशंसित किया जा सकता है?

मुझे विश्वास नहीं है कि यह कुछ ऐसा है जिसे [बड़े करीने से] बाहर से पैच किया जा सकता है। अधिकांश यूजरलैंड समाधान इस और यह जैसे रैपर हैं। प्रतिक्रिया को संशोधित किए बिना, मैं इस दृष्टिकोण के लिए एक उचित विकल्प के बारे में नहीं सोच सकता, और रैपिंग निश्चित रूप से एक आदर्श समाधान नहीं है। मैं

ध्यान दें कि vuejs/vue#7582 में, Vue ने सिगिल का उपयोग करना चुना, और उन्होंने "।" उपसर्ग के रूप में (ग्लिमर का "@" नहीं)।

मेरे पास इस पर एक आधिकारिक बयान का लिंक नहीं है (और शायद Vue के करीब कोई स्पष्ट रूप से पुष्टि कर सकता है), लेकिन ऐसा प्रतीत होता है कि Vue 3.0 के रूप में विकल्प 2 में चला गया है, जिसका अर्थ है कि यह Preact के समान व्यवहार करता है। (संदर्भ के लिए इस मुद्दे को देखें।)

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

क्या आप https://github.com/facebook/react/issues/11347#issuecomment -713514984 में विशिष्ट प्रश्नों का उत्तर दे सकते हैं? मुझे ऐसा लग रहा है कि हम एक-दूसरे से बात कर रहे हैं। मैं सिर्फ एक विशिष्ट तरीके से पूरे इच्छित व्यवहार को समझना चाहता हूं। क्या सेट हो जाता है, और किस मामले में क्रमबद्ध हो जाता है।

एक यादृच्छिक प्रीएक्ट + डब्ल्यूसी देव के रूप में जो यहां ठोकर खाई, मैं यह बताना चाहता था कि "विकल्प 2" न केवल एक _ब्रेकिंग परिवर्तन_ है, बल्कि एक _अपूर्ण समाधान_ भी है (प्रीक्ट अभी भी केवल वैध वेब घटकों के सबसेट के साथ घोषणात्मक रूप से बातचीत कर सकता है)।

अनुमानी के वर्तमान उपयोगकर्ता के रूप में भी, यह लंबे समय में शायद ही वांछनीय लगता है।

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

यानी JSX के नीचे रेंडर करने के बाद:

<web-component key={'key'} ongoing={true} children={[1, 2]} />

properties key , ongoing और children सभी undefined (या जो भी डिफ़ॉल्ट मान है) web-component के बनाए गए उदाहरण पर होंगे।

साथ ही, ओपी के विपरीत, यह विकल्प भी एक ब्रेकिंग बदलाव है। अधिकांश वेब घटक (उदाहरण के लिए lit-element ) शुद्ध HTML के साथ उपयोग किए जाने के उद्देश्य से विशेषताओं के माध्यम से क्रमबद्ध समृद्ध डेटा पास करने की क्षमता प्रदान करते हैं। ऐसे घटकों को रिएक्ट से प्रदान किया जा सकता है जैसे

<web-component richdata={JSON.stringify(something)} />

जो "विकल्प 2" चुने जाने पर टूट जाएगा। यह सुनिश्चित नहीं है कि वेब घटकों का इस तरह का उपयोग रिएक्ट में कितना आम है, लेकिन निश्चित रूप से कुछ कोड बेस हैं जो ऐसा करते हैं, यह कम कुशल है तो रेफरी लेकिन टर्सर भी है।

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

मुझे लगता है कि यह बहुत कम संभावना है कि हम अकेले इस विशेष सुविधा के लिए नया JSX सिंटैक्स पेश करेंगे।

नामस्थान का उपयोग करने के बारे में क्या? https://github.com/facebook/jsx/issues/66 में react नेमस्पेस जोड़ने का प्रस्ताव है key और ref । उसी पंक्ति के साथ, क्या react-dom जैसा कुछ डीओएम गुणों की पहचान के लिए टकसाल के लिए ठीक नामस्थान होगा? ओपी के विकल्प 3 उदाहरण का उपयोग करना, वह होगा:

<custom-img react-dom:src="corgi.jpg" react-dom:hiResSrc="[email protected]" width="100%">

यह सबसे एर्गोनोमिक नहीं है। बस dom बेहतर होगा, लेकिन यह सुनिश्चित नहीं है कि रिएक्ट उन नामस्थानों को टकसाल करना चाहता है जो react शुरू नहीं होते हैं। इसके अलावा, इस पर खराब एर्गोनॉमिक्स दुनिया का अंत नहीं है, अगर विचार यह है कि गुणों के रूप में सेटिंग कम आम मामला होना चाहिए। विशेषताओं का उपयोग करना बेहतर है, क्योंकि यह SSR के साथ समानता प्रदान करता है। गुणों के रूप में सेट करना तब होता है जब विशेषताएँ समस्याग्रस्त होती हैं (जैसे कि किसी वस्तु को पास करना या गुणों द्वारा समर्थित गुणों के लिए), और यह ठीक उन समस्याग्रस्त गुणों के लिए है जिन्हें हम किसी भी तरह से विशेषताओं के लिए SSR नहीं कर सकते हैं, और उन्हें हाइड्रेट करने की आवश्यकता होगी जेएस के माध्यम से

एक _अपूर्ण समाधान_

(प्रीएक्ट अभी भी केवल मान्य वेब घटकों के सबसेट के साथ घोषणात्मक रूप से बातचीत कर सकता है)

@brainlessbadger क्या आप ऊपर अपनी टिप्पणी संपादित कर सकते हैं कि यह सबसेट वास्तव में क्या है? उदा. कौन से वेब घटक/कस्टम तत्व प्रभावित होते हैं (उदाहरण के साथ)? और वे वास्तव में कैसे प्रभावित होते हैं?

@karlhorky मैंने एक स्पष्टीकरण जोड़ा। अनावश्यक रूप से अस्पष्ट होने के लिए क्षमा करें।

वेब घटक घटनाओं के संबंध में। क्या घटनाओं के नामों को टकराने से भविष्य में अवरोध से बचने के बारे में अभी तक कोई सहमति है?

यह विशेषताओं और गुणों के लिए भी एक समस्या है क्योंकि इन सभी की तरह HTMLElement में नई विशेषताएँ जोड़ी जा सकती हैं: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes ऐसा लगता है कि कुछ जोड़े हैं नए जोड़े गए हैं इसलिए अभी भी नए जोड़े जा रहे हैं।

मुझे लगता है कि कड़ाई से बोलते हुए आपको किसी भी कस्टम विशेषता या कस्टम ईवेंट के नाम पर - का उपयोग करना चाहिए।

और कुछ भी एक समझौता है जो उस घटक के जोखिमों को तौलता है जो भविष्य की कल्पना को एक अच्छे नाम का उपयोग करने से रोकता है।

घटनाएँ मुझे अतिरिक्त रूप से परेशान करती हैं, क्योंकि यह केवल उस घटक के असंगत व्यवहार का जोखिम नहीं है। यदि नया ईवेंट बबल करता है, तो यह उस ट्री पथ के सभी मौजूदा वेब घटक को ट्रिगर करेगा।

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

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

मुझे लगता है कि कड़ाई से बोलते हुए आपको किसी भी कस्टम विशेषता या कस्टम ईवेंट के नाम पर - का उपयोग करना चाहिए।

कस्टम एलिमेंट स्पेक में ऐसे प्रतिबंध शामिल नहीं हैं, इसलिए उन्हें रिएक्ट में लागू करने से इंटरऑपरेबिलिटी काफी प्रभावित होगी।

कस्टम तत्व लेखकों से किसी ढांचे की मनमानी आवश्यकताओं की सदस्यता लेने की अपेक्षा नहीं की जानी चाहिए। अलग-अलग राय और सम्मेलनों के साथ ऐसा करने वाले हर ढांचे की कल्पना करें। यह वेब घटकों का उपयोग करने के उद्देश्य को हरा देता है। मैं

आदर्श रूप से, ढांचे को मानक को समायोजित करने के लिए अनुकूल होना चाहिए।

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

हालांकि data- नेमस्पेस किसी कारण से जोड़ा गया था। आप तकनीकी रूप से क्या कर सकते हैं और सर्वोत्तम अभ्यास क्या है, इसके बीच अंतर है। आप तकनीकी रूप से प्रोटोटाइप को भी पैच कर सकते हैं लेकिन फिर आपको स्थितियां शामिल/शामिल होती हैं।

मैं यह सुझाव नहीं दूंगा कि सिर्फ रिएक्ट इसे जोड़ता है, लेकिन यह कि समुदाय इस सम्मेलन में भविष्य के नामस्थान की रक्षा करने में मदद करता है। मुझे लगता है कि यह दुर्भाग्यपूर्ण है कि इस मुद्दे को गंभीरता से नहीं लिया गया। लेकिन शायद वेब केवल नए एपीआई में अजीब नाम जोड़ने के लिए बर्बाद है।

मुझे एसएसआर से गैर-बिल्डिन को बाहर करने का विचार पसंद है और हाइड्रेशन के दौरान गुण पसंद करते हैं क्योंकि घोषणात्मक छाया डोम के साथ वास्तविक सामग्री का विस्तार किया जा सकता है।

ठोस रूप से हालांकि मेरा मानना ​​​​है कि एसएसआर + एएमपी के साथ लोगों द्वारा उपयोग किए जाने वाले मौजूदा दृष्टिकोणों के लिए समस्या पैदा होगी क्योंकि यह विशेषताओं का उपयोग करता है और आप मान सकते हैं कि एएमपी रनटाइम पहले ही लोड हो चुका है।

यह मानते हुए कि विकल्प 3 पर दरवाजा बंद नहीं है, विकल्प 2 पर इसका एक महत्वपूर्ण लाभ है, ऊपर दिए गए विपक्ष में सूचीबद्ध नहीं है - विकल्प 2 के साथ मुझे जो समस्या मिली है वह यह है कि यदि वेब घटक पुस्तकालयों को एसिंक्रोनस रूप से लोड किया

यह एक अच्छा इशारा है, मुझे लगता है, रिएक्ट टीम की ओर से, एसएसआर के रूप में, जहां तक ​​​​अन्य ढांचे का समर्थन (मेरी जानकारी के लिए) ऊपर और उससे आगे जाने का सुझाव देने के लिए, प्रारंभिक प्रतिपादन के दौरान वस्तु गुणों को पारित करने की इजाजत देता है, जो सेवा कर सकता है उपयोगकर्ता बेहतर।

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

एएमपी एक और सम्मेलन का उपयोग करता है, हालांकि - ऐसा करने के लिए यह स्क्रिप्ट प्रकार = एप्लिकेशन.जेसन का उपयोग करता है, जो एक उचित (लेकिन वर्बोज़) विकल्प है।

लेकिन विशेषता दृष्टिकोण के साथ चिपके रहना:

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

तो हाइड्रेशन देरी से बचने के लिए इसे सेट करना सुविधाजनक होगा:

<github-icon icon='{"name":"smiley"}'></github-icon>

एसएसआर के दौरान फिर जीथब-आइकन तुरंत अपना काम कर सकता है, आंतरिक रूप से विशेषता का JSON.parse करता है, और प्रतिक्रिया के लिए (अधिक पूर्ण?) ऑब्जेक्ट वैल्यू में पास होने की प्रतीक्षा नहीं करनी पड़ती है।

तो अब हमारे पास एक मुश्किल स्थिति है - यदि सर्वर पर प्रतिपादन, हम चाहते हैं कि "आइकन" को एक विशेषता के रूप में माना जाए, लेकिन एक वस्तु के रूप में मूल्य में पारित करने में सक्षम हो, जो आदर्श रूप से एसएसआर तंत्र विशेषता में स्ट्रिंग करेगा। क्लाइंट पर हम सीधे ऑब्जेक्ट में पास होने में सक्षम होना चाहते हैं, और स्ट्रिंगिंग और पार्सिंग के ऊपरी हिस्से से नहीं गुजरना चाहते हैं।

बेशक, कुछ गुण ऐसी वस्तुएं हैं जो स्ट्रिंगिंग/पार्सिंग के लिए उत्तरदायी नहीं हैं, इसलिए यह लागू नहीं होता है, और उन गुणों को हाइड्रेशन के पूरा होने की प्रतीक्षा करनी होगी।

यदि सभी गुणों और विशेषताओं ने रिएक्ट टीम के पसंदीदा नामकरण सम्मेलन (शायद) का पालन किया - सभी विशेषताओं में डैश थे, और सभी गुण कैमलकेस का उपयोग करते हुए मिश्रित नाम थे, शायद डैश का अस्तित्व विशेषताओं और गुणों के बीच अंतर करने में मदद कर सकता है:

<github-icon my-icon={myStringifiedProperty} myIcon={myObjectProperty}></github-icon>

समस्या यह है कि ऊपर दिए गए सिंटैक्स में कुछ भी नहीं है, यह दर्शाता है कि सर्वर बनाम क्लाइंट पर क्या करना है, और आदर्श रूप से हम दोनों के लिए एक बाइंडिंग का उपयोग करने में सक्षम होंगे, और रिएक्ट यह पता लगाने के लिए पर्याप्त स्मार्ट होगा कि किसका उपयोग करना है।

प्रतिक्रिया केवल यह मान सकती है कि यदि कोई विशेषता/संपत्ति कुंजी ऊंट का मामला है, तो इसे हमेशा क्लाइंट साइड पर ऑब्जेक्ट के रूप में पास करने के लिए, और ऑब्जेक्ट का JSON-stringified क्रमबद्धता यदि यह एसएसआर के दौरान सेट है। इसी तरह, कुंजी में डैश (सुरक्षित रूप से, मुझे लगता है) मान सकते हैं कि यह एक विशेषता है, और बस मान के .toString() में पास करें। लेकिन मुझे लगता है कि यह बहुत ज्यादा मानता है। और एकल शब्द विशेषताओं और गुणों का समर्थन नहीं करना, जिसे मान्य HTML माना जाता है यदि विशेषताएँ HTMLElement को विस्तारित करने वाले वेब घटक पर लागू होती हैं, तो यह बहुत सीमित होगी। मैं W3C के "आरक्षित" विशेषता नामों की एक सूची जारी करने के पक्ष में हूं, जो भविष्य में जेएस के लिए आरक्षित कुंजी शब्दों के समान उपयोग कर सकता है, और अगर वे एक आरक्षित विशेषता नाम का अनुचित रूप से उपयोग कर रहे हैं तो डेवलपर्स को चेतावनी देने के तरीके खोजने वाले ढांचे।

लेकिन मुझे लगता है कि विकल्प 3 सबसे अच्छा तरीका है। हालांकि, अगर इसे बेहतर उपयोगकर्ता अनुभव के लिए @gaearon द्वारा सुझाए गए

मेरा सुझाव होगा:

<github-icon icon={myDynamicIcon}/>

मतलब विशेषता (toString ())।

<github-icon icon:={myDynamicIcon}/>

इसका मतलब होगा - एसएसआर के दौरान, अनदेखा करें, लेकिन क्लाइंट को ऑब्जेक्ट प्रॉपर्टी (हाइड्रेटिंग के बाद) से बांधें।

अब परिदृश्य (कुछ?) के बारे में क्या प्रतिक्रिया टीम को हल करने में दिलचस्पी है? मेरा पहला विचार सिर्फ कुछ अन्य सतर्क था, जैसे कि दो कोलन:

<github-icon icon::={myDynamicIcon}/> //Not my final suggestion!

इसका मतलब होगा, एसएसआर के दौरान, JSON.stringify संपत्ति, प्रदान किए गए HTML में एक विशेषता के रूप में सेट करें, और क्लाइंट पर एक ऑब्जेक्ट के रूप में पास करें जब संपत्ति हाइड्रेशन के बाद परिवर्तन के लिए बाध्यकारी हो।

यह जटिल नामों के साथ क्या करना है की मुश्किल स्थिति छोड़ देता है। यानी अगर हम सेट करते हैं:

<github-icon iconProps::={myDynamicIconProp}/>  //Not my final suggestion!

यह अतीत में विवादास्पद नहीं था कि संपत्ति नाम के लिए संबंधित विशेषता आइकनप्रॉप्स आइकन-प्रॉप्स होना चाहिए।

शायद यह और अधिक विवादास्पद हो गया है, क्योंकि इन वेब घटकों में से कुछ बिना किसी परिवर्तन के प्लेटफॉर्म में निर्मित हो सकते हैं, जहां विशेषताओं में डैश नहीं हो सकते हैं (लेकिन गुण कैमलकेस हो सकते हैं)। मेरे ज्ञान के लिए, अभी तक एक मूल तत्व नहीं है जो JSON deserializing के माध्यम से जटिल वस्तुओं में गुजरने की अनुमति देता है, लेकिन अगर भविष्य में आवश्यकता उत्पन्न होती है तो मुझे आश्चर्य नहीं होगा। तो रिएक्ट को कैसे पता चलेगा कि डैश कब डालना है या नहीं?

एकमात्र (बदसूरत?) सुझाव जिसके साथ मैं आ सकता हूं वह है:

<github-icon icon-props:iconProps={myDynamicIconProp}/>

जिसका अर्थ है, सर्वर पर, क्रमबद्ध करने के बाद विशेषता आइकन-प्रॉप्स का उपयोग करें, और क्लाइंट पर संपत्ति का उपयोग करें iconProps, सीधे वस्तुओं में गुजर रहा है।

अधिक वर्बोज़ नोटेशन का एक और (लंबा शॉट?) संभावित लाभ, एक संकर विशेषता / संपत्ति जोड़ी के लिए अनुमति देता है, यह है: यह मूल तत्व के गुणों को बार-बार सेट करने के लिए थोड़ा तेज़ हो सकता है, विशेष रूप से संबंधित विशेषता के बजाय, विशेष रूप से के लिए गुण जो तार नहीं हैं। यदि हां, तो क्या रिएक्ट वर्तमान में सर्वर पर विशेषताओं और क्लाइंट पर गुणों का उपयोग करता है? यदि नहीं, तो क्या यह अनुवाद की कठिनाइयों के नामकरण के उसी मुद्दे के कारण है, जिसे यह संकेतन हल करेगा?

@bahrus मुझे लगता है कि इसे सरल बनाया जा सकता है

<my-element attr='using-quotes' property={thisIsAnObject} />

मुझे लगता है कि इस मुद्दे को एक ठोस उदाहरण के साथ स्पष्ट करना सबसे अच्छा हो सकता है।

HTML फॉर्म तत्व में कई विशेषताएं हैं। "यौगिक नाम" वाले सभी एक सुसंगत नामकरण पैटर्न का पालन नहीं करते हैं - आम तौर पर यह सभी निचले मामलों के साथ चिपक जाता है, कोई विभाजक नहीं, लेकिन कभी-कभी एक डैश विभाजक होता है - उदाहरण के लिए "स्वीकार-वर्णसेट", कभी-कभी नहीं - - "नवीनीकरण"।

संबंधित जेएस संपत्ति का नाम या तो एक अच्छे सार्वभौमिक पैटर्न में फिट नहीं होता है - एक्सेप्ट चारसेट, नो वैलिडेट। नोवैलिडेट प्रॉपर्टी / नोवालिडेट विशेषता एक बूलियन है, इसलिए क्लाइंट पर, myForm.setAttribute('novalidate', '') करने के लिए myForm.noValidate = true के विपरीत myForm.setAttribute('novalidate', '') करना बेकार होगा (मुझे लगता है)।

हालाँकि, सर्वर पर, myForm.noValidate = true सेट करने का कोई मतलब नहीं है, क्योंकि हम DOM का एक स्ट्रिंग प्रतिनिधित्व भेजना चाहते हैं, इसलिए हमें विशेषता का उपयोग करने की आवश्यकता है:

<form novalidate={shouldNotValidate}>

असल में, यह मेरे लिए स्पष्ट नहीं है कि रिएक्ट/जेएसएक्स में एक बूलियन विशेषता को सशर्त रूप से निश्चित, स्थिर लुकअप टेबल पर, जो (?) अत्यधिक कठोर लगता है । अगर मैं इतना बोल्ड हो सकता हूं, तो ऐसा लगता है कि एक और क्षेत्र रिएक्ट/जेएसएक्स में सुधार हो सकता है, इस आरएफसी के हिस्से के रूप में डीओएम के काम करने के तरीके के साथ पूरी तरह से संगत होने के लिए?

हम इन सभी परिदृश्यों का प्रतिनिधित्व कैसे कर सकते हैं, ताकि डेवलपर का सर्वर (विशेषताओं के माध्यम से) और क्लाइंट (गुणों के माध्यम से) पर प्रदर्शन का त्याग किए बिना पूर्ण नियंत्रण हो? एक बूलियन जैसे नोवालिडेट के मामले में, मैं प्रस्ताव दूंगा:

<form novalidate:noValidate?={shouldNotValidate}/>

यदि रिएक्ट ने पूरी तरह से डीओएम का समर्थन किया, जितना संभव हो उतना गन्दा, जितना संभव हो सके, मुझे लगता है कि कस्टम तत्वों का समर्थन करने के लिए यह एक लंबा सफर तय करेगा, जो शायद नामकरण पैटर्न में बहुत सुसंगत नहीं हैं।

सर्वर पर JSON.stringify के माध्यम से विशेषताओं के लिए वैकल्पिक रूप से ऑब्जेक्ट गुणों को क्रमबद्ध करने के लिए समर्थन जोड़ना, प्रतिक्रिया और वेब घटकों के लिए एक अतिरिक्त बड़ी जीत होगी, ऐसा मुझे लगता है।

या क्या मैं कुछ न कुछ भूल रहा हूं? ( @eavichay , आप कैसे सुझाव देंगे कि इन परिदृश्यों का सबसे अच्छा प्रतिनिधित्व किया जाए, आपके उदाहरण का अनुसरण नहीं)।