मुझे यह पसंद है। बंडल आकार को कम करना और "वर्ग" प्रोप ऐसे परिवर्तन हैं जिनका बहुत स्वागत होगा।

महान काम!

मैं

पुस्तकालय के लेखक ध्यान दें! मैं

महान!

क्लासनाम → क्लास शानदार है

अन्य सभी के बारे में क्या? अजीब लगता है कि अभी भी clipPath , htmlFor , tabIndex , आदि कर रहे हैं।

class को अपनाना पुस्तकालय को शुरुआती लोगों के लिए अधिक अनुकूल बनाने में एक बड़ी सफलता है। बधाई हो।

यह कमाल का है। मैं बहुत उत्सुक हूं कि कैसे class की ओर बढ़ना वास्तव में सहारा के साथ काम कर रहा है।

ऐसा लगता है कि ({ class }) => <div class={class} /> शुरू में एक आरक्षित कीवर्ड समस्या पेश करेगा?

यह शानदार खबर है, धन्यवाद @gaearon!

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

शानदार! क्या आपके पास बंडल आकार में कमी का लक्ष्य है?

मैं

अन्य सभी के बारे में क्या? अभी भी क्लिपपाथ, एचटीएमएलफोर, टैबइंडेक्स इत्यादि करने के लिए अजीब लगता है।

मैं चर्चा के लिए तैयार हूं लेकिन मैं तर्क दूंगा कि ये परिवर्तन इसके लायक नहीं हैं ( for को छोड़कर)।

मुझे लगता है कि इवेंट सिस्टम का फिर से लिखना इसका सबसे दिलचस्प पहलू है। बंडल के आकार को कम करने और सामुदायिक योगदान को आसान बनाने का महत्वपूर्ण अवसर है।

हो जाए!

मुझे आश्चर्य है कि क्या एक ही समय में JSX 2.0 जारी करने पर भी काम करना उचित होगा? लोगों को वैसे भी कुछ चीजें फिर से सीखने की जरूरत है। हो सकता है कि एक समय में दो बार कुछ चीजों के बजाय एक बार में एक गुच्छा फिर से सीखना बेहतर हो? इसे पढ़ते ही बस एक विचार आया।

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

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

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

जब तक रिएक्ट फायर तेजी से धधक रहा है....

ये सभी बदलाव शानदार हैं। मैं इसके बारे में और react-testing-library के लिए इसके प्रभावों के बारे में बहुत उत्साहित हूं। विशेष रूप से, घटनाओं को प्रतिक्रिया रूट से जोड़ा जा रहा है (या शायद घटना प्रतिनिधिमंडल को पूरी तरह से छोड़ दें क्योंकि यह अब आधुनिक वातावरण में आवश्यक नहीं हो सकता है?), संभावित रूप से सिंथेटिक घटनाओं को हटाने/पुनर्लेखन, और onChange -> onInput react-testing-library के कार्यान्वयन और टूल का उपयोग करने के अनुभव में गंभीरता से सुधार करेगा।

मुझे इस पर प्रतिक्रिया देना अच्छा लगेगा क्योंकि इसे लागू किया जा रहा है।

हो सकता है कि इवेंट डेलिगेशन को पूरी तरह से छोड़ दें क्योंकि अब आधुनिक वातावरण में इसकी आवश्यकता नहीं हो सकती है

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

@tannerlinsley ({ class: className }) => <div class={className} /> दुर्भाग्य से यह jsx 2.0 ऑब्जेक्ट शॉर्ट हैंड नोटेशन ( <div class /> ) को मार देगा, लेकिन ऐसा ही हो ...

यह सुपर, बहुत अच्छा होगा यदि class अंत में स्ट्रिंग्स के बगल में ऑब्जेक्ट्स और एरे बीटीडब्ल्यू ले सकता है।

क्या आपके पास बंडल आकार में कमी का लक्ष्य है?

रिएक्ट डोम का एक तिहाई छोड़ना अच्छा होगा। हम देखेंगे। जल्दी कहना मुश्किल है लेकिन हम अपनी तरफ से पूरी कोशिश करेंगे।

वाह, यह लगभग उन सभी डिज़ाइन निर्णयों की एक गणना है जिनका मैं उल्लेख करता हूँ जब लोग मुझसे प्रतिक्रिया विपक्ष के बारे में पूछते हैं।

यह जिस दिशा में जा रहा है उससे प्यार करो।

पुस्तकालयों के लिए अपग्रेड पथ क्या होगा जो className का उपयोग करते हैं और प्रतिक्रिया के कई संस्करणों का समर्थन करना चाहते हैं?

@gaearon शायद यह कोई बड़ी बात नहीं है, आज यह कहना अच्छा है कि "प्रॉप्स DOM गुण हैं HTML विशेषताएँ नहीं", अब यह "क्लासनाम को छोड़कर, वह HTML नाम है"। मैं प्रतिक्रिया के साथ मेल खाने के लिए विशेषताओं के साथ गड़बड़ करने के 10 मिनट के एसवीजी डब्ल्यू/ओ को कॉपी/पेस्ट करने में सक्षम होना चाहता हूं

htmlFor के बारे में क्या?

ऐसा लगता है कि className -> class संक्रमण को बहुत सावधानी से करना होगा, शायद एक विस्तारित अवधि में। यह पारिस्थितिकी तंत्र के लिए बहुत सारे मुद्दों का कारण बनने जा रहा है, क्योंकि लगभग हर घटक को बदलने की आवश्यकता होगी - यहां तक ​​​​कि बहुत ही मामूली। यह अधिकतर ठीक है यदि आप कोड "स्वयं" हैं और एक कोडमोड है, लेकिन जब आप तीसरे पक्ष के पुस्तकालयों पर निर्भर होते हैं तो आप काफी हद तक रखरखाव की दया पर होते हैं।

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

मैं @felixfbecker . से सहमत हूं
सब कुछ बहुत बढ़िया लगता है और डेवलपर्स और उपयोगकर्ताओं दोनों के लिए गुणवत्ता में सुधार करेगा, लेकिन वर्गनाम बदल जाता है।

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

@felixfbecker यह JSX में class / for और JS संस्करण में className / htmlFor हो सकता है?

<label class="foo" for="bar">..</label>

होगा

React.createElement('label', {className: 'foo', htmlFor: 'bar'}, '..')

बढ़िया योजना! यहाँ अच्छा लगा कि! मैं

यह कमाल है, मैं नए सामान में खुदाई करने के लिए इंतजार नहीं कर सकता।

घटना प्रणाली (#4751) को काफी सरल बनाएं।

अब रिएक्टडॉम परिभाषा को विस्तारित किए बिना, प्रतिक्रिया हैंडलर को कस्टम तत्वों को नहीं सौंप सकती है। https://github.com/facebook/react/issues/9242

इसका मतलब है कि रिएक्ट कस्टम तत्व जैसे <x-component onMyEvent={ev => {...}} /> . पर कस्टम हैंडलर सेट नहीं कर सकता

@gaearon
क्या आपके पास इस बारे में कोई योजना है?

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

हमारे पास यह सब हो सकता था!

इवेंट डेलिगेशन को फिर से लिखने से #1254 फिक्सिंग के लिए दरवाजे खुलेंगे; जहां कुछ घटनाएं उस नोड के लिए perf को नीचा दिखाती हैं जिससे वे जुड़े होते हैं (जो रिएक्ट के लिए पूरे ऐप का मतलब है)।

साथ ही, एक लंबे शॉट के रूप में, क्या आपने सिंथेटिक डेटासेट प्रोप रखने पर विचार किया है? स्वीकार्य HTML प्रॉप्स (डेटा-* के कारण) टाइप करने में सक्षम नहीं होने के कारण DOM नोड्स में प्रॉप्स को अग्रेषित करते समय एक टन बग हो जाता है। वर्तमान में टाइप किए गए रिएक्ट घटकों को प्रॉप्स के लिए सटीक प्रकार और डेटा विशेषताओं की अनुमति के बीच चयन करना है।

में उत्साहित हु

@ryanflorence थोड़ा हटकर है, लेकिन यह थोड़े दुख की बात है कि किसी को भी (जहां तक ​​​​मुझे पता है) को HTML/css/svg -> jsx ट्रांसफ़ोमर बनाने का विचार नहीं था ताकि माइग्रेशन को आसान बनाने के लिए HTML को मैप करने के लिए इतने छोटे बदलावों के साथ प्रतिक्रिया दी जा सके। रिएक्ट प्रोप के लिए attrs। इतने सारे मानव-घंटे बर्बाद कर दिए गए ज्यादातर खोज-और-प्रतिस्थापन :(

एक ही मुद्दे (और टिप्पणियों) में निम्नलिखित को देखना बहुत अजीब है:

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

जब ये सभी DOM API के प्रत्यक्ष समकक्ष हों

और यह तर्क जरूरी नहीं है:

मैंने इस तर्क के आपके पक्ष का वर्षों से बचाव किया है लेकिन मुझे लगता है कि अब यह घर्षण है जो इसके लायक नहीं है। आपको इससे कुछ हासिल नहीं होता। केवल लोगों को कक्षा का उपयोग करने देने से इसके अलावा कोई नकारात्मक प्रभाव नहीं पड़ता

प्रतिक्रिया हमेशा जेएस के शीर्ष पर एक बहुत ही पतली परत रही है। तो JSX के कोण कोष्ठक के अलावा बाकी सब कुछ JS _and_ का DOM API में प्रत्यक्ष समकक्ष था, जो सीधे DOM से संबंधित चीजों के लिए था: className , ClipPath , htmlFor , tabIndex आदि आदि आदि।

class पेश करने के निर्णय के साथ रिएक्ट एक पतली परत बनना बंद हो जाता है ( class JS में एक आरक्षित शब्द है) और DOM API के साथ अधिक संगत होने के घोषित लक्ष्य से अलग हो जाता है।

यह देखना विशेष रूप से परेशान करने वाला है कि आप दोनों "ऑनचेंज से ऑनइनपुट में माइग्रेट करना चाहते हैं" क्योंकि यह डीओएम के साथ असंगत है और className -> class माइग्रेट करके डीओएम के साथ असंगत हो जाता है।

इसके अतिरिक्त, यह कीड़े की एक पूरी कैन खोलता है, क्योंकि लोग अन्य भागों में परिवर्तन की मांग करेंगे (और पहले से ही मांग कर रहे हैं)। केवल टिप्पणियों में: हम data-* के बजाय data-* dataset का उपयोग क्यों करते हैं? शायद इसलिए कि data-* वैध JS नहीं है (काफी हद class ) और क्योंकि यह DOM API के अनुरूप है? हम htmlFor क्यों नहीं बदलते? क्योंकि for एक आरक्षित शब्द है और htmlFor DOM API में है? आदि आदि आदि।

और फिर भी अगर हम एक अज्ञात कुंजी/मूल्य जोड़ी पास करते हैं तो इसे रिएक्ट 16 के बाद से एक विशेषता के रूप में माना जाएगा। इसलिए हम पहले से ही असंगत हैं।

@gaearon यही कारण है कि रिएक्ट एकमात्र पुस्तकालय है जो CustomElements एवरीवेयर इंटरऑप टेस्ट पर खराब स्कोर करता है: https://custom-elements-everywhere.com/
और इसे बदलने के लिए कई मुद्दे हैं: https://github.com/facebook/react/issues/11347 , https://github.com/facebook/react/issues/7249 , https://github.com/facebook /प्रतिक्रिया/मुद्दों/9230

यह एक गैर-मुद्दा हो सकता है, लेकिन क्या रिएक्ट फायर टू रिएक्ट फाइबर की समानता गैर-देशी अंग्रेजी बोलने वालों के लिए भ्रमित करने वाली है? मैंने अक्सर सोचा है कि नेवार्क पेन स्टेशन और न्यूयॉर्क पेन स्टेशन यहाँ NYC में एक ही ट्रेन लाइन पर होना पर्यटकों के लिए एक विशेष रूप से क्रूर मज़ाक था।

यदि यह एक वास्तविक चिंता है, तो आप इसे रिएक्ट फ्लेम कह सकते हैं और फिर भी आग रख सकते हैं इमोजी।

इवेंट डेलिगेशन को फिर से लिखने से #1254 फिक्सिंग के लिए दरवाजे खुलेंगे; जहां कुछ घटनाएं उस नोड के लिए perf को नीचा दिखाती हैं जिससे वे जुड़े होते हैं (जो रिएक्ट के लिए पूरे ऐप का मतलब है)।

किसी न किसी रूप में #1254 को ठीक करना निश्चित रूप से कुछ ऐसा है जिसे मैं देखना चाहता हूं।

साथ ही, एक लंबे शॉट के रूप में, क्या आपने सिंथेटिक डेटासेट प्रोप रखने पर विचार किया है?

मैं अभी कुछ इस तरह से प्रतिबद्ध नहीं होना चाहता क्योंकि एक बड़ी सतह है। DOM के लिए रिच इंटरफ़ेस ( ariaSet , dataSet , classList ) समझ में आता है लेकिन यह स्पष्ट नहीं है कि हम रिएक्ट डोम में कितना निवेश करना चाहते हैं, बनाम एक उच्च स्तरीय लाइब्रेरी कि आपको एक समृद्ध डोम एपीआई देता है। चूंकि ये परिवर्तन अधिक कॉस्मेटिक हैं, लेकिन उच्च सतह क्षेत्र हैं, इसलिए मैं उनके साथ रुकूंगा।

प्रतिक्रिया धधकते

@ryanflorence थोड़ा हटकर है, लेकिन यह थोड़े दुख की बात है कि किसी को भी (जहां तक ​​​​मुझे पता है) को HTML/css/svg -> jsx ट्रांसफ़ोमर बनाने का विचार नहीं था ताकि माइग्रेशन को आसान बनाने के लिए HTML को मैप करने के लिए इतने छोटे बदलावों के साथ प्रतिक्रिया दी जा सके। रिएक्ट प्रोप के लिए attrs। इतने सारे मानव-घंटे बर्बाद कर दिए गए ज्यादातर खोज-और-प्रतिस्थापन :(

@jxub
https://transform.now.sh/html-to-jsx/

नए बदलावों के लिए बहुत उत्साहित हैं, आप लोग फेसबुक के इस माइग्रेशन के साथ इतिहास रच रहे हैं। रिएक्ट फायर में 50k घटकों को माइग्रेट किया जाएगा?
आपके परीक्षण सूट इतने कड़े होने चाहिए <3

क्या रिएक्ट फायर टू रिएक्ट फाइबर की समानता गैर-देशी अंग्रेजी बोलने वालों के लिए भ्रमित करने वाली है?

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

@gaearon साझा करने के लिए धन्यवाद, यह आश्चर्यजनक है!

मुझे एक JSX 2.0 रिलीज़ को व्हाइट स्पेस और नई लाइन समस्या को हल करते हुए देखना अच्छा लगेगा जो तब होती है जब हम अपने कोड को बैबेल और टाइपस्क्रिप्ट के साथ संकलित करते हैं।

अलग-अलग मुद्दे खुले हैं और मैंने योगदान करने की कोशिश की, लेकिन मुझे बताया गया क्योंकि रिएक्ट टीम को JSX के आसपास की हर चीज की समीक्षा करने की आवश्यकता है।

यह समस्या वैसे भी डोम से संबंधित है, क्योंकि जिस तरह से हम जेएसएक्स को जेएस में अनुवाद करते हैं वह डब्ल्यू 3 सी के कहने की अनुमति नहीं देता है।

यह समस्या है https://github.com/facebook/jsx/issues/19

मेरी टिप्पणी अंत में है।

मुझे लगता है, className ठीक है। जो है उसे होने दो। अपमान को चोट में न जोड़ें।

क्या कोई कृपया स्पष्ट कर सकता है कि यह मौजूदा हैंडलर को कैसे प्रभावित करता है?

मान विशेषता में इनपुट मान दिखाना बंद करें

क्या रिएक्ट में अभी भी हैंडलर में सटीक event.target.value अपडेट के साथ नियंत्रित इनपुट होंगे, या क्या यह केवल रेफरी और डोम नोड्स से पढ़ने के मूल्यों को प्रभावित करता है?

@nickmccurdy यह प्रभावित करता है कि आप ब्राउज़र में क्या देखते हैं devtools

@tomdale रिएक्ट एम्बर

अच्छा! मैं प्रतिक्रिया 17 में परिवर्तनों की पूरी सूची देखने का इंतजार कर रहा हूं।
मुझे विश्वास है कि यह ReactJS का एक नया युग होगा। ️

@ टोमडेल हम्म: यार्न, फाइबर, फैब्रिक; शायद एक और कपड़ों से संबंधित शब्द इस्तेमाल किया जा सकता है? मैं

और फिर भी अगर हम एक अज्ञात कुंजी/मूल्य जोड़ी पास करते हैं तो इसे रिएक्ट 16 के बाद से एक विशेषता के रूप में माना जाएगा। इसलिए हम पहले से ही असंगत हैं।

@gaearon यही कारण है कि रिएक्ट एकमात्र पुस्तकालय है जो CustomElements एवरीवेयर इंटरऑप टेस्ट पर खराब स्कोर करता है: https://custom-elements-everywhere.com/

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

क्या रिएक्ट फायर टू रिएक्ट फाइबर की समानता गैर-देशी अंग्रेजी बोलने वालों के लिए भ्रमित करने वाली है?

दोनों आंतरिक कोडनेम हैं और परियोजनाओं के पूरा होने के बाद वास्तव में कोई महत्व नहीं रखते हैं। रिएक्ट फायर सिर्फ रिएक्ट डोम को बेहतर बनाने का एक प्रयास है - और जब तक यह उत्पादन के लिए तैयार हो जाता है तब तक यह सिर्फ रिएक्ट डोम होगा।

क्या रिएक्ट में अभी भी हैंडलर में सटीक event.target.value अपडेट के साथ नियंत्रित इनपुट होंगे, या क्या यह केवल refs और DOM Nodes से रीडिंग वैल्यू को प्रभावित करता है?

हां, क्योंकि event.target.value एक संपत्ति है । हम विशेषताओं को अपडेट करने से रोकने के बारे में बात कर रहे हैं। जो कोई अन्य लोकप्रिय पुस्तकालय नहीं करता है (AFAIK) और जो अनगिनत समस्याओं का कारण बनता है। यह आपके कोड को तब तक प्रभावित नहीं करना चाहिए जब तक कि आप मूल्य पर सीएसएस चयनकर्ताओं पर भरोसा नहीं कर रहे हैं (जो शायद वैसे भी खराब है)।

अच्छा! मैं प्रतिक्रिया 17 में परिवर्तनों की पूरी सूची देखने का इंतजार कर रहा हूं।

ध्यान दें कि हम इसे 17 तक तैयार करने के लिए प्रतिबद्ध नहीं हैं। यह 18 या 19 हो सकता है।

रिएक्ट जैसी अच्छी लाइब्रेरी पर लगातार विकास देखना अच्छा है। 🎉 class उपयोगिता को बहुत बेहतर बना देगा, यह इसके लायक है imo

@gaearon

कस्टम और सामान्य तत्व पूरी तरह से अलग कोड पथ हैं

ऐसा लगता है कि कुछ ठीक करना भी है। क्या सभी तत्वों के साथ समान व्यवहार न करने का कोई कारण है? यही HTML और DOM स्पेक्स का इरादा है।

@justinfagnani जैसा कि पहले चर्चा की गई थी, उस समय हमने ऐसा नहीं करने का कारण यह था कि यह बताने के लिए कोई परंपरा नहीं थी कि किसी संपत्ति या विशेषता को कैसे सेट किया जाए - और एक जोखिम था कि एक चेक का उपयोग करके हम इसे बनाने का जोखिम उठाते हैं। वेब प्लेटफॉर्म के लिए प्रोटोटाइप में नए गुण जोड़ना असंभव है। मुझे लगता है कि अब तक RFC और PRs में पहले से ही किसी प्रकार की आम सहमति है जिस पर @robdodson काम कर रहा है, और हम शायद इसे वहां से उठा सकते हैं।

👍 🔥 🔥 🔥

रिएक्ट फायर हमें कुछ चतुर प्रदर्शन अनुकूलन को लागू करने की अनुमति देता है जो कि इन्फर्नो में है - लेकिन ब्रेकिंग परिवर्तनों के कारण लागू नहीं हो पाया है। रोमांचक समय :)

एलजीटीएम

प्रस्तावित className से संबंधित -> class नाम बदलें: मुझे एक classes संपत्ति पसंद आएगी जो स्ट्रिंग्स की एक सरणी लेती है। यह मुझे मेरे घटकों में बहुत सारे स्ट्रिंग मैनिपुलेशन (या क्लासनाम का उपयोग) की परेशानी से बचाएगा।

मुझे लगता है कि classes प्रोप का एकमात्र नुकसान यह होगा कि एक ही क्रम में एक ही तार वाले सरणी शुद्ध घटक में फिर से प्रस्तुत करेंगे, जबकि एक ही सीएसएस कक्षाओं की एक स्ट्रिंग नहीं होगी। हालांकि ईमानदारी से, यह एक छोटी सी समस्या की तरह लगता है। मुझे लगता है कि अधिकांश रिएक्ट देव पहले से ही प्रॉप्स में सरणियों और वस्तुओं के ट्रेडऑफ़ को जानते हैं।

@gaearon के पास पिछड़ी संगतता की योजना है? हो सकता है कि रिएक्ट फाइबर के समान पथ का अनुसरण करें, परिवर्तनों के बारे में चेतावनियां जोड़ना और बड़े कोडबेस अपडेट के लिए समय देना जो नए अपडेट खोए बिना।

https://www.youtube.com/watch?v=F1U0qvtQnE8

class और className के संबंध में।

मैं जानता हूं कि हम इस पर किसी भी तरह से व्यापक समझौता नहीं करेंगे। इस बारे में लोगों की काफी मजबूत राय है। मैं यह साझा करना चाहता हूं कि मैं इसके बारे में कैसे सोच रहा हूं, इस उम्मीद में कि यह मददगार होगा।

घटक एपीआई को मुहावरेदार महसूस करना चाहिए

एक सामान्य तर्क है कि रिएक्ट "जावास्क्रिप्ट से मेल खाता है" और इस प्रकार className को प्राथमिकता दी जाती है। मुझे लगता है कि इस दावे को गलत समझा गया है इसलिए मैं इस पर थोड़ा ध्यान देना चाहूंगा।

रिएक्ट में, सबसे पहले और सबसे महत्वपूर्ण, हम इस बात का ध्यान रखते हैं कि रिएक्ट घटक का उपयोग मुहावरेदार जावास्क्रिप्ट की तरह होना चाहिए । इसका मतलब यह है कि अगर मैं एक काल्पनिक <Table> घटक का उपयोग करता हूं, तो मुझे उम्मीद है कि इसका सहारा ऊंट होगा:

<Table
  rowHeight={10}
  headerBorderInset={5}
  renderRow={this.renderRow}
/>

मुझे किसी घटक के सार्वजनिक API में row_height या row-height जैसे प्रोप नाम देखने की उम्मीद नहीं है। कंपोनेंट के प्रॉप्स एक ऑब्जेक्ट होते हैं (जैसे "ऑप्शन बैग"), और हम आम तौर पर उन विकल्पों के camelCase होने की उम्मीद करते हैं। यह DOM में हमेशा मुहावरेदार नहीं हो सकता है, लेकिन कई जगहों पर DOM बहुत सुसंगत नहीं है। प्रतिक्रिया जावास्क्रिप्ट पारिस्थितिकी तंत्र के साथ संरेखित होती है जो camelCase का अत्यधिक उपयोग करती है।

लेकिन डोम के बारे में क्या? यहीं कंटीली हो जाती है।

डोम गुण सिर्फ "जेएस में गुण" नहीं हैं

DOM में, हमारे पास विशेषताएँ और गुण हैं। विशेषताएं वे चीजें हैं जो आप आमतौर पर HTML में देखते हैं। गुण वे चीजें हैं जो आप आमतौर पर JS से सेट करते हैं। लेकिन महत्वपूर्ण रूप से, DOM API गुण सेट करने और विशेषताएँ सेट करने दोनों के लिए मौजूद हैं - और वे हमेशा एक ही चीज़ सेट नहीं कर रहे हैं।

node.value = 10; // setting a property
node.setAttribute('value', '10'); // setting an attribute

कई मामलों में कोई फर्क नहीं पड़ता। कुछ मामलों में यह करता है। लेकिन शायद उस तरह से नहीं जिस तरह से कोई रिएक्ट का उपयोग करने के बारे में सोच सकता है (जिसमें दोनों पर एक अमूर्तता है)।

प्रतिक्रिया सिर्फ गुण सेट नहीं कर रहा है

एक आम गलत धारणा यह है कि चूंकि रिएक्ट वर्तमान में अधिकांश डोम प्रॉप्स के लिए camelCase कन्वेंशन का उपयोग करता है, इसका मतलब है कि रिएक्ट DOM गुण सेट कर रहा है। ये गलत है।

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

मेरा कहना यह है कि क्या रिएक्ट आंतरिक रूप से गुणों या विशेषताओं का उपयोग करता है, यह एक कार्यान्वयन विवरण है - और इसका इससे कोई लेना-देना नहीं है कि क्या रिएक्ट DOM तत्व _API_ को संपत्ति के नाम, विशेषता नाम, या यहां तक ​​​​कि कुछ अन्य नामों का उपयोग करना चाहिए जो समझ में आते हैं।

फिर भी, चलो बस संपत्ति के नाम का प्रयोग करें?

ठीक है, गुण और विशेषताएँ एक कार्यान्वयन विवरण हैं। लेकिन क्यों न केवल डीओएम संपत्ति नामों का उपयोग करने पर मानकीकरण किया जाए क्योंकि उन्हें विशेष रूप से "जावास्क्रिप्ट के लिए" बनाया गया था? क्या यह नहीं है कि आज रिएक्ट एपीआई कैसे डिज़ाइन किया गया है?

खैर, बिलकुल नहीं। नीचे दिए गए प्रॉप्स में से केवल एक वास्तविक DOM ऑब्जेक्ट प्रॉपर्टी से मेल खाता है:

<div
  tabIndex={1}
  data-id="123"
  aria-live="polite"
  nopin="nopin"
  itemType="http://schema.org/Movie"
  onClick={function() { alert('hi') }}
/>

विडंबना यह है कि उपरोक्त एकमात्र प्रोप में वास्तविक DOM प्रॉपर्टी है, जिसका नाम उसी नाम से है ( tabIndex अगर आप निश्चित नहीं थे) वास्तव में रिएक्ट द्वारा एक विशेषता के रूप में सेट किया जा रहा है!

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

कुछ मामलों में रिएक्ट जानबूझकर विचलन करना चुनता है ( onClick रिएक्ट बनाम onclick DOM प्रॉपर्टी में) क्योंकि यह कस्टम रिएक्ट घटकों के लिए अधिक समझ में आता है। ऐसा इसलिए है क्योंकि रिएक्ट घटक अक्सर अधिक जटिल ईवेंट हैंडलर जैसे onItemClick को उजागर करते हैं। यदि आप <Button onclick> लेकिन <Table onItemClick> लिखते हैं तो यह बहुत असंगत होगा। और <Table onitemclick> कैमलकेस नहीं है, जिसे हम एक घटक एपीआई में टालना चाहते थे।

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

यदि संपत्ति के नाम नहीं हैं, तो आइए लगातार बने रहें और विशेषता नामों का उपयोग करें?

तो क्यों न केवल विशेषता नामों का उपयोग किया जाए? यह प्रशंसनीय हो सकता है। लेकिन अब हम उस पहले विचार से टकराते हैं जिसे हमने लाया था। एक प्रतिक्रिया घटक का उपयोग मुहावरेदार जावास्क्रिप्ट की तरह महसूस करना चाहिए । लेकिन अक्सर घटक कम से कम कुछ प्रॉप्स को अंतर्निहित DOM तत्व के लिए अग्रेषित करते हैं।

<Button
  borderColor='red'
  tabIndex={1}
 />

 // renders...

 <button
   tabIndex={1}
/>

कस्टम Button के लिए असंगत पूंजीकरण के साथ प्रॉप्स स्वीकार करना अजीब होगा:

<Button
  borderColor='red'
  tabindex={1}
 />

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

मुझे लगता है कि यह प्राथमिक कारण है कि यह tabIndex , cellSpacing जैसे प्रॉप्स के लिए वांछनीय है, और अधिकांश अन्य डोम-संबंधित प्रॉप्स कैमलकेस सम्मेलन का पालन करने के लिए। ऐसा इसलिए है क्योंकि वे अक्सर घटक एपीआई में समाप्त हो जाते हैं।

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

यह यह भी बताता है कि क्यों प्रॉप्स जैसे data-* , aria-* , और कस्टम विशेषताएँ उचित अपवाद हैं (भले ही हम उनके लिए अधिक समृद्ध API बना सकें )। वे शायद ही कभी कस्टम घटकों को पास किए जाते हैं। आम तौर पर, वे कस्टम घटकों में उपयोगी होने के लिए डीओएम के साथ बहुत अधिक युग्मित होते हैं - और इसके बजाय, वे <Modal> या <Button> जैसे एक समृद्ध कैमलकेस एपीआई के साथ कुछ का कार्यान्वयन विवरण बन जाते हैं।

प्रतिक्रिया गुण पहले से ही डोम गुणों से मेल नहीं खाते

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

यदि यह बहुत अधिक कट्टरपंथी लगता है, तो विचार करें कि हम पहले से ही ऐसा कर रहे हैं। हम srcSet नाम की किसी चीज़ का समर्थन करते हैं। लेकिन इसके लिए DOM प्रॉपर्टी का नाम है srcset । हमारे पास autoCapitalize है लेकिन DOM प्रॉपर्टी को autocapitalize कहा जाता है। हमारे पास autoFocus है लेकिन DOM संपत्ति autofocus है।

हम पहले से ही DOM प्रॉपर्टी के नामों से विचलित हो रहे हैं, जब वे कैमलकेस जावास्क्रिप्ट कन्वेंशन से मेल नहीं खाते हैं। जो हमें class पर लाता है।

अंत में: className बनाम class

इसे className बनाने के मूल औचित्य का एक हिस्सा था क्योंकि रिएक्ट DOM गुण सेट कर रहा था, और className DOM प्रॉपर्टी का नाम है।

हालाँकि, जैसा कि मैंने ऊपर बताया, रिएक्ट तीन या चार विशेष मामलों को छोड़कर अब गुणों का उपयोग नहीं करता है। इससे भी महत्वपूर्ण बात यह है कि रिएक्ट लगातार डोम संपत्ति नामों का उपयोग नहीं करता है - बल्कि, यह उन नामों का उपयोग करता है जो जावास्क्रिप्ट से उपयोग किए जाने पर प्राकृतिक दिखेंगे, भले ही डीओएम विशेषता और संपत्ति के नामों में आंतरिक नामकरण असंगति हो। और ऐसा इसलिए है क्योंकि रिएक्ट कस्टम घटकों के लिए प्रोप नाम रखने के बारे में सबसे ज्यादा परवाह करता है "जावास्क्रिप्ट"। इस अर्थ में, tabindex "JavaScripty" नहीं है - लेकिन class और className दोनों हैं।

class के खिलाफ एक और तर्क यह था कि इस तरह का कोड मान्य ES3 (IE8 के लिए प्रासंगिक) नहीं था:

// Not valid in ES3
// Valid in ES5
var props = { class: 'foo' };

लेकिन अधिकांश अब ES3 नहीं लिखते हैं। या तो आप बैबेल जैसे टूलचेन का उपयोग कर रहे हैं या आप संभवतः IE9+ को लक्षित कर रहे हैं - रिएक्ट अब IE8 का भी समर्थन नहीं करता है।

तो class के साथ एकमात्र असुविधा यह है कि आप इसे नहीं लिख सकते हैं:

// Not valid at all :-(
const class = props.class;
const { class } = props;

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

// Valid
const {class: cls} = foo;
const cls = props.class;

इतना अधिक प्रयास नहीं है ।

आम तौर पर लोग class को पढ़ने की तुलना में कहीं अधिक बार पास करते हैं क्योंकि कई घटकों में एक से अधिक आंतरिक <div> या अन्य होस्ट तत्व होते हैं। तो आप <div className> को नष्ट करने की इच्छा से कहीं अधिक बार $# class <div className> लिखना समाप्त कर देते हैं। और इस प्रकार class में परिवर्तन से अधिक कीबोर्ड टाइपिंग की बचत होगी, जितना कि यह पेश करेगा।

यहां एक और महत्वपूर्ण बिंदु है।

class को कई स्तरों से गुजरना अपने आप में एक अच्छा पैटर्न नहीं है। यह पुस्तकालयों के लिए आवश्यक है, लेकिन एप्लिकेशन कोड में यह अक्सर नाजुक घटकों की ओर जाता है। जिनकी शैलियाँ हर समय टूटती हैं क्योंकि वहाँ एक सौ अलग-अलग कॉलसाइट्स हैं, जिनमें से प्रत्येक एक अलग वर्ग को जोड़ता है, जिससे कैस्केड कीड़े होते हैं। इसलिए यह स्पष्ट नहीं है कि पहली बार में विनाशकारी class को प्रोत्साहित करना कितना मूल्यवान है। मुझे लगता है कि यह ठीक है कि आपको इसे प्रॉप्स से पढ़ने के लिए कोड की एक और लाइन लिखने की आवश्यकता है (या आप केवल props.class का उपयोग कर सकते हैं और इसके बारे में नहीं सोच सकते हैं)।

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

// Valid in ES2018

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

और अगर आपको इसे संशोधित करने की आवश्यकता नहीं है तो आप इससे $ class पढ़े बिना ही {...rest} को अग्रेषित कर सकते थे। तो विनाशकारी सीमा बेहतर घटक डिजाइन को प्रोत्साहित करने में मदद कर सकती है।

क्यों न दोनों?

अंत में, क्या हम केवल class और className दोनों का समर्थन नहीं कर सकते? एक तरह से, हम पहले से ही करते हैं, लेकिन प्रतिक्रिया चेतावनी के साथ आप पर चिल्लाती है। इस के लिए एक कारण है।

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

सारांश

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

जिसे हम डाउनसाइड्स (डीओएम गुणों के साथ असंगत) के रूप में देखते थे, वह विवादास्पद है क्योंकि हम अब न तो डीओएम गुण सेट करते हैं, और न ही उनके अनुरूप होने का प्रयास करते हैं। इसके बजाय हम रिएक्ट घटकों के उपभोग पक्ष पर एक विशेषता-आधारित लेकिन कैमलकेस एपीआई रखने का लक्ष्य बना रहे हैं - जिस पर हम पहले से ही लगभग सुसंगत हैं। और class="Button" स्पष्ट रूप से className="Button" से अधिक सुविधाजनक है। वास्तव में अगर डोम एपीआई आज डिजाइन किया गया था तो शायद यह आपको .class संपत्ति को ठीक से सेट करने देगा क्योंकि इस तरह के असाइनमेंट में class का उपयोग करने पर प्रतिबंध ES5 में हटा दिया गया था - लगभग दस साल पहले।

केवल शेष बड़ा नकारात्मक पक्ष प्रवासन लागत है। हम इसका सावधानीपूर्वक आकलन करेंगे। लेकिन अगर हम वैसे भी कई बदलाव कर रहे हैं, तो हम इसे भी कर सकते हैं और इसे अच्छे के लिए ठीक कर सकते हैं। हम इस बारे में हल्के में नहीं सोच रहे हैं और हम आपकी सभी चिंताओं को ध्यान में रखते हैं।

नोट: यह अन्य रिएक्ट प्रोप नामों के लिए समझ में आता है जो कैमलकेसेड विशेषता नामों से मेल नहीं खाते हैं।

@renatoagds

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

जैसा कि मैंने नोट किया:

और हमारी माइग्रेशन रणनीति के बारे में हमें ईमानदार रखने के लिए फेसबुक पर हमारे पास 50 हजार से अधिक घटक हैं। हम कुछ लक्षित सुधारों या स्वचालित कोडमॉड को छोड़कर उत्पाद कोड को फिर से लिखने का जोखिम नहीं उठा सकते।

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

पुन: वर्गनाम -> वर्ग, मैं जो भी निर्णय के साथ अच्छा हूं, मैं निश्चित रूप से नए उपयोगकर्ताओं के लिए कक्षा बदलने के अपवाद और कोड की छोटी पंक्तियों का एक पक्ष लाभ देख सकता हूं। हालाँकि, उन्हें अभी भी अन्य ऊंटों के नामों के बारे में जानने की आवश्यकता होगी।

तो कक्षा के साथ एकमात्र असुविधा यह है कि आप इसे नहीं लिख सकते हैं:

const { class } = props;

लेकिन मुझे लगता है कि समय के साथ, यह तर्क अपने आप में काफी मजबूत नहीं है। प्रतिक्रिया आपको उपयोग करने के लिए मजबूर नहीं करती है> विनाशकारी, और लेखन

const class = props.class;

इतना अधिक प्रयास नहीं है।

दो (संभवतः छोटी) चीजें:

1. const class = props.class अमान्य JavaScript नहीं है? मैंने नहीं सोचा था कि यह था, और एक त्वरित परीक्षण में क्रोम इसे पसंद नहीं करता है। साथ ही, यह आलेख बताता है कि यह मान्य नहीं है।

2. मैं इस परिवर्तन को इस तरह के घटकों को लिखने वाले लोगों के लिए निराशा का एक (एक बार फिर, संभावित रूप से छोटा) क्षेत्र देख सकता था: एनवीएम (नीचे अपडेट देखें)

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    className={someClassName}
    {...rest}/>
);

इस बदलाव के बाद, इसे कुछ ऐसा होना चाहिए...

const { oneProp, twoProp, ...rest }  = this.props;

// do stuff with oneProp, twoProp, this.props.className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    {...rest}
    class={someClassName}/>
);

इस बदलाव के आसपास काम करना असंभव नहीं है, लेकिन इस शैली में लेखन और पठन दोनों घटकों को ध्यान में रखना थोड़ा अधिक है।

अद्यतन करें:

कोई बात नहीं,

const { class: className } = this.props;

उसने चाल चली।

केवल शेष बड़ा नकारात्मक पक्ष प्रवासन लागत है। हम इसका सावधानीपूर्वक आकलन करेंगे। लेकिन अगर हम वैसे भी कई बदलाव कर रहे हैं, तो हम इसे भी कर सकते हैं और इसे अच्छे के लिए ठीक कर सकते हैं। हम इस बारे में हल्के में नहीं सोच रहे हैं और हम आपकी सभी चिंताओं को ध्यान में रखते हैं।

सौभाग्य से यह आसानी से कम हो जाता है यदि कोई सीएसएस-इन-जेएस दृष्टिकोण का उपयोग कर रहा है, जैसे सौंदर्यशास्त्र। अद्भुत लेखन के लिए धन्यवाद!

विशेषता नामों के बारे में रैंडम टिप, मुझे उत्कृष्ट प्रोजेक्ट मिला, svg2jsx बड़े SVG को रिएक्ट में उपयोग करने के लिए परिवर्तित करने के लिए बहुत अच्छा है!

@jamesकृपया क्षमा करें, मेरा दिमाग खाली हो गया - आप सही कह रहे हैं। संपादित।

@james कृपया आप सही कह रहे हैं। वह भी अक्सर JSON के साथ काम करता है, डिफ़ॉल्ट मान के लिए, इतना कष्टप्रद!

const { default: defaultVal } = property

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

className -> class पारिस्थितिकी तंत्र के लिए एक बड़ा बदलाव होगा, कई असंबद्ध घटक असंगत हो जाएंगे, और यदि आप उन्हें पैच नहीं कर सकते हैं तो आप कुछ भी नहीं कर सकते हैं। हो सकता है कि StrictMode जैसे कुछ रैपर हों जो क्रमिक प्रवास पथ प्रदान करने के लिए पेड़ में गहरे घटकों के लिए इस परिवर्तन को अक्षम कर दें?

मैं इस परिवर्तन को इस तरह के घटकों को लिखने वाले लोगों के लिए निराशा का एक (एक बार फिर, संभावित रूप से छोटा) क्षेत्र देख सकता हूं:

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
 <div className={someClassName} {...rest}/>
);

बस इसे नष्ट मत करो।

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div
    {...rest}
    class={'something ' + rest.class}
  />
);

@gaearon

क्या रिएक्ट आंतरिक रूप से गुणों या विशेषताओं का उपयोग करता है, यह एक कार्यान्वयन विवरण है

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

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

@sompylasar

className -> class पारिस्थितिकी तंत्र के लिए एक बहुत बड़ा परिवर्तन होगा, कई असंरक्षित घटक असंगत हो जाएंगे, और यदि आप उन्हें पैच नहीं कर सकते हैं तो आप कुछ भी नहीं कर सकते हैं। हो सकता है कि स्ट्रिक्टमोड जैसे कुछ रैपर हों जो क्रमिक माइग्रेशन पथ प्रदान करने के लिए पेड़ में गहरे घटकों के लिए इस परिवर्तन को अक्षम कर दें?

मैं सहमत हूं - और हम अभी भी पेशेवरों और विपक्षों का वजन कर रहे हैं। कुछ भी फाइनल नहीं हुआ है।

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

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

आपके निर्णय के बावजूद, class के विरुद्ध एक और तर्क खोज योग्यता है। जब आप ES6 कोड में CSS क्लास का उपयोग करने वाले JS क्लास घटकों का उपयोग करने वाले घटकों को खोजना चाहते हैं, तो आपको class द्वारा कितने झूठे सकारात्मक परिणाम मिलेंगे? हां, आप class={ खोज सकते हैं, लेकिन JSX में प्रॉप्स को नष्ट करने के बारे में क्या है जो JS में एक ऑब्जेक्ट के रूप में बनाए गए हैं? (मैं प्रॉप्स डिस्ट्रक्टिंग के भारी उपयोग के खिलाफ हूं लेकिन वे अभी भी उपयोग किए जाते हैं) बेशक, हमें कोड संपादकों में बेहतर संदर्भ-जागरूक एएसटी-आधारित खोज टूल की आवश्यकता है, लेकिन अभी के लिए हमारे पास केवल टेक्स्ट और रेगेक्सपी है। बेशक टाइप सिस्टम ऑब्जेक्ट पासिंग को ट्रैक करने में मदद कर सकता है, लेकिन बड़ी आबादी ने उन्हें अपनाया नहीं है।

आरक्षित शब्द का उपयोग करने के बारे में कुछ मेरे साथ सही नहीं बैठता है, भले ही इससे अब कोई समस्या न हो; क्या हम निश्चित रूप से कह सकते हैं कि rest.class (उदाहरण के लिए) x वर्षों में भाषा के लिए महत्वपूर्ण नहीं होगा?

@GeordieP अगर यह आज काम करता है तो यह कल नहीं टूट सकता। जावास्क्रिप्ट को कैसे विकसित किया जा रहा है, इसका मूल सिद्धांत यही है, और इसकी कई विशिष्टताओं का कारण है।

@gaearon मेला, फिर। अगर यह काफी बड़ी जीत है, तो मैं कहता हूं कि इसके लिए जाओ।

@sompylasar मैं आमतौर पर className= या className: खोजता हूं, ऐसा लगता है कि ये दोनों class के साथ भी काम करेंगे।

कृपया className से छुटकारा पाएं, और भगवान के लिए, htmlFor । मैं एक डोम डेवलपर नहीं हूं, अगर मुझे मूल डोम विधियों तक पहुंचना है तो आमतौर पर कुछ बहुत गलत होता है। लोगों को रिएक्ट करने के लिए मेरे पास जो सबसे बड़ी चुनौती है, वह है अमूर्त JSX DOM और इसके अजीब प्रतिस्थापन HTML विशेषताओं को बनाता है। सब कुछ प्रसारित किया जा रहा है, इस बिंदु पर आरक्षित शब्दों के बारे में चिंता करने का कोई कारण नहीं है। आईएमओ।

सुनिश्चित नहीं है कि यह मौजूदा चर्चा में कुछ भी जोड़ रहा है, लेकिन ऐसा लगता है कि className को बदलने का एक बेहतर कारण होना चाहिए।

क्या शुरुआती रिएक्ट शिक्षार्थियों को अपनी परियोजनाओं और व्यवहार को अद्यतन करने के लिए हर किसी के योग्य नाम से थोड़ा अनजान नाम से सहेजना है?

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

साथ ही, शुरुआती अभी भी बड़ी मात्रा में सामग्री (ब्लॉग/रेपो/आदि के रूप में) से भ्रमित नहीं होंगे जो वर्तमान में className का उपयोग करता है?

अंत में, जैसा कि @sompylasar ने कहा, यह मेरे कोडबेस के भीतर खोज-क्षमता को नुकसान पहुंचाता है।

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

थोड़ा हटकर लेकिन यह थोड़े दुखद है कि किसी को भी (जहाँ तक मुझे पता है) एक html/css/svg -> jsx ट्रांसफ़ोमर बनाने का विचार नहीं था ताकि HTML attrs को मैप करने के लिए इतने छोटे बदलावों के साथ प्रतिक्रिया करने के लिए माइग्रेशन को आसान बनाया जा सके। प्रतिक्रिया सहारा।

@jxub - मैंने 2014 में हैकथॉन के हिस्से के रूप में JSX कनवर्टर के लिए एक HTML बनाया: https://magic.reactjs.net/htmltojsx.htm। मुझे यकीन नहीं है कि यह एसवीजी को अच्छी तरह से संभालता है, हालांकि। हैकाथॉन परियोजना एक स्क्रिप्ट बनाने के लिए थी जो रिएक्ट (https://github.com/reactjs/react-magic) का उपयोग करके एक सादे HTML साइट को "अजाक्सिफाई" करेगी और उस हिस्से के लिए मुझे एक रिएक्ट घटक बनाने का एक तरीका बनाने की आवश्यकता थी एचटीएमएल के एक हिस्से से, इसलिए मैंने एचटीएमएल को जेएसएक्स भाग में एक अलग स्टैंडअलोन पेज के रूप में जारी किया।

हम अभी भी IE11 का समर्थन करने की परवाह करते हैं लेकिन यह संभव है कि हम कुछ मौजूदा ब्राउज़र अंतरों को सुचारू करने का प्रयास नहीं करेंगे - जो कि कई आधुनिक UI पुस्तकालयों द्वारा लिया गया रुख है।

@gaearon - आधुनिक UI पुस्तकालयों के कुछ उदाहरण क्या हैं जो ब्राउज़र के अंतर को सुचारू नहीं करते हैं? मेरे लिए, यह पुस्तकालय का उपयोग करने के प्रमुख कारणों में से एक है।

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

महान नाट्य कलाकार टायशलर, दृश्यों के रेखाचित्र बनाते हुए, कोने में एक छोटे हरे कुत्ते को चित्रित करते हैं। और जब प्रवेश समिति में से एक ने पूछा: "मुझे सब कुछ पसंद है, लेकिन यह कुत्ता कहाँ है?", कलाकार ने अफसोस की सांस के साथ उसे थपथपाया।

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

यह अच्छा होगा यदि निष्क्रिय घटना श्रोताओं का समर्थन रिएक्ट फायर के दायरे में हो, जो कि मोबाइल पर एक महत्वपूर्ण विशेषता है।

6436

इस पर आपकी कड़ी मेहनत के लिए धन्यवाद, लेकिन कृपया className -> class पर पुनर्विचार करें।

हम सभी एक बार नए रिएक्ट थे और className ने हमें रिएक्ट को सीखने और प्यार करने से नहीं रोका।

मुझे याद है कि जब मैं jsx के साथ vue का उपयोग कर रहा था, तो उनके पास पहले से ही class नहीं className था, मैं असहमत हूं कि क्या className को class में बदल दिया जाएगा, क्योंकि रिएक्ट वर्चुअल डोम में अग्रणी है। , और स्वयं डोम का प्रतिनिधित्व करते हैं।

दस्तावेज़ के बजाय प्रतिक्रिया रूट पर ईवेंट संलग्न करें

@gaearon क्या इसका मतलब यह है कि एक परीक्षण वातावरण में मुझे वास्तविक ब्राउज़र घटनाओं को प्रेषित करने में सक्षम होने के लिए दस्तावेज़ में तत्वों को जोड़ना नहीं होगा और उनसे जुड़े हैंडलर को बुलाया जाएगा? ऐसा करने के लिए बहुत काउंटर-सहज ज्ञान युक्त है और मुझे यकीन है कि कई डेवलपर्स का स्रोत रहा है जो रिएक्ट के आंतरिक से अपरिचित हैं, भ्रमित हो जाते हैं, परीक्षण लिखने और घटना सिमुलेशन और खराब परीक्षण प्रथाओं में बहुत समय बर्बाद करते हैं।

जो मुझे दूसरे नोट पर ले जाता है, क्या हम react-dom/test-utils के बारे में कुछ कर सकते हैं? मुझे इससे जुड़े सभी मुद्दों को देखते हुए Simulate को संभावित रूप से हटाने में विशेष दिलचस्पी है, और निश्चित रूप से react-dom में ही आवश्यक परिवर्तन करें ताकि वास्तव में इसकी आवश्यकता न हो अब और। क्या यह दायरे में हो सकता है?

/सीसी @kentcdodds

मुझे वह दिशा और बड़ी तस्वीर पसंद है जो रिएक्ट फायर ले रही है। अब तक वे काम करने के लिए बड़े बदलाव की तरह दिखते हैं।

अधिकांश घोषित परिवर्तनों से प्यार है, लेकिन मुझे className परिवर्तन के बारे में संदेह है।

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

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

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

महान

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

क्या यह वास्तव में एक बदलाव पर इतनी राजनीतिक पूंजी खर्च करने लायक है, जब बहुत सी अन्य अच्छी चीजें घोषित की जा रही हैं?

जहां से मैं खड़ा हूं, यदि आप कोई निर्णय ले रहे हैं जहां औचित्य का हिस्सा है "और कुछ ऐसा लिखना ... ... _वह_ अधिक प्रयास नहीं है।", उस निर्णय में एक _विशाल_ उल्टा होना चाहिए, और className -> class परिवर्तन केवल उन सभी चीज़ों की तुलना में नहीं है जिनकी घोषणा की गई है।

यह रिएक्ट फायर पर एक प्रमुख प्रगति होगी

लगभग class v/s className , मुझे लगता है कि हमें खुद को याद दिलाना चाहिए कि JSX React.

चूंकि JSX एक _DSL_ है जिसे HTML की तरह दिखने के लिए डिज़ाइन किया गया है, इसलिए इसे यथासंभव HTML के करीब रखना सबसे अच्छा है। माना जाता है कि इसे डीओएम एपीआई में className कहा जाता है, लेकिन ज्यादातर जेएसएक्स का उपयोग कर रहे हैं क्योंकि वे सीधे डोम एपीआई से निपटना नहीं चाहते हैं।

यदि यह प्रतिक्रिया के एपीआई के लिए डीओएम एपीआई से निकटता से मेल खाने के लिए अधिक समझ में आता है, तो मुझे आशा है कि ट्रांसपिलेशन में मैपिंग करना ठीक/संभव है:
<img src="avatar.png" class="profile" /> → React.createElement("img", { src: "avatar.png", className: "profile" }) ।

JSX सिंटैक्स को HTML का क्लीन सुपरसेट बनाना बहुत मूल्यवान होगा।

@mhenr18 ने जो कहा है उसे जोड़ने के लिए।

चीजों की वर्तमान स्थिति:

• प्रतिक्रिया असंगत है
• एपीआई कैमलकेस है

चीजों की प्रस्तावित स्थिति:

• प्रतिक्रिया असंगत है
• एपीआई कैमलकेस है
• className -> class

कथित लाभ:

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

वास्तविक डाउनसाइड्स:

• className पर निर्भर संपूर्ण पारिस्थितिकी तंत्र काम करना बंद कर देता है (बड़े पैमाने पर उन्नयन प्रयास)
• किताबों, ट्यूटोरियल्स, उदाहरणों, कोड, पोस्ट, लेखों का पूरा विशाल हिस्सा हमेशा इतना थोड़ा अमान्य हो जाता है
• एकमात्र वैध जेएस शेष अतिरिक्त टाइपिंग है : const {class: cls} = props । सादा जेएस में हर दूसरे संभावित उपयोग-मामला अमान्य हो जाता है
• रिएक्ट एपीआई असंगत रहता है, और आगे की धारणाओं को तोड़ता है (क्यों htmlFor नहीं for आदि)

यदि मैं एक उत्पाद प्रबंधक होता, तो परिवर्तन पर मेरी तत्काल प्रतिक्रिया होती: क्या?

@gaearon आपने पहले ही इस पर विचार कर लिया होगा, कृपया पीआर को "रिएक्ट फायर" या इसी तरह के कीवर्ड के साथ टैग करें।

मुद्दों को आमतौर पर सही ढंग से टैग किया जाता है, पीआर में कभी-कभी उनके पास नहीं होता है। यह संभावित योगदानकर्ताओं की मदद करता है।
यह मेरे अनुभव से आ रहा है जब मैं पूरे फाइबर विकास के दौरान रिएक्ट फाइबर और रिएक्ट रिकॉन्सिलर संबंधित कमिट की तलाश में गिट इतिहास के माध्यम से पढ़ने की कोशिश कर रहा था। यह हममें से उन लोगों की मदद करता है जो यह पता लगाने की कोशिश कर रहे हैं कि क्या हो रहा है और देखें कि क्या हम कुछ तरीकों से योगदान कर सकते हैं।

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

एक शब्द के लिए आवश्यक सभी प्रयास।
प्रतिक्रिया के व्यवहार में यह कुछ भी नहीं बदलेगा।
यह प्रतिक्रिया-डोम के विकास को बढ़ावा नहीं देगा।
यह प्रतिक्रिया के साथ एक सप्ताह से अधिक समय तक काम करने वाले देवों की उत्पादकता में वृद्धि नहीं करेगा।
यह बस सब कुछ तोड़ देगा।

कृपया इसके बारे में सोचें, क्या यह वास्तव में इसके लायक है?

मैं वर्षों से बेबेल-प्लगइन-रिएक्ट-एचटीएमएल-एटीआर का उपयोग कर रहा हूं और यह मेरी अच्छी सेवा कर रहा है, मुझे नहीं लगता कि className class करना एक अच्छा विचार है। यह एक प्लगइन द्वारा बेहतर हासिल किया गया है जैसा मैंने उल्लेख किया है।

क्या पूरी " class v className " / " for v htmlFor " स्थिति को संभालने के लिए कोई बैबल प्लगइन नहीं था ?

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

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

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

कृपया className बनाम class पर पुनर्विचार करें। जैसा कि ऊपर कहा गया है, लाभ लगभग न के बराबर है लेकिन वास्तविक गिरावट है।

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

class अधिकांश प्रोग्रामिंग भाषाओं में एक आरक्षित कीवर्ड है, और हम अब इस प्रोप में हेरफेर नहीं कर सकते हैं, जिससे प्रतिक्रिया आवेदन असंभव हो जाता है (सौभाग्य से कक्षाओं में हेरफेर किए बिना एक वास्तविक बनाना)। वही htmlFor बनाम for के लिए जाता है, दुख की बात है (यह वास्तव में बदसूरत है लेकिन मैं आभारी हूं कि यह मौजूद है)।

ओह वैसे, खोज योग्यता ... कल्पना कीजिए कि आप "रिएक्ट क्लास" के लिए Google हैं, आपको मिश्रित सिग्नल मिलेंगे: रिएक्ट क्लास घटक, रिएक्ट क्लास एट्रिब्यूट। आप "रिएक्ट क्लासनाम" के लिए गूगल करते हैं, आपको पुराना दस्तावेज मिलेगा (कोड अपग्रेड के अलावा इस परिवर्तन से प्राप्त अपग्रेड कार्य की बड़ी मात्रा में ऊपर वर्णित लोग)।

क्या इस परियोजना का लक्ष्य समुदाय के लिए अधिक काम और इंटरनेट के लिए अधिक शोर और मिश्रित संकेत उत्पन्न करना है? मुझे आशा नहीं है।

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

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

यदि आप इतने दृढ़ हैं कि वास्तव में इस परिवर्तन की आवश्यकता है, तो परिवर्तन का सही कारण बताएं। यह "सीखने में कठिन" बात नहीं हो सकती, शक्तिशाली रिएक्ट कोर टीम के लिए बहुत उथली लगती है। आपके मन में निश्चित रूप से कुछ होना चाहिए।

@sompylasar मैं आमतौर पर क्लासनाम = या क्लासनाम की खोज करता हूं: ऐसा लगता है कि ये दोनों कक्षा के साथ भी काम करेंगे।

इसके अलावा, सौभाग्य सीधे जीथब = / पर कर रहा है

मैंने यहां सभी टिप्पणियां पढ़ी हैं। मैं परिवर्तनों के साथ ठीक हूं, लेकिन class के बारे में निश्चित नहीं हूं। मुख्य कारण यह है कि यह JSX 2.0 की योजनाओं के साथ काम नहीं करेगा। शॉर्टकट नोटेशन के बारे में (जैसा कि अब हमारे पास ऑब्जेक्ट्स में है)।
बाकी सब कुछ बहुत अच्छा सुधार प्रतीत होता है।
अंतिम निर्णय की प्रतीक्षा में :) आपके अद्भुत प्रयासों के लिए धन्यवाद दोस्तों!

आपकी एक टिप्पणी में, आपने उल्लेख किया था "अगर यह आज काम करता है, तो इसे कल काम करना चाहिए"। मेरे पूछने से पहले इसे ध्यान में रखें;)।

मैं आरएमडब्ल्यूसी https://jamesmfriedman.github.io/rmwc/ नामक एक यूआई लाइब्रेरी बनाए रखता हूं जो प्रतिक्रिया के सभी संस्करणों को 15.4 पर लक्षित करता है। मैं एक एकीकृत एपीआई सतह को बनाए रखने में सक्षम हूं, लेकिन क्लासनाम को कक्षा में बदलना, ऑन-इनपुट पर बदलना, और इवेंट सिस्टम को ओवरहाल करना इसे जारी रखना लगभग असंभव बना देगा।

क्या एक "कम्पेट" परत की कोई संभावना है जो इस सामान में से कुछ को हुड के नीचे अनुवाद कर सकती है? तो मैं जो भी संस्करण प्रतिक्रिया आग में लिख सकता हूं, लेकिन कम रनटाइम में चलना जारी रखता हूं।

यदि नहीं, तो मुझे उम्मीद है कि मेरा अजीब कोड अजीब होने वाला है। मैं

अगर className को वास्तव में class में बदलना है, तो कृपया htmlFor को for में भी बदलें।
चूंकि class और for मूल रूप से अमान्य है जब हम props नष्ट कर रहे हैं।

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

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

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

पीएस बाकी सब कुछ बहुत अच्छा लग रहा है, विशेष रूप से घटना सामग्री

नए अपडेट की प्रतीक्षा में

@gaearon क्या यह विचार करने योग्य है कि आपका अपना उदाहरण:

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div class={'something ' + rest.class} {...rest}/>
);

इसमें एक बग है और वह काम नहीं करेगा जैसा आप उम्मीद करते हैं? यह उतना सीधा नहीं हो सकता है जितना "बस इसे नष्ट न करें।"

क्या मैं अकेला हूं जो वर्ग के नाम के वर्ग के बारे में चिंतित नहीं था? यदि आप मुझसे पूछें कि ऐसी कौन सी समस्याएँ हैं जो मेरे दिमाग में कभी नहीं आतीं।

फिर भी, अपडेट मुफ्त हैं और मुझे मुफ्त पसंद हैं।

क्या मैं अकेला हूं जो वर्ग के नाम के वर्ग के बारे में चिंतित नहीं था?

मुझे क्लास की कतई चिंता नहीं है। आईई 11 के साथ सूक्ष्म बग मजेदार होने जा रहे हैं (और फिर भी मैं इन परिवर्तनों के साथ अभी भी ठीक हूं)

यह अच्छा होगा यदि निष्क्रिय घटना श्रोताओं का समर्थन रिएक्ट फायर के दायरे में हो, जो कि मोबाइल पर एक महत्वपूर्ण विशेषता है। #6436

मैं सहमत हूं। यह निश्चित रूप से इस कार्य के दायरे में है।

अरे @gaearon - सबसे पहले धन्यवाद।

क्या आपने इस बारे में जानकारी एकत्र करने के लिए एक सर्वेक्षण करने पर विचार किया है कि लोग कैसे प्रतिक्रिया का उपयोग कर रहे हैं और किन एपीआई का उपयोग किया जा रहा है और क्या भ्रमित कर रहा है?

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

मैंने इसे उन परियोजनाओं में उपयोगी पाया है जिनमें मैं व्यक्तिगत रूप से शामिल रहा हूं (नोड, ब्लूबर्ड इत्यादि)।

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

क्या आपने इस बारे में जानकारी एकत्र करने के लिए एक सर्वेक्षण करने पर विचार किया है कि लोग कैसे प्रतिक्रिया का उपयोग कर रहे हैं> और कौन से एपीआई का उपयोग किया जा रहा है और क्या भ्रमित कर रहा है?

मुझे लगता है कि प्रतिक्रिया-मूल के पास एक कैनी है। मुझे नहीं पता था कि प्रतिक्रिया नहीं होती है

मैं आरएमडब्ल्यूसी https://jamesmfriedman.github.io/rmwc/ नामक एक यूआई लाइब्रेरी बनाए रखता हूं जो प्रतिक्रिया के सभी संस्करणों को 15.4 पर लक्षित करता है। मैं एक एकीकृत एपीआई सतह को बनाए रखने में सक्षम हूं, लेकिन क्लासनाम को कक्षा में बदलना, ऑन-इनपुट पर बदलना, और इवेंट सिस्टम को ओवरहाल करना इसे जारी रखना लगभग असंभव बना देगा।

क्या एक "कम्पेट" परत की कोई संभावना है जो इस सामान में से कुछ को हुड के नीचे अनुवाद कर सकती है? तो मैं जो भी संस्करण प्रतिक्रिया आग में लिख सकता हूं, लेकिन कम रनटाइम में चलना जारी रखता हूं।

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

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

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

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

विशेष रूप से पुस्तकालयों के लिए एक संकलन समय संगतता परत की तरह।

मैं के लिए htmlFor को छोड़ने का समर्थन करता हूं।

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

रिएक्ट एपीआई असंगत रहता है, और आगे की धारणाओं को तोड़ता है (क्यों htmlFor आदि के लिए नहीं)

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

क्या पूरे "क्लास वी क्लासनाम" / "वी एचटीएमएलफॉर" स्थिति को संभालने के लिए बैबेल प्लगइन नहीं था?

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

const props = {
   class: "foo"
}
<div {...props} />

यह भी समझ में नहीं आता है कि आप class पास करते हैं लेकिन घटक के प्रोप में className प्राप्त करते हैं। या, यदि प्लगइन केवल प्लेटफ़ॉर्म तत्वों को लक्षित करता है, तो यह अजीब होगा कि button को Button से बदलने से class प्रोप के संकलन में परिवर्तन होता है।

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

मजेदार तथ्य: इस प्रकार JSX कंपाइलर का एक बहुत पुराना संस्करण काम करता है। यह व्यवहार कितना भ्रमित करने वाला होने के कारण हटा दिया गया था।

कमाल के बदलाव। . .

अद्भुत! इस तरह के रोमांचक अपडेट लाने के लिए काम करने के लिए सभी योगदानकर्ताओं का धन्यवाद।
मुझे नहीं पता था कि className > class इतना बड़ा घोटाला था। व्यक्तिगत रूप से मुझे इसकी आदत हो गई है।

कम बंडल आकार और उन्नत इवेंट सिस्टम ध्वनि वास्तव में आशाजनक है। सुपर स्टोक!

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

रिएक्ट डोम का एक तिहाई छोड़ना अच्छा होगा।

वेब ऐप डेवलपमेंट में रिएक्ट का उपयोग करना बहुत अच्छा होगा।

नामस्थान के लिए भी अच्छा होगा विशिष्ट प्रोप जैसे प्रतिक्रिया दें key तथा ref । जैसे

<Foo @key="foo" @ref={callback} prop="hi" />

इस पर यहां चर्चा की गई है - https://github.com/facebook/jsx/issues/66

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

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

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

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

इसके अलावा, मैं वास्तव में रिएक्ट के निर्माण, रखरखाव और उन्नयन के प्रयास और इसके पीछे इंजीनियरों के जुनून की सराहना करता हूं :)

ये भविष्य {...update} हैं

className -> class : मुझे नहीं लगता कि यह एक दुर्लभ स्थिति है जब क्लास विशेषता को JSX/ऑब्जेक्ट घोषणा के बाहर परिभाषित किया जाता है। ऐसी स्थितियों में हमें एक ही चीज़ के लिए अलग-अलग नामकरण का उपयोग करना होगा, असंगति उत्पन्न करना, कोड जटिलता और संज्ञानात्मक भार बढ़ाना।
सुझाया गया परिवर्तन हमारे कोडबेस से विशेषता/प्रोप नाम बेमेल को नहीं हटाएगा - यह सिंटैक्स सीमाओं के कारण या देशी डोम के साथ काम करते समय कहीं मौजूद होगा। यह एक अच्छी बात है कि हमने इस नामकरण समस्या के लिए "मानकीकृत" (और इस बिंदु पर अच्छी तरह से स्थापित) समाधान तैयार किया है।
वर्तमान में className को हर जगह लगातार इस्तेमाल किया जा सकता है, हमेशा एक ही चीज़ का जिक्र करते हुए - देशी डोम के साथ काम करते समय भी। वास्तव में प्रतिक्रिया वस्तुतः एकमात्र स्थान हो सकता है, जहाँ हमें वर्ग विशेषता को संदर्भित करने के लिए class का उपयोग करने के लिए मजबूर किया जाएगा।
className शुरू से ही काफी अनावश्यक और थोड़ा भ्रमित करने वाला लग रहा था, लेकिन बाद में यह काफी व्यावहारिक साबित हुआ और इसका उपयोग करना अपेक्षाकृत आसान था।

मैं $ dangerouslySetInnerHTML के लिए अतिरिक्त वस्तु { __html } से भी छुटकारा पाऊंगा क्योंकि यह वास्तव में अनावश्यक लगता है, लेकिन यह प्रवासन से संबंधित समस्याओं के लायक नहीं हो सकता है (और शायद इस मुद्दे से पूरी तरह से असंबंधित)।

जबकि अन्य परिवर्तन बहुत कम भावनाएं उत्पन्न करते हैं, वे बहुत अधिक रोचक और महत्वपूर्ण हैं, इसलिए प्रयास के लिए fb टीम को धन्यवाद।

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

आदर्श रूप में मैं इस परिदृश्य में रहना चाहता हूं कि:

• डाउनस्ट्रीम रिएक्ट लाइब्रेरी नए संस्करण पर कोड को फिर से लिखता है, मेरे उपयोग के मामले के लिए बग पेश करता है
• प्रतिक्रिया अच्छी नई सुविधा / बंडल कमी जोड़ती है
• पुराने पुस्तकालय संस्करण नए रिएक्ट पर प्रयोग करने योग्य रहता है
• हां, मैं रिएक्ट लॉन्च के ठीक बाद नई सुविधा का उपयोग कर सकता हूं और बस बग को ठीक करने के लिए लाइब्रेरी की प्रतीक्षा करें

व्यवहार में यह अधिक पसंद है:

• पुस्तकालय कोड को फिर से लिखता है, बग पेश करता है
• रिएक्ट ने नया ब्रेकिंग चेंज जारी किया
• पुरानी लाइब्रेरी अब काम नहीं करती
• नई लाइब्रेरी अंततः अपडेट होती है
• बग अभी भी मौजूद हो सकता है
• मैं लंबे समय से (केन व्हीलर को उद्धृत करने के लिए) "नई हॉटनेस" के बजाय पुराने रिएक्ट पर अटका हुआ हूं।
• मुझे दुख हो रहा है :(

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

दुर्भाग्य से, इसके 0.x प्रतिमान को छोड़ने के बावजूद और एक कोर वेब लाइब्रेरी बनने की कोशिश करने के बावजूद रिएक्ट अभी भी संस्करण संख्याओं पर मंथन कर रहा है, जिसका अर्थ है कि खड़े रहने के लिए बहुत समय व्यतीत करना।

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

(साथ ही IE11 की बात दुखद है क्योंकि आप एक ऐसे ब्राउज़र को हटा रहे हैं जो EOL नहीं है - अंतिम रिलीज 52 दिन पहले। मुझे लगता है कि रिएक्ट टीम को यह पता चलेगा कि यह काम को कम करने के लिए फेसबुक टीम और सभी बाहरी और आंतरिक लाइब्रेरी टीमों को आगे बढ़ाता है। बजाय)।

@ उरुगेटर

मैं अतिरिक्त ऑब्जेक्ट { __html } से भी छुटकारा पाउंगा खतरनाक तरीके से सेटइनरएचटीएमएल क्योंकि यह वास्तव में अनावश्यक लगता है

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

@philipwhiuk

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

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

साथ ही IE11 की बात दुखद है क्योंकि आप एक ऐसे ब्राउज़र को हटा रहे हैं जो EOL नहीं है - 52 दिन पहले अंतिम रिलीज़।

कोई भी IE 11 का बहिष्कार नहीं कर रहा है। रिएक्ट के वर्तमान संस्करण को वास्तव में IE 11 में कुछ विशेषताओं के लिए पॉलीफ़िल की आवश्यकता है, इसलिए सुझाए गए परिवर्तनों का IE 11 के विकास पर समान प्रभाव होने की संभावना है। https://reactjs.org/docs/javascript-environment-requirements.html

मैं अतिरिक्त ऑब्जेक्ट { __html } से भी छुटकारा पाउंगा खतरनाक तरीके से सेटइनरएचटीएमएल क्योंकि यह वास्तव में अनावश्यक लगता है

@urugator - इसके लायक क्या है, आंतरिक रूप से फेसबुक पर __html का सबसे आम उपयोग सर्वर-रेंडर किए गए HTML को रिएक्ट कंपोनेंट ट्री में सम्मिलित करना है। उस उपयोग के मामले के लिए, हम सर्वर-साइड __html ऑब्जेक्ट बनाते हैं, और क्लाइंट-साइड करने के खिलाफ लिंट नियम हैं। सर्वर-साइड, हमारे पास ऐसे तरीके हैं जो XHP को __html गुणों वाली वस्तुओं के लिए क्रमबद्ध करते हैं। यह सुनिश्चित करता है कि हम कहीं भी किसी भी सुरक्षा छेद का परिचय न दें, क्योंकि XHP JSX के समान है (यह वास्तव में JSX के लिए मुख्य प्रेरणा थी) और इसमें XSS सुरक्षा भी है।

अनिवार्य रूप से, __html ऑब्जेक्ट HTML की एक स्ट्रिंग को चिह्नित करते हैं जिसे हम जानते हैं कि इसे कहीं सेनिटाइज़ किया गया है और सीधे DOM में सम्मिलित करना सुरक्षित है। एक कच्ची स्ट्रिंग को संभालना कठिन होता है - आप कैसे बता सकते हैं कि इसे स्वच्छ किया गया है या नहीं, अगर किसी ने गलती से कुछ कच्चे उपयोगकर्ता इनपुट लौटा दिए (और इस प्रकार एक एक्सएसएस छेद पेश किया)?

तो हाँ, इसका उपयोग करना जानबूझकर कठिन है, क्योंकि अधिकांश ऐप्स में कई उपयोग के मामले नहीं होने चाहिए, और उपयोग के मामलों को यथोचित रूप से समाहित किया जाना चाहिए। आम तौर पर आपको अपने रिएक्ट घटक में सीधे __html ऑब्जेक्ट का निर्माण नहीं करना चाहिए, बल्कि आपके पास कुछ फ़ंक्शन होना चाहिए जो इसे लौटाता है (देखें कि डॉक्स createMarkup फ़ंक्शन का उपयोग कैसे करते हैं: https://reactjs. org/docs/dom-elements.html#dangerouslysetinnerhtml)

मेरी चिंता यह है कि फेसबुक पर लोग जड़ता को कम करके आंक रहे हैं, दर्द और विखंडन तोड़ने वाले एपीआई परिवर्तन पारिस्थितिकी तंत्र और समुदाय के कारण हो सकते हैं।

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

यह सच है कि उनके पास चिंता करने के लिए एफबी में बड़ी संख्या में घटक हैं, लेकिन उन्हें जो लाभ मिला है, और मुझे यहां लगता है, बाहरी ओपन सोर्स प्रतिक्रिया पुस्तकालयों पर उनकी न्यूनतम निर्भरता है क्योंकि उन्होंने अपने अधिकांश घटकों को आंतरिक रूप से बनाया है।

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

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

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

यदि आप उत्सुक हैं, तो हमारे पास अभी भी इस तरह का कोड है

React.PropTypes = require('prop-types')
React.createClass = require('create-react-class')

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

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

(साथ ही IE11 की बात दुखद है क्योंकि आप एक ऐसे ब्राउज़र को हटा रहे हैं जो EOL नहीं है - अंतिम रिलीज 52 दिन पहले। मुझे लगता है कि रिएक्ट टीम को यह पता चलेगा कि यह काम को कम करने के लिए फेसबुक टीम और सभी बाहरी और आंतरिक लाइब्रेरी टीमों को आगे बढ़ाता है। बजाय)।

मुझे समझ में नहीं आ रहा है कि आप क्या कह रहे हैं। मैंने कहीं भी नहीं कहा आईई 11 को "बहिष्कृत" हो रहा था।

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

साथ ही, हमें Facebook पर अन्य टीमों को "कार्य को आगे बढ़ाने" की आवश्यकता नहीं है। अगर हम कुछ तोड़ते हैं, तो उसे ठीक करना हम पर है। यही कारण है कि हम प्रवासन रणनीतियों के बारे में बहुत अधिक परवाह करते हैं - हमें आम तौर पर उन्हें स्वयं निष्पादित करना पड़ता है।

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

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

क्या class बनाम className और for बनाम htmlFor के लिए कीवर्ड समस्या कुछ ऐसा नहीं है जिसे जेएसएक्स कंपाइलर आरक्षित शब्दों को ओवरराइड करने के लिए संभाल सकता है?

मैं वास्तव में केवल तभी चिंतित होता हूं जब परिवर्तन इतने बड़े होते हैं कि खोज परिणाम अप्रचलित उत्तर देते हैं ... दर्द कोणीय 2+ की तरह "angular -angularjs -angular1.x" आदि के लिए गुगल करते समय पेश किया गया।

इसके अलावा मैं सभी परिवर्तनों का स्वागत करता हूँ !!!

@gaearon

तुमने कहा था

"हमें कुछ पुराने ब्राउज़रों के साथ संगतता छोड़ने की आवश्यकता हो सकती है"

यह ड्रॉप कम्पैटिबिलिटी वाला हिस्सा था जिसमें मुझे समस्या थी, न कि निम्नलिखित पॉलीफिल भाग। अंधकार युग में वापस जाना मेरी चिंता थी।

प्रक्रिया के संबंध में। क्या इस तरह का 'मुद्दा' नहीं है जिसके लिए RFC प्रक्रिया को डिज़ाइन किया गया था?

यह ड्रॉप कम्पैटिबिलिटी वाला हिस्सा था जिसमें मुझे समस्या थी, न कि निम्नलिखित पॉलीफिल भाग। अंधकार युग में वापस जाना मेरी चिंता थी।

मैं IE10 और इससे पहले के बारे में बात कर रहा था। मैंने विशेष रूप से नोट किया कि हम IE11 का समर्थन करते रहना चाहते हैं - मुझे लगता है कि यह हमारे ट्रैफ़िक के लगभग 3% का प्रतिनिधित्व करता है, जो कि 1% कटऑफ से बहुत अधिक है जहाँ हम इसे बहुत पुराना मानते हैं।

प्रक्रिया के संबंध में। क्या इस तरह का 'मुद्दा' नहीं है जिसके लिए RFC प्रक्रिया को डिज़ाइन किया गया था?

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

ठीक है स्पष्टीकरण के लिए धन्यवाद!

@gaearon

यह प्रशंसनीय है कि हम सिंथेटिक घटनाओं से पूरी तरह छुटकारा पा लेंगे।

यह उस तत्व की ओर इशारा करते हुए event.currentTarget के साथ कैसे काम करेगा, जिस पर ईवेंट श्रोता जुड़ा हुआ है, जिसका मूल मामले में हमेशा document का अर्थ होता है - या रिएक्ट रूट एक बार उस पर स्विच हो जाता है?

प्रतिक्रिया सिर्फ गुण सेट नहीं कर रहा है

(...)

यहाँ मेरा कहना यह है कि क्या रिएक्ट आंतरिक रूप से गुणों या विशेषताओं का उपयोग करता है, यह एक कार्यान्वयन विवरण है

यह एक कार्यान्वयन विवरण क्यों है जब यह डीओएम में क्या होता है इसे प्रभावित कर सकता है? जब तक कि केवल उन गुणों को संदर्भित नहीं किया जाता है जो किसी तरह विशेषताओं (और पीछे) जैसे class / className में परिलक्षित होते हैं।

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

यह कैसे काम करेगा event.currentTarget उस तत्व की ओर इशारा करते हुए जिस पर ईवेंट श्रोता जुड़ा हुआ है, जो मूल मामले में हमेशा दस्तावेज़ का अर्थ होता है - या रिएक्ट रूट एक बार उस पर स्विच हो जाता है?

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

यह एक कार्यान्वयन विवरण क्यों है जब यह डीओएम में क्या होता है इसे प्रभावित कर सकता है? जब तक कि केवल उन गुणों को संदर्भित नहीं किया जाता है जो किसी भी तरह वर्ग/वर्गनाम जैसे गुणों (और पीछे) में दिखाई देते हैं।

उनमें से अधिकांश के लिए उपयोगकर्ता के दृष्टिकोण से कोई अंतर नहीं देखा जा सकता है कि किसका उपयोग करना है। मुझे लगता है कि उनमें से अधिकतर परिलक्षित होते हैं (हालांकि शायद मैं गलत हूं)।

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

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

(ऐसे मामले हैं जहां यह बहुत अधिक प्रासंगिक हो जाता है जैसे कि कस्टम तत्वों के साथ। लेकिन वहां भी, दोनों का समान रूप से समर्थन करना उतना ही भ्रमित करने वाला है क्योंकि आपको चुनना है कि किसका उपयोग करना है। इस पर कहीं और बहस की गई है इसलिए मैं कूदने से बचना चाहूंगा इस बहस में फिर से - हमारे पास @robdodson जैसे लोगों के प्रस्ताव हैं और हम उन पर गौर करेंगे।)

@ डेनियल15
उल्लिखित नीतियों के बिना (जो मुझे नहीं लगता कि कहीं और उल्लेख किया गया है), अतिरिक्त ऑब्जेक्ट रैपर इसे किसी भी तरह से सुरक्षित नहीं बनाता है।
मेरा मानना ​​है कि उपयोगकर्ता को dangerouslySetInnerHTML के माध्यम से खतरनाक उपयोग के बारे में पर्याप्त रूप से चेतावनी दी गई है। यही वह बिंदु है जब उपयोगकर्ता को दस्तावेज़ों की जांच करने, प्रभावों पर विचार करने और निर्णय लेने के लिए मजबूर होना पड़ता है।
किसी ऑब्जेक्ट/फ़ंक्शन में (संभवतः असंक्रमित) स्ट्रिंग को लपेटने की आवश्यकता, उसे लपेटे गए मूल्य पर पुनर्विचार या स्वच्छ करने के लिए नहीं बनायेगी।
अगर यह इस तरह से काम करेगा, तो शायद { __html } जटिल विचार नहीं है और [{ _html: { __html }] इसे और भी सुरक्षित बना देगा - हमें कितनी बार यह बताना होगा कि कुछ सुरक्षित बनाने के लिए खतरनाक है ?

आपके द्वारा प्रदान की गई अंतर्दृष्टि के साथ मैं तर्क को समझता हूं, लेकिन मुझे लगता है कि यह वर्तमान में फेसबुक के बाहर किसी पर भी लागू नहीं होता है, क्योंकि हमारे पास " { __html } sanitized html का प्रतिनिधित्व करता है" नियम के बारे में कोई सुराग नहीं है।
मैंने हमेशा सोचा कि यह एपीआई में सिर्फ एक और बाधा है। समय निकालने और उस पर कुछ प्रकाश डालने के लिए धन्यवाद, अब और अधिक समझ में आता है।

यह केवल इसे और अधिक जटिल बनाने के बारे में नहीं है, यह गैर-स्वच्छ डेटा को गलती से उपयोग होने से रोकने के बारे में है।

मुझे बस इतना पसंद है कि जिस तरह से प्रतिक्रिया समुदाय द्वारा की जाती है। आप लोगों को यह सब सुनने और इसका सर्वोत्तम लाभ उठाने के लिए बधाई।

मुझे अच्छा लगता है कि हर कोई कैसे सोचता है कि पिछले संस्करणों में जो बदलाव आ रहे हैं या रिएक्ट में आए हैं, वे 'ब्रेकिंग' थे। उन लोगों ने स्पष्ट रूप से कोणीय 2> 3> 4 बार अनुभव नहीं किया।

मुझे बदलाव पसंद हैं। व्यक्तिगत रूप से मुझे className से कोई आपत्ति नहीं है और class को नष्ट करना परेशानी का सबब बन सकता है। लेकिन मुझे यह देखना अच्छा लगेगा कि आप लोग क्या लेकर आने वाले हैं।

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

मुझे प्रतिक्रिया पसंद है

यह नए डेवलपर्स को प्रतिक्रिया देने में मदद करने का एक सही मौका है और अधिक स्वागत महसूस करता है। मुझे बहुत खुशी है कि ऐसा हो रहा है।

बस लोगों को वर्ग का उपयोग करने देने से कोई नकारात्मक प्रभाव नहीं पड़ता है, सिवाय इसके कि यह विनाशकारी और प्रवासन लागत के साथ काम नहीं करता है।

@gaearon 2c में फेंकना लेकिन वे दो नकारात्मक वर्तमान नकारात्मक (सीखने की कक्षा की एक बार की छोटी लागत => वर्गनाम बनाम हमेशा विनाशकारी + पारिस्थितिकी तंत्र-स्तर प्रवासन लागत से बचने) की तुलना में बड़े या बड़े लगते हैं।

प्रतिक्रिया: दिल:

ऊपर @natew गूंज रहा है:

@gaearon 2c में फेंकना लेकिन वे दो नकारात्मक वर्तमान नकारात्मक (सीखने की कक्षा की एक बार की छोटी लागत => वर्गनाम बनाम हमेशा विनाशकारी + पारिस्थितिकी तंत्र-स्तर प्रवासन लागत से बचने) की तुलना में बड़े या बड़े लगते हैं।

वैसे भी, className से class में बदलने के पीछे क्या प्रेरणा है?
जहां तक ​​​​मैं आपकी टिप्पणी को दो तर्कों तक उबाल सकता हूं, (अगर मैं गलत हूं तो कृपया मुझे सुधारें):

ज्यादातर लोग जो उम्मीद करते हैं, उसके करीब अवधारणात्मक रूप से

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

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

मेरा नोब सिर फट गया होगा।
मुझे लगता है कि एपीआई के साथ बातचीत करते समय लोग एपीआई से समाधान प्रदान करने की अपेक्षा करते हैं। ClassName एक अंतर्निहित समाधान है। कक्षा एक अंतर्निहित समस्या है।

कम टाइपिंग

ब्रुह, यह चार वर्ण 8^) है। इसके अलावा, भले ही हम वर्तमान में className का उपयोग करने की तुलना में बहुत कम बार class को नष्ट कर दें, जब हम ऐसा करते हैं तो यह अधिक टाइपिंग है। तो मैंने 12 बार 4 कम अक्षर टाइप किए होंगे लेकिन हर बार जब मैं class का वर्णन करता हूं तो 50 और वर्ण जोड़े जाते हैं? यह सिर्फ मूर्खतापूर्ण है।

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

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

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

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

मैं डैन चर्च से प्रार्थना करता हूं कि आप अपना विचार बदल दें।

मुझे बहुत खुशी है कि प्रतिक्रिया को लगातार उन्नत किया जा सकता है। प्रतिक्रिया का उपयोग करने वाले एक डेवलपर के रूप में, मैं इसे vue से आगे निकलते हुए नहीं देखना चाहता। लेकिन क्लासनाम-> क्लास की प्रक्रिया दर्दनाक होनी चाहिए।

मैं कॉपी-पेस्ट के लिए className -> class नाम बदलने के खिलाफ नहीं हूं, लेकिन अभी तक इसके लिए कोई स्पष्ट प्रेरणा नहीं है। className डोम में मौजूद है जबकि आरक्षित प्रोप नाम हैं जो कहीं से भी आते हैं जैसे htmlFor । मुझे लगता है कि जब नाम बदलने की बात आती है तो उन्हें प्राथमिकता दी जानी चाहिए और शायद यह एक बदलाव के बारे में कम व्यापक है जो एक परीक्षण के रूप में भी काम कर सकता है।

@sonhanguyen htmlFor आधिकारिक वेब एपीआई नाम भी है: https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelElement/htmlFor

@allan2coder इसे किसी सरणी में लपेटने के बजाय, इसे <React.Fragment> या <> में लपेटें।

@allan2coder कृपया इस सूत्र को विषय पर रखें, यदि आप चाहें तो एक अलग मुद्दा दर्ज करके प्रश्न पूछ सकते हैं।

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

मैँ आशा करता हूँ कि।

• ऑनचेंज से ऑनइनपुट में माइग्रेट करें और अनियंत्रित घटकों के लिए इसे पॉलीफिल न करें।

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

@MuYunyun

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

वर्तमान ऑनचेंज ऑनपुट + कुछ अन्य मामलों का अनुकरण करता है। डीओएम में पहले से मौजूद एक परिवर्तन घटना पर विचार करने का कोई मतलब नहीं है और इसमें समान अर्थशास्त्र नहीं है: https://developer.mozilla.org/en-US/docs/Web/Events/change

@jxub

थोड़ा हटकर लेकिन यह थोड़े दुखद है कि किसी को भी (जहाँ तक मुझे पता है) एक html/css/svg -> jsx ट्रांसफ़ोमर बनाने का विचार नहीं था ताकि HTML attrs को मैप करने के लिए इतने छोटे बदलावों के साथ प्रतिक्रिया करने के लिए माइग्रेशन को आसान बनाया जा सके। प्रतिक्रिया सहारा। इतने सारे मानव-घंटे बर्बाद कर दिए गए ज्यादातर खोज-और-प्रतिस्थापन :(

मैं अन्य संपादकों के बारे में नहीं जानता, लेकिन IntelliJ IDEA (और WebStorm, PhpStorm आदि) यह परिवर्तन करता है, जब आप JS में HTML कोड पेस्ट करते हैं।

थोड़ा हटकर लेकिन यह थोड़े दुखद है कि किसी को भी (जहाँ तक मुझे पता है) एक html/css/svg -> jsx ट्रांसफ़ोमर बनाने का विचार नहीं था ताकि HTML attrs को मैप करने के लिए इतने छोटे बदलावों के साथ प्रतिक्रिया करने के लिए माइग्रेशन को आसान बनाया जा सके। प्रतिक्रिया सहारा। इतने सारे मानव-घंटे बर्बाद कर दिए गए ज्यादातर खोज-और-प्रतिस्थापन :(

यह वास्तव में मौजूद है लेकिन यह बहुत पुराना है और पूरी तरह से सही नहीं है: https://magic.reactjs.net/htmltojsx.htm

हमें उस प्रयास को पुनर्जीवित करना चाहिए। अगर आप मदद करना चाहते हैं तो कृपया करें: https://github.com/reactjs/reactjs.org/issues/484। अब तक किसी ने मदद की पेशकश नहीं की और उसका पीछा किया।

यह वास्तव में मौजूद है लेकिन यह बहुत पुराना है और पूरी तरह से सही नहीं है: https://magic.reactjs.net/htmltojsx.htm

मैंने इसे पहले कई बार इस्तेमाल किया है - कुछ घटकों को आउटसोर्सिंग करते समय एचटीएमएल/सीएसएस जानने वाले लोगों को आउटसोर्सिंग करते समय इसका उपयोग करना बहुत आम है लेकिन जावास्क्रिप्ट नहीं।

तो बस फीडबैक देना कि यह एक उपयोगी उपकरण है जिसका लोग व्यवहार में उपयोग करते हैं। ऑनलाइन अन्य कन्वर्टर्स भी हैं।

इस दृष्टिकोण के साथ एक समस्या यह है कि यह केवल एकतरफा है (केवल माइग्रेट _to_ प्रतिक्रिया)। हालांकि यह समस्या प्रतिक्रिया के लिए विशेष नहीं है।

आशा है कि यह चीजों को बहुत आसान बना देगा ...

इस दृष्टिकोण के साथ एक समस्या यह है कि यह केवल एकतरफा है (केवल प्रतिक्रिया करने के लिए माइग्रेट करें)। हालांकि यह समस्या प्रतिक्रिया के लिए विशेष नहीं है।

क्यों? यह दूसरी तरफ और भी आसान होना चाहिए - बस ReactDOMServer.renderToString चलाएं।

रिलीज का बेसब्री से इंतजार

@gaearon

क्यों? यह दूसरे तरीके से और भी आसान होना चाहिए - बस ReactDOMServer.renderToString चलाएँ।

ठीक है, इसलिए संदर्भ के लिए चर्चा की गई समस्या यह है: मैं चाहता हूं कि जो लोग एचटीएमएल/सीएसएस लिखते हैं और जेएस कोड पर काम करने के लिए जावास्क्रिप्ट को अच्छी तरह से नहीं जानते हैं ताकि वे घटकों के मार्कअप/शैली/लेआउट पर काम कर सकें।

इसे अभी करने का एक तरीका यह है कि वे इसे html/css में विकसित करें और htmltojsx का उपयोग करें। यह मेरे लिए काफी अच्छा काम करता है।

समस्या यह है कि अब मुझे प्रतिक्रिया में प्रत्येक मार्कअप/शैली/लेआउट परिवर्तन को स्वयं बनाए रखना है।

अगर मैं ReactDOMServer.renderToString पर कॉल करता हूं तो वास्तव में मुझे स्थिर HTML मिल जाएगा, लेकिन उस HTML में सभी वास्तविक घटक कोड नहीं होंगे, इसलिए इसे UI लोगों को देना और उनके आउटपुट का उपयोग करना संभव नहीं है क्योंकि मुझे सभी को फिर से लिखना होगा मेरा तर्क।

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

मुझे पूरी तरह से लगता है कि यह रिएक्टडॉम कोर के दायरे में नहीं है, लेकिन यह निश्चित रूप से अपने डोमेन में है और एक दिलचस्प समस्या है।

यह उच्च प्राथमिकता नहीं है - मैं ज्यादातर यह बताना चाहता था कि प्रवासन के संदर्भ के बाहर भी htmltojsx हम में से कुछ के लिए क्यों उपयोगी है :)

मैं उन लोगों को चाहता हूं जो एचटीएमएल/सीएसएस लिखते हैं और जेएस कोड पर काम करने के लिए जावास्क्रिप्ट को अच्छी तरह से नहीं जानते हैं ताकि वे घटकों के मार्कअप/शैली/लेआउट पर काम कर सकें।

यह कितनी बड़ी समस्या है, और उन्हें थोड़ा JSX सिखाना कितना कठिन होगा? वैसे भी रिएक्ट-सेवी इंजीनियर द्वारा परिवर्तनों की समीक्षा करने की आवश्यकता है।

क्षमा करें अगर यह बहुत अधिक विषय हो जाता है, लेकिन मेरा मानना ​​​​है कि आजकल केवल HTML/CSS पर्याप्त नहीं है।

( @gaearon अगर यह शोर हो जाता है तो इसे छिपाने के लिए स्वतंत्र महसूस करें क्योंकि यह उपरोक्त पहले से ही मामूली ओटी टिप्पणी के बारे में एक उत्तर है)

यह कितनी बड़ी समस्या है, और उन्हें थोड़ा JSX सिखाना कितना कठिन होगा? वैसे भी रिएक्ट-सेवी इंजीनियर द्वारा परिवर्तनों की समीक्षा करने की आवश्यकता है।

खैर, इसके लिए निम्नलिखित की आवश्यकता होगी:

• केवल उन ठेकेदारों के साथ काम करें जो आपके वर्तमान रिएक्ट स्टैक से परिचित हों। स्टाइल-घटकों को सीखने वाले लोगों को ढूंढना कहीं अधिक कठिन है
• नोड (एनपीएम), अपना स्टैक (रिएक्ट, वेबपैक आदि) स्थापित करें, और इसे चलाने के लिए आवश्यक अन्य सभी चीजें यूआई लोगों के प्रत्येक कंप्यूटर पर प्रोजेक्ट करें और इसे अद्यतित रखें।
• उन्हें कुछ बुनियादी प्रोग्रामिंग और जावास्क्रिप्ट सिखाएं, यह सीखें कि कैसे devtools, कंसोल त्रुटियों आदि के साथ काम करना है।
• उन्हें रिएक्ट करना सिखाएं, इसका सिंटैक्स क्या है, सामान जैसे className , key का क्या मतलब है आदि।
• केवल उन ठेकेदारों और फ्रीलांसरों के साथ काम करें जो HTML/CSS बनाने के बजाय उस तरह से काम करने के इच्छुक हैं। यह आमतौर पर चीजों को अधिक महंगा भी बनाता है।

अब, जैसा कि ऊपर बताया गया है, प्रतिक्रिया-स्केप्चैप जैसी चीजें यूआई लोगों के लिए इसे अधिक सुलभ और आसान बनाने के लिए एक उपयोगी तरीका हैं - लेकिन इसके लिए उन्हें अभी भी बहुत कुछ सीखने की आवश्यकता है।

मुझे पूरी तरह से पता है कि आप यह क्यों पूछ रहे हैं और मुझे यकीन नहीं है कि यह एक आम समस्या है (मुझे संदेह है कि यह है)। भले ही मुझे नहीं लगता कि यह रिएक्टडॉम के मूल के भविष्य के दायरे में है।

यह काफी अलग विषय है :-) इस चर्चा को ट्विटर पर या कहीं और जारी रखें।

"जिस व्यवहार के लिए आप एक उपकरण का उपयोग करते हुए देखते हैं वह एक ऐसा व्यवहार है जो उपकरण को प्रोत्साहित करता है"
~ गैरी बर्नहार्ट

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

16.3 में किए गए परिवर्तनों पर वापस जा रहे हैं (यदि मुझे सही याद है) पुस्तकालय अब vdom द्वारा प्रदान किए जा रहे मूल HTML तत्वों को पारित किसी भी विशेषता को स्वीकार करके अलग तरह से व्यवहार करेगा, मुझे स्पष्ट रूप से याद है कि मेरा अधिकांश कोडबेस अब बग से ग्रस्त था क्योंकि व्यवहार के बारे में हमने इस स्पष्ट रूप से खराब पैटर्न को लागू किया था

<div {...this.props} />

इसलिए मुझे कहना होगा कि मैं काफी निराश हूं कि डैन सुझाव दे रहा है कि हम इस भयानक कोड को सभी कोडबेस में फैलाते रहें।

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

<Child {...props} />

const Child = (props) => <div {...props} />

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

यदि इसे ठीक करने के लिए प्रतिक्रिया के लिए एक पुनर्लेखन किया जाता है, तो मैं उम्मीद करता हूं कि इसके पीछे के डिजाइनरों को नुकसान का एहसास होगा कि ये खराब पैटर्न खराब निर्णयों को दोगुना करने के बजाय कोडबेस का कारण बनते हैं।

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

@gaearon लंबे समय से! :) (पीएस। टीएल के लिए खेद है; डॉ आगे)

वैसे भी, मैं अपने स्वयं के कारनामों से जो कुछ सीखा है, उसमें कुछ अंतर्दृष्टि देना चाहता हूं। मैंने अपना खुद का "न्यूनतम" रिएक्ट व्युत्पन्न बनाया है जिसे अब मैं प्रदर्शन/सुविधा महत्वपूर्ण अनुप्रयोगों के लिए उपयोग करता हूं। यह शुरू में सिर्फ एक मजेदार साइड प्रयोग था, लेकिन मैं कई अन्य लाभों सहित प्रारंभिक प्रतिपादन/अद्यतन/हटाने के लिए वास्तविक दुनिया के मामलों में + 300% से अधिक के प्रदर्शन में सुधार देख रहा था। वह भी पूल किए गए ईवेंट हैंडलर का उपयोग किए बिना।

आईआईआरसी इसका एक बड़ा हिस्सा सभी रिएक्ट-प्रॉप्स लॉजिक को दरकिनार करते हुए मेरी अपनी लाइब्रेरी से आता है और बस एट्रीब्यूट को सीधे सेटएट्रिब्यूट में फीड करता है, स्टाइल को सीधे स्टाइल में सेट करता है। तो मूल DOM तत्व इंटरफ़ेस इस तरह दिखता है `{विशेषताएँ: {}, शैली: {}, श्रोता: {}, वर्गनाम: "", ...}, यह अधिक क्रियात्मक है लेकिन इंटरफ़ेस अब लागू करने के लिए छोटा और तुच्छ है और अत्यंत तेज है। यह शायद आपके लिए बहुत अधिक है, लेकिन इसने मेरी बहुत अच्छी सेवा की है।

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

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

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

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

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

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

इससे पहले कि मैं भूल जाऊं, आपको मेरे objectKeyValueReconcile फ़ंक्शन में रुचि हो सकती है, विशेष रूप से प्रतिक्रिया-जैसे परिदृश्यों के लिए पिछले/अगले प्रॉप्स की तुलना करने के लिए अत्यधिक तेज़ होने के लिए अनुकूलित। यह मेरे लिए काफी महत्वपूर्ण वास्तविक-विश्व प्रदर्शन लाभ के लिए जिम्मेदार है।

https://github.com/syranide/surgical/blob/master/packages/surgical/private/objectKeyValueReconcile.js

imho मैं "वर्ग" विचार छोड़ दूंगा। JSX अंततः मर जाएगा।

प्रतिक्रिया डोम में गैर-तत्व आधारित डोम/विंडो घटनाओं के लिए समर्थन जोड़ने के विचार क्या हैं? सिंथेटिक घटनाओं के संभावित निष्कासन के साथ मुझे संदेह है कि अभी भी कुछ प्रकार के ईवेंट एकत्रित/अद्यतन/बैचिंग होंगे। कीप्रेस, आकार बदलना और विंडो स्क्रॉल इवेंट सामान्य परिदृश्य हैं जो दिमाग में आते हैं, लेकिन संभवतः https://developer.mozilla.org/en-US/docs/Web/Events में अधिकांश/सभी सूची का समर्थन करने में सक्षम होने से एक ही अमूर्त के पीछे फायदेमंद हो।

यह सबसे पुराने खुले अंक #285 में भी चर्चा की जाती है।

@gaearon

className -> class का व्यावहारिक प्रभाव होगा:

({ className }) => <div className={className} />

हो जाएगा

({ ...rest }) => <div class={rest.class} />

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

@kans

या यह:

props => <div class={props.class} />

यह मूल कार्य के समान जटिलता है।

मुझे क्लासनाम पसंद आया क्योंकि क्लास जेएस में एक कीवर्ड है, लेकिन ऐसा नहीं लगता कि यह किसी भी तरह से एक बड़ा सौदा है। मुझे ग्लैमरस जैसी किसी चीज़ के साथ स्टाइल करना पसंद है, इसलिए, यह कुछ ऐसा नहीं है जो मुझे प्रभावित करता है। मैंने पिछले कुछ सालों में क्लासनाम को दो दर्जन बार इस्तेमाल किया है ?? लगभग नहीं।

हालांकि एक विचार जो मेरे साथ class के पक्ष में हुआ, वह यह है कि अधिकांश लोग जो वास्तव में क्लासनाम का उपयोग करते हैं, वे सीएसएस का उपयोग कर रहे हैं, और वे class के html/css मॉडल की अपेक्षा करते हैं। इस प्रोप का अत्यधिक मुख्य उद्देश्य वास्तव में सिर्फ सीएसएस कोड से जुड़ रहा है, ठीक है, तो क्यों न इसे एचटीएमएल/सीएसएस उपयोगकर्ता की तरह कक्षा को कॉल करें?

डिज़ाइन सिस्टम कोड के बाहर IMO, वास्तव में मुहावरेदार प्रतिक्रिया विकास आमतौर पर वैसे भी क्लासनाम या क्लास का उपयोग नहीं करेगा। जब मुझे सीएसएस के लिए कक्षाओं का उपयोग करने की आवश्यकता होती है, तो यह ज्यादातर कुछ छोटे यूआई घटकों से अलग होती है। एप्लिकेशन परत पर उपयोग की जाने वाली बहुत कुछ उच्च स्तर है (जैसे, कहें, <Columns verticalAlign="center"> या <BodyText /> )।

इसलिए मुझे लगता है कि मुझे आश्चर्य है कि अगर className से class का नाम बदलने से उन लोगों के लिए आसान हो जाता है जो किसी भी तरह से प्रोप का उपयोग करते हैं (रिएक्ट डेवलपमेंट में आना आसान है, संदर्भों को स्विच करने के लिए, क्रोधित न होने के लिए) , आदि), क्यों न सिर्फ इसका नाम बदलें?

कृपया बंडल का आकार कम करें।

चूंकि यह एक बड़ा, ब्रेकिंग अपडेट है, शायद हम रिएक्ट जीवनचक्र नामकरण को भी ठीक कर सकते हैं!

यानी shouldComponentUpdate => shouldUpdate , आदि। यह नामकरण मूर्खतापूर्ण से परे है।

@AlexGalays

चूंकि यह एक बड़ा, ब्रेकिंग अपडेट है, शायद हम रिएक्ट जीवनचक्र नामकरण को भी ठीक कर सकते हैं!

यानी shouldComponentUpdate => shouldUpdate, आदि। यह नामकरण मूर्खतापूर्ण से परे है।

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

जीवनचक्र विधियाँ रिएक्ट कोर का हिस्सा हैं, और यह समस्या केवल प्रतिक्रिया-डोम के बारे में है।

@ljharb
उफ़, वाकई!

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

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

मुझे आश्चर्य है कि क्या फ़ोरम में कुछ चर्चाओं को अलग-अलग थ्रेड्स पर ले जाना उचित है (https://discuss.reactjs.org)? चूंकि गिटहब मुद्दों को फोरम पोस्ट की तरह थ्रेड नहीं किया जाता है, इसलिए एक ही मुद्दे में कई अलग-अलग चीजों पर चर्चा करना मुश्किल हो जाता है।

className -> class का परिवर्तन मुझे दिलचस्प लगता है

देखिए, 2019 रिएक्ट प्रोजेक्ट्स

const {
  class: className, // YouKnowIamRight PepeHands
  someFancyProp,
  ...restProps
} = props

मैं इसे निश्चित रूप से देख रहा हूं।

मुझे HTML को कॉपी पेस्ट करने में सक्षम होना और className को बदलने की आवश्यकता नहीं है, लेकिन साथ ही मैं उन मुद्दों को देखता हूं जो class आरक्षित कीवर्ड ला सकते हैं।

इस बिंदु पर, मैं className के साथ रहना पसंद करूंगा जब तक कि आपको इसके बारे में एक मजबूत इंजीनियरिंग चिंता न हो (व्यक्तिगत वरीयता नहीं)

लेकिन यह सिर्फ मेरी व्यावहारिक राय है।

जबकि मैं class पहचानकर्ता को नष्ट करने में सक्षम नहीं होने के अतिरिक्त घर्षण को समझता हूं, मुझे लगता है कि इस धागे में बहुत से लोग कक्षा के नाम को प्रोप के रूप में प्राप्त करने की संख्या को अधिक महत्व देते हैं।

className को एक रिएक्ट कंपोनेंट (जो कि केवल DOM एलिमेंट नहीं है) को पास करने का मतलब है कि आप या तो बिना कोई नया एब्स्ट्रैक्शन प्रदान किए काफी छोटे बिल्डिंग ब्लॉक्स बना रहे हैं या वह कंपोनेंट इसके कुछ कार्यान्वयन विवरणों को उजागर करता है। पहले मामले में (उदाहरण के लिए <Button /> घटक) आप शायद @gaearon के उदाहरण का पालन करना चाहेंगे और साथ ही साथ प्रोप के "बाकी" को DOM तत्व पर भी अग्रेषित करना चाहेंगे। दूसरे मामले में, हो सकता है कि अतिरिक्त घर्षण आपको काम करने से बचने और बेहतर समाधान के साथ आने के लिए मजबूर करे।

अपने विनम्र अनुभव से, मुझे HTML को JSX में कॉपी करना पड़ा (और class को className से बदल दें) जितना मैं याद कर सकता हूं उससे अधिक बार एक घटक बनाना जो प्राप्त करता है className ।

सभी प्रॉप्स को HTML में फैलाना एक विरोधी पैटर्न है। यदि भविष्य में किसी व्यक्ति में एक अतिरिक्त प्रोप शामिल होता है जो एक HTML विशेषता से मेल खाता है तो यह अप्रत्याशित रूप से व्यवहार को बदल देगा। यदि आईई एक नई विशेषता जोड़ता है तो आपको लगाया जाता है।

@philipwhiuk यदि आप केवल उन प्रॉप्स को फैलाते हैं जिनका आप उपयोग नहीं करते हैं तो कोई व्यवहार समस्या नहीं होगी।

@ जे-एफ1

यदि आप केवल उन प्रॉप्स को फैलाते हैं जिनका आप उपयोग नहीं करते हैं तो कोई व्यवहार समस्या नहीं होगी।

ज़रुरी नहीं। यदि आप अपने घटक API में एक नया विकल्प जोड़ते हैं तो यह विकल्प अंतर्निहित DOM नोड को पास होना बंद हो जाता है। कोई व्यक्ति उस सटीक विशेषता पर निर्भर हो सकता है जिसे तत्व पर सेट किया जा रहा है और फिर आप उस व्यक्ति को तोड़ देते हैं। सभी अप्रयुक्त प्रॉप्स को नीचे की किसी भी चीज़ में फैलाने का मतलब है कि आपके घटक एपीआई में कोई भी जोड़ एक ब्रेकिंग बदलाव है।

बीटीडब्ल्यू, मैंने एक यादृच्छिक उदाहरण का उपयोग किया जहां आप class के मूल्य का पुनर्निर्माण करते हैं लेकिन उस विवरण पर कटौती नहीं करते हैं।

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

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

यदि आप थोड़े अधिक व्यावहारिक हैं तो आप अपनी व्यक्तिगत प्राथमिकताओं के बजाय तकनीकी निहितार्थों के बारे में बात करेंगे, लेकिन मैं किसी को भी className के तकनीकी निहितार्थों के बारे में कुछ भी कहते हुए नहीं देखता।

एक और बात जिस पर आपको ध्यान देने की आवश्यकता है वह यह है कि आप कोर योगदानकर्ताओं को किसी ऐसी चीज़ पर ध्यान केंद्रित कर रहे हैं जो व्यक्तिगत प्राथमिकताओं का मामला है (मुझे गलत साबित करें, सिर्फ इसलिए कि मैं चाहता हूं कि आप इसके बारे में व्यावहारिक रूप से सोचें)

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

लेकिन फिर, मेरी व्यावहारिक राय।

पॉलीफिल की बात करें तो, मुझे नहीं लगता कि प्रतिक्रिया को यह पता लगाने की कोशिश करनी चाहिए कि क्या उपयोगकर्ता ने "अच्छा" पॉलीफिल निर्दिष्ट किया है।
(उदाहरण के लिए कोड में hasBadMapPolyfill )
किसी प्रोग्रामिंग प्रोजेक्ट में होने वाली सभी यादृच्छिक गलतियों के लिए रिएक्ट को जिम्मेदार नहीं ठहराया जाना चाहिए।

@AlexGalays React सही शब्दार्थ के साथ मानचित्र कार्यान्वयन का उपयोग करने पर निर्भर करता है। यदि उपयोगकर्ता एक गैर-अनुपालन पॉलीफ़िल का उपयोग कर रहे हैं, तो उनका ऐप अप्रत्याशित और भ्रमित करने वाले तरीकों से टूट सकता है, इसलिए उस मामले में समय से पहले चेतावनी देना मददगार होता है।

यह केवल विकास निर्माण में ही किया जाता है, इसलिए उत्पादन में इसके लिए कोई ओवरहेड नहीं है।

मुझे यह रिएक्ट फायर पसंद है और आप इस पर काम करना जारी रखेंगे क्योंकि यह रिएक्टडॉम को आधुनिक बनाने के लिए अधिक दिलचस्प कदम लगता है।

क्या प्रतिक्रिया आग के लिए घटना संचालकों को फिर से बांधना संभव नहीं होगा?

class Compo exntends Compoent {
 onClick() {
   ...
 }
  render() {
   <button onClick={this.onClick} >click me </button>
  }
}

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

@cullophid

क्या प्रतिक्रिया आग के लिए घटना संचालकों को फिर से बांधना संभव नहीं होगा?

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

class Compo extends Compoent {
 onClick = () => {
   ...
 }
 render() {
   <button onClick={this.onClick}>click me</button>
 }
}

घटना प्रणाली को सरल बनाने का एक अन्य लाभ (क्या हम बिना किसी पूलिंग के कच्चे डोम घटनाओं पर वापस जा सकते हैं जैसे सभी ढांचे करते हैं? :)) यह है कि स्थिर रूप से टाइप करना भी आसान है।

एक महान योजना की तरह लगता है! आईई 11 समर्थन प्राप्त करना वाकई अच्छा होगा (भले ही इसका मतलब है कि हमारे अपने पॉलीफिल को शिपिंग करना जो पूरी तरह से ठीक है)। सरकारी ग्राहकों के साथ काम करने वाले किसी व्यक्ति के रूप में, जब वे IE 11 का उपयोग करना बंद कर देंगे, तो यह पूरी तरह से अज्ञात है :(

@MatthewHerbst एक ही नाव, हमारे ग्राहक IE 11 का उपयोग करते हैं और हमारे पास इसका पर्याप्त ट्रैफ़िक है

बस यह कहने के लिए झंकार करना चाहता था कि यह सब सुपर रोमांचक है। एक बात जो मैंने पढ़ी वह मुझे चिंतित करती थी:

यह संभव है कि हम कुछ मौजूदा ब्राउज़र अंतरों को दूर करने का प्रयास नहीं करेंगे

अभी मुझे यह जानकर अच्छा लगा कि रिएक्ट का इवेंट सिस्टम किसी भी ब्राउज़र पर "जस्ट वर्क" करेगा जो रिएक्ट का समर्थन करता है। मुझे डर है कि इस बदलाव का मतलब यह होगा कि क्रॉस ब्राउज़र समस्याओं के लिए यह ऐप की ज़िम्मेदारी बन जाएगी। यह संभवतः बग का पता लगाने में बहुत मुश्किल पेश करेगा। ... कम से कम यह मेरे ऐप्स के लिए होगा। :)

वैसे भी, हमेशा की तरह महान पुस्तकालय के लिए धन्यवाद।

@kentcdodds ने JSX 2.0 एकीकरण का उल्लेख एक संभावित विचार के रूप में किया था जिसे मैं रणनीति के माध्यम से पढ़ रहा था और इससे संबंधित कुछ भी नहीं देखा। मैं सोच रहा था कि क्या यह सिर्फ हवा में था या ऐसा कुछ जिसे भविष्य के लिए रोक दिया जाएगा?

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

@hbroer लिगेसी सॉफ्टवेयर?

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

• "अपडेट करना नहीं जानते" - हमारी समस्या नहीं है, लेकिन हम ब्राउज़रों की सूची के साथ "नया ब्राउज़र इंस्टॉल करें" संदेश डाल सकते हैं और शायद Microsoft हॉटलाइन के टेक्स्ट और फ़ोन नंबर की मदद से ^^
• "कोई विकल्प नहीं है" - ठीक है, लेकिन संगठन को अपने परिवेश को अपडेट करना होगा। यदि उनके उपकरण काम नहीं करते हैं, तो वे करेंगे।

मैं अतीत के लिए कोड से नफरत करता हूं और नई तकनीक के लाभ का उपयोग नहीं कर सकता, क्योंकि 90% कोडर अभी भी पिछली सदी में रहने वाले नीचे के 15% उपभोक्ताओं के भद्दे ब्राउज़र का समर्थन करते हैं। ^^ यह "ओह इस इंटरनेट एक्सप्लोरर 6 नर्ड के साथ क्या है, हमें अगले 10 वर्षों के लिए फिर से उस 15% का समर्थन करना होगा"।

वेबकिट पर स्विच के साथ विंडोज 7 और 8 के लिए एज लाने के लिए बीटीडब्ल्यू एम $ सीम।

@hbroer सब कुछ हमारी समस्या है अगर यह उपयोगकर्ताओं को प्रभावित करता है। अन्य मनुष्यों के लिए कुछ सहानुभूति रखें।

(अलग से, M$ एक सुंदर किशोर है और 90 के दशक के उत्तरार्ध का बहुत पुराना संदर्भ है जिसे आप हटाना चाहते हैं; यदि आप ऐसा करते हैं तो मुझे इसे अलग करने में खुशी होगी)

मैं देख रहा हूँ, यहाँ कई M$ fanboiz हैं। :DI वास्तव में मनुष्यों की परवाह करता है, लेकिन उन संगठनों पर नहीं जो प्रौद्योगिकी प्रगति को रोकते हैं, या कोडर्स जो वर्षों से उस पुरानी बकवास का समर्थन करना चाहते हैं। मुझे एक अतिरिक्त पैकेज से कोई समस्या नहीं है जो पुस्तकालय को "पुरानी बकवास संगत" बनाता है। लेकिन 2019 में एक पुस्तकालय को >=2019 तकनीक को ध्यान में रखकर कोडित किया जाना चाहिए, न कि <=2013 तकनीक को। इसका समर्थन करना काफी बुरा है (ओह हम इसे थोड़ा और तरीके से करते हैं) सफारी और (पुरानी) किनारे की बकवास।

माइक्रोड्रॉप

@hbroer वास्तव में प्राचीन एंड्रॉइड ब्राउज़र, और प्राचीन सफारी, किसी भी माइक्रोसॉफ्ट ब्राउज़र की तुलना में अधिक समस्या है। यह "फैनबोई" होने के बारे में नहीं बल्कि पेशेवर होने के बारे में है, और "एम $" शब्द का उपयोग करना नहीं है।

और नहीं, पुरानी तकनीक का समर्थन करने के लिए यह किसी भी तरह से "बुरा" नहीं है, यह नैतिक और नैतिक बात है। क्या बुरा है वे वेबसाइटें जो "एक्स में सबसे अच्छा काम करती हैं", चाहे वह नेटस्केप नेविगेटर हो, आईई 6, या नवीनतम क्रोम।

मैं देख रहा हूँ, यहाँ कई M$ fanboiz हैं।

@hbroer मैं यहाँ एक व्यक्ति को कंबल विज्ञापन होमिनम हमलों के साथ देखता हूँ।

लेकिन 2019 में एक पुस्तकालय को >=2019 तकनीक को ध्यान में रखकर कोडित किया जाना चाहिए, न कि <=2013 तकनीक को।

नहीं, यह नहीं होना चाहिए।

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

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

यदि आप पुराने बकवास का समर्थन चाहते हैं तो पॉली फिल जोड़ें। भविष्य और वर्तमान के लिए कोड न करने का कोई कारण नहीं है। पुरानी तकनीक का समर्थन करने से वेब ऐप्स आवश्यकता से अधिक मोटा और धीमा हो जाता है।

पीएस मैं एक ऐसे व्यक्ति को देखता हूं जो कटाक्ष नहीं पढ़ सकता और मुस्कुराहट की परवाह नहीं करता ^^

@hbroer आप दिखा रहे हैं कि IE11 वर्तमान है, इसलिए हमें इसके लिए कोडिंग करने की उम्मीद है।

और एक बार फिर से। https://browserl.ist पर डिफ़ॉल्ट मान देखें।

पीएस मैं एक ऐसे व्यक्ति को देखता हूं जो कटाक्ष नहीं पढ़ सकता और मुस्कुराहट की परवाह नहीं करता ^^

हाँ, नहीं। यह ट्रोल और खेल के मैदान के धमकियों द्वारा नियोजित एक सामान्य रणनीति है। "क्या?! मैंने तुम्हारा अपमान नहीं किया! यह सिर्फ एक मजाक था!"।

ग्रह पर 0.20% लोग, यहां तक ​​कि "इंटरनेट का उपयोग करने वालों" द्वारा फ़िल्टर किए गए, 6.4 मिलियन मनुष्य हैं। प्रतिशत बिल्कुल अप्रासंगिक हैं। मनुष्यों के लिए कोड; अतीत और भविष्य, और आपके बंडल आकार, कोई फर्क नहीं पड़ता।

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

अब 2019 में मैं नई परियोजनाओं के लिए सीएसएस ग्रिड (जिसमें IE11 पर केवल प्रायोगिक समर्थन है) का उपयोग करूंगा, और ES6 में स्थानांतरित हो जाएगा और मैं उस पुराने ब्राउज़र के लिए पॉलीफ़िल वितरित नहीं करना चाहता। IE11 उपयोगकर्ताओं को बस एक संदेश मिलता है: अपना ब्राउज़र अपडेट करें या किसी विकल्प का उपयोग करें।

ऐसे लोग हैं जो जावा स्क्रिप्ट का उपयोग नहीं करना चाहते हैं। आप उनकी परवाह करते हैं? आप उन लोगों को आँकड़ों में नहीं देखते हैं। और मैं आंकड़ों में भी नहीं हूं, जैसे कई अन्य लोग जो उस टूल को ब्लॉक करते हैं।

मैं हर उस ब्राउजर पर नजर रखता हूं जो पुराना नहीं है। मैं एज का समर्थन करता हूं, जिसमें उस IE11 बकवास की तुलना में कम उपयोगकर्ता हैं, क्योंकि विंडोज 7 (जो जनवरी 2020 को समाप्त होता है) का समर्थन करता है, और आधुनिक लोग आधुनिक ब्राउज़र का उपयोग करते हैं। ^^

कोई भी आपको पॉलीफ़िल और संगतता पैकेज जैसी किसी चीज़ का उपयोग करने से नहीं रोकता है। लेकिन कोर अप टू डेट होना चाहिए और पुराने M$ तकनीकी ब्राउज़र के केवल एक टुकड़े के कारण पीछे नहीं रहना चाहिए।

मैं कई जावास्क्रिप्ट ढांचे में जो खो रहा हूं वह एलटीएस है। उसी के बारे में हम बात कर सकते हैं। यदि आप वर्तमान से सुविधाओं के साथ एक आधुनिक पृष्ठ बनाते हैं, तो एक अप टू डेट तकनीकी ढांचे का उपयोग करना अच्छा है। और यदि आप b2b सामान के लिए एक वेबएप बना रहे हैं जिसके लिए अधिकतम स्थिरता और अनुकूलता की आवश्यकता है तो आप एलटीएस संस्करण का उपयोग कर सकते हैं। या नॉकआउट का उपयोग करें। फिर आप उन कुछ 100t लोगों का समर्थन कर सकते हैं जो अभी भी IE6 ^^ . के साथ अद्यतन नहीं किए गए Windows XP का उपयोग कर रहे हैं

मूल पोस्ट में संगतता स्पष्ट रूप से "ट्रेड-ऑफ़" के तहत सूचीबद्ध है, इसलिए पुराने ब्राउज़रों के लिए पूर्ण समर्थन होना पहले से ही एक माध्यमिक फोकस है।

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

रिएक्ट फायर की प्रगति स्वयं अप्रभावित लगती है, इसलिए इस बहस से वास्तव में कुछ हासिल नहीं होना है। आइए कृपया आगे बढ़ते हैं और मुख्य विषय पर वापस आते हैं।

क्या यह #6410 को हल करने का एक अच्छा अवसर होगा? यह onChange / onInput में प्रस्तावित परिवर्तनों के प्रभाव के समान लगता है।

5 जून 2019 से अपडेट

इसे बीते एक अर्सा हो गया है। हम कहां हैं, इस पर एक छोटा सा अपडेट यहां दिया गया है।

हमने दिसंबर में फायर पर काम करना शुरू किया। https://github.com/facebook/react/pull/14382 और अन्य थ्रेड्स में कुछ कार्य प्रगति पर है। हालांकि, जैसे ही हमने इवेंट सिस्टम के उन हिस्सों को हटाना शुरू किया जो हमें लगता था कि वे अनावश्यक या पुराने थे, हमने कई किनारे के मामलों की खोज की जहां यह बहुत मददगार था और बग को रोका - यहां तक ​​​​कि आधुनिक ब्राउज़रों में भी। हम अभी भी विरासत की कमी को कम करना चाहते हैं लेकिन यह स्पष्ट नहीं है कि कच्चे DOM ईवेंट के करीब होना व्यवहार में सबसे अच्छी दिशा है। लाइब्रेरी कोड को केवल एप्लिकेशन कोड में कई बार फिर से जोड़ने के लिए कम करना सबसे अच्छा ट्रेडऑफ़ नहीं है। और इसे ऐप स्तर पर ठीक करना हमेशा संभव नहीं होता है।

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

इसलिए जब हमने फायर पर काम शुरू किया, तो हमने सोचा कि शायद एक कस्टम इवेंट सिस्टम अनावश्यक है। लेकिन इसे प्रोटोटाइप करने के बाद, हमने महसूस किया कि हमारी घटना प्रणाली वास्तव में इस समस्या को ठीक करने के लिए हमारा सबसे बड़ा लीवर है ।

इस जांच के परिणामस्वरूप, हमने अन्य मदों पर अस्थायी रूप से काम रोक दिया है जो रिएक्ट फायर का हिस्सा हैं, और हमने पहले केवल इवेंट सिस्टम पर ध्यान केंद्रित करने का निर्णय लिया है। उस परियोजना को रिएक्ट फ्लेयर (https://github.com/facebook/react/issues/15257) के रूप में जाना जाने लगा। यह अपने आप में काफी चुनौतीपूर्ण है और इस सूची की अन्य वस्तुओं को प्रभावित करता है, इसलिए हम पहले इस पर अलग-अलग ध्यान केंद्रित कर रहे हैं।

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

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

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

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

क्या "रिएक्ट फ्लेयर" डिफ़ॉल्ट रिएक्ट पैकेज के एक भाग के रूप में आएगा या एपीआई की मात्रा को देखते हुए अतिरिक्त इंस्टालेशन की आवश्यकता होगी?

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

क्या यह माउस और टच इवेंट सिस्टम पॉइंटरइवेंट का लाभ उठाएगा? मैंने पिछले अपडेट में इस वेब मानक का उल्लेख नहीं देखा था, इसलिए मैं इसे आपके ध्यान में लाना चाहता था।

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

और यहाँ वर्तमान ब्राउज़र संगतता के लिए एक सीधा लिंक है।

@jonathantneal हां, नई प्रणाली पॉइंटर इवेंट्स का भारी उपयोग करती है - पॉइंटर इवेंट्स के लिए कोई समर्थन नहीं होने पर माउस/टच इवेंट्स में फॉलबैक के साथ।

मुझे चिंता है कि इस मुद्दे में https://github.com/facebook/react/issues/11347 को संबोधित नहीं किया गया था। रिएक्ट फ़्लैंक https://custom-elements-everywhere.com।

इवेंट सिस्टम को नया स्वरूप देते समय कृपया शैडो रूट पर विचार करें - केवल रिएक्ट रूट से जुड़ने से आज अधिकांश मुद्दों का समाधान नहीं होगा, केवल तत्व से जुड़ना (https://github.com/facebook/react/issues/9242, https:// github.com/facebook/react/issues/15759, https://github.com/facebook/react/issues/13713, https://github.com/facebook/react/issues/11827

इस अपडेट में: https://github.com/facebook/react/issues/13525#issuecomment -499196939 @gaearon में उल्लेख है:

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

मैं उत्सुक था कि क्या इन किनारे के मामलों की सूची कहीं भी प्रलेखित है?

@gaearon अब जब फ्लेयर बाहर हो गया है (SCNR), क्या कोई अद्यतन योजना है ( 5 जून, 2019 अपडेट के संबंध में) कैसे आगे बढ़ना है?

और @trusktr की तरह, मैं भी यहां #11347 संबोधित करना चाहूंगा।

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

अरे सब, कुछ समय हो गया है और हमने इनमें से कुछ चीजों को चालू और बंद करने की कोशिश की है।

मुझे प्रत्येक पर एक अपडेट दें:

• value विशेषता (https://github.com/facebook/react/issues/11896) में इनपुट मान दिखाना बंद करें। यह मूल रूप से https://github.com/facebook/react/pull/6406 के माध्यम से प्रतिक्रिया 15.2.0 में जोड़ा गया था। यह बहुत सामान्य रूप से अनुरोध किया गया था क्योंकि लोगों का DOM का वैचारिक मॉडल यह है कि value जो वे DOM इंस्पेक्टर में देखते हैं वह value JSX विशेषता से मेल खाना चाहिए। लेकिन ऐसा नहीं है कि डोम कैसे काम करता है। जब आप किसी फ़ील्ड में टाइप करते हैं, तो ब्राउज़र value विशेषता को अपडेट नहीं करता है। रिएक्ट भी ऐसा नहीं करना चाहिए। यह पता चला कि सीएसएस चयनकर्ताओं पर निर्भर कुछ कोड के लिए शायद मददगार होने के बावजूद यह परिवर्तन, बग का एक झरना पैदा करता है - उनमें से कुछ अभी भी आज तक ठीक नहीं हुए हैं। इस परिवर्तन के कुछ नतीजों में शामिल हैं: https://github.com/facebook/react/issues/7179 , https://github.com/facebook/react/issues/8395 , https://github.com/facebook /react/issues/7328 , https://github.com/facebook/react/issues/7233 , https://github.com/facebook/react/issues/11881 , https://github.com/facebook/react /मुद्दों/7253 , https://github.com/facebook/react/pull/9584 , https://github.com/facebook/react/pull/9806 , https://github.com/facebook/react/pull /9714 ​​, https://github.com/facebook/react/pull/11534 , https://github.com/facebook/react/pull/11746 , https://github.com/facebook/react/pull/12925 . इस बिंदु पर ब्राउज़र से लड़ते रहना स्पष्ट रूप से इसके लायक नहीं है, और हमें इसे वापस करना चाहिए। इस यात्रा का सकारात्मक हिस्सा यह है कि हमारे DOM योगदानकर्ताओं ( @nhunzaker , @awery , @jquense , और @ philipp-spiess ) के अथक परिश्रम के लिए धन्यवाद, अब हमारे पास विस्तृत DOM परीक्षण जुड़नार हैं जो हमें प्रतिगमन से बचने में मदद करेंगे।

हम अभी भी ऐसा करना चाहते हैं, लेकिन हमने रिएक्ट 17 को "आरक्षित" करने का निर्णय लिया है ताकि न्यूनतम संभव ब्रेकिंग परिवर्तन हो सकें ताकि यह इस सूची के अगले आइटम पर ध्यान केंद्रित कर सके। तो यह परिवर्तन रिएक्ट 18 तक प्रतीक्षा करेगा।

• दस्तावेज़ के बजाय रिएक्ट रूट पर ईवेंट संलग्न करें (https://github.com/facebook/react/issues/2043)। रिएक्ट ऐप्स को बड़े सिस्टम में एम्बेड करते समय ईवेंट हैंडलर को दस्तावेज़ में संलग्न करना एक समस्या बन जाता है। एटम संपादक उन पहले मामलों में से एक था जो इससे टकराए थे। कोई भी बड़ी वेबसाइट अंततः stopPropagation से संबंधित बहुत जटिल एज केस विकसित करती है जो नॉन-रिएक्ट कोड के साथ या रिएक्ट रूट्स (https://github.com/facebook/react/issues/8693, https://github) के साथ इंटरैक्ट करते हैं। .com/facebook/react/pull/8117, https://github.com/facebook/react/issues/12518)। हम प्रत्येक रूट पर ईवेंट को उत्सुकता से संलग्न करना चाहेंगे ताकि हम अपडेट के दौरान कम रनटाइम चेक कर सकें।

हम इसे रिएक्ट 17 में कर रहे हैं। यह काम का एक बड़ा हिस्सा निकला लेकिन शुक्र है कि यह समाप्त हो गया।

• onChange से onInput पर माइग्रेट करें और अनियंत्रित घटकों के लिए इसे पॉलीफ़िल न करें (https://github.com/facebook/react/issues/9657)। विस्तृत योजना के लिए जुड़ा हुआ मुद्दा देखें। यह भ्रमित करने वाला रहा है कि DOM में input ईवेंट के रूप में जाने जाने वाले रिएक्ट के लिए एक अलग ईवेंट नाम का उपयोग करता है। जबकि हम आम तौर पर महत्वपूर्ण लाभ के बिना इस तरह के बड़े बदलाव करने से बचते हैं, इस मामले में हम कुछ जटिलता को दूर करने के लिए व्यवहार को भी बदलना चाहते हैं जो केवल नियंत्रित इनपुट को बदलने जैसे किनारे के मामलों के लिए जरूरी है। तो इन दो परिवर्तनों को एक साथ करना समझ में आता है, और इसे onInput और onChange बनाने के अवसर के रूप में उपयोग करें, ठीक उसी तरह जैसे DOM ईवेंट अनियंत्रित घटकों के लिए करते हैं।

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

• घटना प्रणाली को काफी सरल बनाएं (https://github.com/facebook/react/issues/4751)। 2013 में इसके प्रारंभिक कार्यान्वयन के बाद से वर्तमान घटना प्रणाली मुश्किल से बदली है। इसे रिएक्ट डोम और रिएक्ट नेटिव में पुन: उपयोग किया जाता है, इसलिए यह अनावश्यक रूप से सार है। इसके द्वारा प्रदान की जाने वाली कई पॉलीफ़िल आधुनिक ब्राउज़रों के लिए अनावश्यक हैं, और उनमें से कुछ हल करने की तुलना में अधिक समस्याएँ पैदा करती हैं। यह रिएक्ट डोम बंडल आकार के एक महत्वपूर्ण हिस्से के लिए भी जिम्मेदार है। हमारे यहां कोई बहुत विशिष्ट योजना नहीं है, लेकिन हम शायद इवेंट सिस्टम को पूरी तरह से फोर्क कर देंगे, और फिर देखेंगे कि हम इसे कितना कम कर सकते हैं यदि हम डीओएम हमें जो देते हैं उसके करीब रहते हैं। यह प्रशंसनीय है कि हम सिंथेटिक घटनाओं से पूरी तरह छुटकारा पा लेंगे। हमें मीडिया इवेंट जैसे बबलिंग इवेंट को बंद करना चाहिए जो DOM में बबल नहीं करते हैं और बबल करने का कोई अच्छा कारण नहीं है। हम कुछ प्रतिक्रिया-विशिष्ट क्षमताओं को बनाए रखना चाहते हैं जैसे पोर्टल्स के माध्यम से बुदबुदाना, लेकिन हम इसे सरल माध्यमों (जैसे ईवेंट को फिर से भेजना) के माध्यम से करने का प्रयास करेंगे। पैसिव इवेंट इसका हिस्सा होने की संभावना है।

हमने 2019 की शुरुआत में यह कोशिश की है, और हमारे आंतरिक परीक्षण में वास्तव में न्यूनतम घटना प्रणाली बहुत अच्छी तरह से काम नहीं करती है। काफी हद तक क्रॉस-ब्राउज़र सामान्यीकरण रिएक्ट कर रहा है जो अभी भी पुराने ब्राउज़र वाले लोगों के लिए उपयोगी है, या अधिक विशिष्ट क्षेत्रों जैसे समृद्ध टेक्स्ट इनपुट संपादकों में contentEditable का उपयोग कर रहा है। उस ने कहा, घटनाओं को जड़ों से जोड़ने पर हमारे काम के एक हिस्से के रूप में, हमने घटना प्रणाली से बहुत सारे अमूर्तन को हटा दिया है ताकि भविष्य में इसे समझना और सुधारना आसान हो। रिएक्ट 17 के एक भाग के रूप में, हम "इवेंट पूलिंग" को हटा रहे हैं जिससे बहुत भ्रम हुआ है, और हम अब onScroll ईवेंट को बुदबुदाते नहीं हैं। हम रिएक्ट 18 में मीडिया इवेंट्स के बुदबुदाहट को रोकने के साथ-साथ रिएक्ट व्यवहार को ब्राउज़र के करीब लाएंगे। हमने नए ईवेंट सिस्टम के साथ कुछ बाइट सहेजे थे, लेकिन वे नई सुविधाओं द्वारा लिए गए थे जिन पर हम काम कर रहे हैं, इसलिए इससे बंडल का आकार समग्र रूप से कम नहीं होगा।

• className → class (https://github.com/facebook/react/issues/4331, यह भी देखें https://github.com/facebook/react/issues/13525#issuecomment- 417818906 नीचे)। यह अनगिनत बार प्रस्तावित किया गया है। हम पहले से ही रिएक्ट 16 में class को DOM नोड में जाने की अनुमति दे रहे हैं। यह जो भ्रम पैदा कर रहा है, वह सिंटैक्स सीमाओं के लायक नहीं है, जिससे वह बचाव करने की कोशिश कर रहा है। हम इस परिवर्तन को अपने आप नहीं करेंगे, लेकिन इसके ऊपर की सभी चीज़ों के साथ मिलकर यह समझ में आता है। ध्यान दें कि हम दोनों को बिना चेतावनियों के अनुमति नहीं दे सकते क्योंकि इससे एक घटक पारिस्थितिकी तंत्र को संभालना बहुत मुश्किल हो जाता है। प्रत्येक घटक को दोनों को सही ढंग से संभालना सीखना होगा, और उनमें परस्पर विरोधी होने का जोखिम है। चूंकि कई घटक className (उदाहरण के लिए इसे जोड़कर) संसाधित करते हैं, यह बहुत त्रुटि-प्रवण है।

यह प्रस्ताव का सबसे विवादास्पद हिस्सा था। तब से, हमने हुक जारी किए, जो फ़ंक्शन घटकों को लिखने को प्रोत्साहित करते हैं। फ़ंक्शन घटकों में, हम आम तौर पर प्रॉप्स के लिए विनाशकारी का उपयोग करने का सुझाव देते हैं, लेकिन आप { class, ... } नहीं लिख सकते क्योंकि यह एक सिंटैक्स त्रुटि होगी। तो कुल मिलाकर यह स्पष्ट नहीं है कि यह वास्तव में इसके साथ पालन करने के लिए पर्याप्त एर्गोनोमिक है। मुझे लगता है कि यह प्रशंसनीय है कि हम भविष्य में इस पर फिर से विचार करेंगे, या कम से कम class को चेतावनी न दें और लोगों को वह करने दें जो वे चाहते हैं। लेकिन अभी के लिए, हम इस विचार को ठंडे बस्ते में डाल देंगे।

नमस्ते, यह एक अच्छा लेख है!
सिर्फ यह जानना चाहता था कि क्या रिएक्ट-डोम उत्पाद के आकार को कम करने के लिए कोई योजना पाइपलाइन में है? मोबाइल एप्लिकेशन के लिए, यह अभी भी एक ओवरहेड है क्योंकि ब्राउज़र 100+ KB रिएक्ट-डोम जेएस और फिर अन्य मॉड्यूल को पार्स करेगा। फिर ऐप-विशिष्ट JS.
सामग्री-समृद्ध पृष्ठों के लिए, यह अधिक अवरोधन और अधिक TTI का कारण बन रहा है।

कोई विचार हम इस तरह के बदलाव कब देख सकते हैं?

@ morevolk-latei आपके माप में, 100 KB ReactDOM को पार्स करने में कितना समय लगता है?