यह एक बहुत अच्छा सवाल है। इसे बढ़ाने के लिए धन्यवाद!

यह एक ऐसा मामला है, जहाँ आप मैन्युअल रूप से पेड़ की पुनर्गणना का अनुकूलन / अनुकूलन कर रहे हैं। यह मुझे लगता है कि आपको किसी भी संदर्भ चर तक पहुंच का अनुरोध करने की आवश्यकता होगी जो आपकी गणना के लिए प्रासंगिक हो। यदि आवश्यक हो तो हम पूरी कल्पना (या यहां तक ​​कि पूर्ण संदर्भ) के हैश में पास की तरह अन्य फैंसी चीजें करने पर भी विचार कर सकते हैं।

@sebmark कचरा - विचार?

हाँ, समस्या यह है कि बीच के घटक यह नहीं जानते कि कुछ दूर के बच्चे को किस संदर्भ की आवश्यकता हो सकती है। ऐसा कोई तरीका नहीं है जिससे वे यह जान सकें कि contextTypes भी _be सक्षम_ को सही ढंग से shouldComponentUpdate लागू करने की घोषणा करने के लिए।

मुझे आश्चर्य है कि अगर प्रसंग अलग-अलग वृक्षों के जाल में हो सकता है, तो बिना shouldComponentUpdate बीच में अवरुद्ध किए बिना?

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

@gaearon मुझे लगता है कि उस मामले में आपको सब कुछ फिर से प्रस्तुत करने की आवश्यकता है और इसलिए shouldComponentUpdate का घटाने के उप-योग का प्रभाव नहीं होगा। अन्यथा संदर्भ तत्व पेड़ के साथ असंगत स्थिति में होगा।

@andreypopp

मुझे लगता है कि मध्य घटकों पर shouldComponentUpdate का कोई प्रभाव नहीं होना चाहिए कि क्या उनके वंशजों को नया संदर्भ प्राप्त होता है, जैसे कि उनका नया राज्य प्राप्त करने पर कोई प्रभाव नहीं है:

http://jsbin.com/geseduneso/2/edit?js , आउटपुट

(यदि यह मामला था, तो दोनों संख्या में वृद्धि होगी)

असंगति कहाँ है?

इसे अलग तरीके से रखने के लिए, मुझे लगता है कि context को ठीक उसी तरह काम करना चाहिए जैसे कि संदर्भ के मालिक के पास "स्टोर" जैसा कुछ होता है जिसके परिणाम में getChildContext() componentWillUpdate लिखा जाता है, और सभी वंशज संदर्भ उपभोक्ता जिन्होंने contextTypes में उस संदर्भ से चाबियाँ घोषित कीं, उन्हें यह संदर्भ प्राप्त करना चाहिए जैसे कि उन्हें उस "स्टोर" की सदस्यता दी गई थी और अपने स्वयं के राज्य को अपडेट किया था।

मुझे वास्तविक क्रियान्वयन से कोई मतलब नहीं है - लेकिन मैं बताना चाहता हूं कि यह मॉडल बीच में shouldComponentUpdate साथ किसी भी फ्लक्स ऐप की तुलना में अधिक असंगत नहीं है। संदर्भ को एक "साइडवे स्टोरेज" की तरह काम करना चाहिए, लेकिन एक उपप्रकार के लिए स्कूप किया गया।

संपादित करें: यह काम नहीं करेगा क्योंकि माता-पिता बदल सकते हैं

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

लेकिन फिर, एकमात्र उचित समाधान जो मुझे दिखाई देता है, वह पूरी तरह से संदर्भ परिवर्तन से मना करता है। यही है, getChildContext() getInitialState() समान बनाते हैं, जो घटक के माउंट होने से पहले केवल एक बार कॉल किया जाता है।

यह संदर्भ को सोचने के लिए एक नरक बहुत आसान बना देगा। हम कभी भी अद्यतन नहीं करते हैं क्योंकि हम shouldComponentUpdate से तीसरा पैरामीटर निकाल सकते हैं।

जब आप _need_ संदर्भ स्वामी से अपडेट करते हैं (उदाहरण के लिए जैसे प्रतिक्रिया-राउटर activeRoutes ActiveState mixin cc @mjackson में उपयोग के लिए टॉप-डाउन पास करना चाहता है), तो कुछ भी आपको { addChangeListener, removeChangeListener, getActiveRoutes } पास करने से रोकता है context । वंशज अब परिवर्तनों की सदस्यता ले सकते हैं और उन्हें state में डाल सकते हैं।

क्या यह एक उचित समाधान है?

मुझे लगता है कि उत्तर देने के लिए महत्वपूर्ण प्रश्न है:

किन परिदृश्यों में _data_ गुजर रहा है context props माध्यम से डेटा पारित करने के लिए बेहतर है या एक घटक को कॉल करने के लिए अपने स्वयं के setState कॉल करने के लिए एक घटना को ट्रिगर कर रहा है।

मैं काफी खुशी से चारों ओर वस्तु संदर्भों को पारित करने के लिए संदर्भ का उपयोग कर रहा हूं, क्योंकि मैं केवल उन वस्तुओं पर लिखता हूं, पढ़ा नहीं जाता। जैसे। this.context.triggerAction("something")

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

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

मुझे लगता है कि हम एक समाधान पा सकते हैं जो उपयोगकर्ताओं को श्रोताओं को तार-तार करने से बचाते हैं।

मुझे लगता है कि @andreypopp सही हो सकता है। या बहुत कम से कम, हमें यह जानने के लिए shouldComponentUpdate के लिए एक तरीका प्रदान करने की आवश्यकता है कि क्या संदर्भ में कुछ भी बदल गया है, इसलिए यह संदर्भ चर परिवर्तन होने पर हमेशा सही लौटने का निर्णय ले सकता है।

मैं आज बाद में @sebmarkbage से चैट

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

आउच। आप पूरी तरह से सही हैं, मैंने इस पर विचार नहीं किया है।

@jsfb एक दूसरे विचार पर, मैं आपकी टिप्पणी को काफी नहीं समझता। यदि आप एक मूल नोड की जगह लेते हैं, तो पूरा बच्चा सबट्री फिर से माउंट होगा, है न?

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

@sebmark कचरा और मैंने बातचीत की, और निम्नलिखित निष्कर्ष पर आए:

• shouldComponentUpdate एक जटिल एस्केप हैच है, जिसके कार्यान्वयन के लिए आपको घटक के तहत क्या हो रहा है, इसकी ठोस समझ होनी चाहिए। इस कारण से, यह मानना ​​अनुचित नहीं है कि आप जानते हैं कि कौन से संदर्भ चर का उपयोग किया जा रहा है, क्योंकि आपको पहले से ही यह जानना होगा कि कौन से गुणों का उपयोग किया जा रहा है और उनका उपयोग कैसे किया जा रहा है।
• यह परिवर्तन शायद स्थिति को पहले से बहुत बदतर नहीं बना रहा है, और यह पुराने "मालिक" रिश्ते का उपयोग करने पर एक सुधार है। इसलिए, यह मुद्दा अभी भी चर्चा के लायक है, लेकिन संभवतः गैर-अवरुद्ध है।
• संदर्भ इस बिंदु पर एक जटिल विशेषता / प्रयोग हैं, और हमें आधिकारिक तौर पर उनका समर्थन / दस्तावेज करने से पहले हमें और अधिक सोचने की आवश्यकता है। जैसा कि हम और अधिक सीखते हैं, हम संभवतः इस विषय पर चलना जारी रखेंगे।

@sebmark कचरा , मुझे पता है अगर मैं कुछ भी याद किया!

हालांकि अच्छी चर्चा! पूरी प्रतिक्रिया के लिए धन्यवाद!

इस पर चर्चा करने के लिए समय निकालने के लिए धन्यवाद!

यह मान लेना अनुचित नहीं है कि आप जानते हैं कि कौन से संदर्भ चर का उपयोग किया जा रहा है, क्योंकि आपको पहले से ही यह जानना होगा कि कौन से गुणों का उपयोग किया जा रहा है और उनका उपयोग कैसे किया जा रहा है।

अगर एक शीर्ष स्तर Feed घटक लागू shouldComponentUpdate का उपयोग करके PureRenderMixin अतिरिक्त अद्यतन से बचने के लिए, यह मतलब नहीं है कि Feed इसके अंदर है कि कहीं जानता है वहाँ एक Cell जो कि Link जो राउटर के संदर्भ पर निर्भर करता है।

यह तब और भी बदतर हो जाता है जब चौखटे (जैसे कि सबसे लोकप्रिय रिएक्ट रूटिंग फ्रेमवर्क ) संदर्भ का उपयोग करते हैं और आपको इसके बारे में पता भी नहीं हो सकता है। कहीं न कहीं, ऐसे ऐप हैं जो सक्रिय लिंक स्थिति को नहीं बदलते हैं क्योंकि किसी ने शीर्ष-स्तरीय घटकों को अनुकूलित किया है और शाब्दिक रूप से _no विचार_ नहीं था और उन्हें अपने shouldComponentUpdate contextTypes से _even get_ nextContext घोषणा करनी थी। shouldComponentUpdate ।

कोई रास्ता नहीं है घटकों को उनके संभावित वंशज _all के बारे में पता है। मूल रूप से, अगर मैं PureRenderMixin -सक्षम घटक के अंदर कहीं भी संदर्भ-निर्भर घटक को स्थानांतरित करता हूं, तो यह टूट जाएगा, लेकिन बहुत सूक्ष्म रूप से। इसलिए, यदि आप संदर्भ का उपयोग करते हैं, तो असंबंधित घटकों के इस सूक्ष्म विखंडन से बचने का एकमात्र तरीका _never_ है जो shouldComponentUpdate करता है जो कि इसके बारे में रिएक्ट क्या कह रहा है के खिलाफ जाता है।

रिएक्ट के शीर्ष पर कुछ रूपरेखाएँ, जैसे कि @swannodette ओम, PureRenderMixin -ish shouldComponentUpdate _default_ बनाते हैं, उन्हें इस तरह से काट देना अजीब है। इसका मतलब है कि उनके लिए हर घटक में संदर्भ-तोड़ shouldComponentUpdate ।

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

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

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

मुझे लगता है कि हमें जो करने की आवश्यकता है वह पैतृक पेड़ में कहीं भी एक नया संदर्भ होने पर shouldComponentUpdate । संभावित रूप से shouldUpdateChildContext या कुछ ऐसा होता है जो यह निर्धारित करता है कि पूरे उप-योग को समेटने की आवश्यकता है या नहीं।

@sebmarkbage

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

सही है, यह हमेशा बेकार था।

मुझे लगता है कि हमें क्या करने की ज़रूरत है अगर मूल पेड़ में कहीं भी एक नया संदर्भ है, तो byComponentUpdate पास होना चाहिए।

इसके बहुत सारे अर्थ निकलते हैं। माता-पिता में प्रसंग परिवर्तन उपसर्ग में shouldComponentUpdate s को गलत साबित करने की आवश्यकता है।

लेकिन यह सवाल भी पैदा होता है: जब संदर्भ बदलते हैं तो हमें कैसे पता चलता है? राज्य और प्रॉप्स के लिए हमारे पास setState और render / setProps । ऐसा लगता है कि हमें कहीं के आसपास वर्तमान संदर्भ की एक प्रति रखने और getChildContext के परिणाम के साथ इसे अलग करने की आवश्यकता होगी जब भी render कहा जाता है।

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

इसलिए, एक उदाहरण को देखते हुए,

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

var peopleStore = this.context.peopleStore;
var person = peopleStore.get(this.props.personId);
return <div>person.fullName</div>;

अवयव श्रोताओं को दुकानों में संलग्न करते हैं। मैंने पूरी तरह से ग्रैन्युलैरिटी पर फैसला नहीं किया है। सभी दुकानों में एक ऑनकॉन्ग इवेंट है। हालाँकि, मैंने दो अन्य बातों पर निर्णय नहीं लिया है,
1) व्यक्तिगत संपत्ति परिवर्तन के लिए श्रोता
2) अगर दुकानों में स्टोर होना चाहिए

इस उदाहरण में, यदि "लोग" "fb उपयोगकर्ता" थे, तो यह एक बड़ा जटिल एसिंक्स स्टोर है। क्या मुझे किसी व्यक्ति के लिए स्टोर संरचना का पुन: उपयोग करना चाहिए? सामान्य संग्रह के लिए एक (getFriends, getPerson, आदि) लेकिन एक व्यक्ति के लिए व्यक्तिगत स्टोर प्रकार के कई अनूठे उदाहरण हैं।

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

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

मैं आवेदन तर्क को पहले मौजूद लोगों के स्टोर को हटाने / नष्ट करने की उम्मीद करूंगा। उसके लिए, मेरे घटक को अपडेट के लिए सुनना बंद करना होगा। इसके लिए, मैं एक ReactClass एपीआई की सिफारिश करूंगा। उदाहरण के लिए,

onContextChange (प्रचलित, नया)

तत्व तब दो लोगों की तुलना कर सकता है। आइए सार्वजनिक डेटा को अनदेखा करें और मान लें कि नया PeopleStore शून्य है। तत्व पिछले स्टोर से अनसब्सक्राइब करेगा और रेंडर () को ट्रिगर करेगा। रेंडर तब कुछ 'उपयोगकर्ता अज्ञात' प्रकार संदेश दिखाएगा।

जब उपयोगकर्ता किसी अन्य उपयोगकर्ता के रूप में लॉग इन करता है, तो एक नया स्टोर बनाया जाता है, तत्व reattaches, और रेंडर () नए डेटा के साथ अपनी बात करता है।

पर्दे के पीछे, "this.render ()" तुल्यकालिक नहीं हो सकता है। मेरे किसी भी डिजाइन / उदाहरण के लिए किसी भी तरह से किसी भी तरह से बनाने के लिए, फ्रेमवर्क द्वारा रेंडर () कॉल को एकत्र करने और एक साथ बैचने की आवश्यकता है।

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

इसमें काफी रुचि है। (ऊपर संदर्भ देखें।)

हां @ बेयररॉन ।

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

यह सभी देखें
https://github.com/yahoo/react-intl/issues/58
https://github.com/facebook/react/issues/3038

@ सेलर मैंने एक कस्टम PureRenderMixin भी अपनाया, यह स्पष्ट रूप से बीच में कड़े shouldComponentUpdate s के साथ टूट सकता है, जैसा कि @gaearon कहते हैं (या यदि तीसरा पैरामीटर गायब हो जाएगा)। आप हमेशा प्रॉप्स पर भरोसा कर सकते हैं। आइए देखें कि यह मुद्दा कैसे विकसित होगा :)

@gpbl जाँच करें कि:
https://github.com/facebook/react/issues/3038#issuecomment -76449195

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

@slorber unmountComponentAtNode कॉल करने से उपयोगकर्ता का बुरा अनुभव होता है, क्योंकि यह सभी स्थानीय स्थिति का नुकसान होता है।

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

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

@ मेरे लिए यह स्थानीय स्थिति को ढीला करने की समस्या नहीं है, क्योंकि मेरे पास कोई स्थानीय राज्य नहीं है और मेरा पूरा ऐप पूरी तरह से रिएक्ट के बाहर अपरिवर्तनीय स्थिति का प्रबंधन करता है :) फ्रेमवर्क के लिए मैंने जो वीडियो बनाया है, उसकी जांच करें: https: / /github.com/stample/atom-react

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

हां, shouldUpdateChildContext इसे अच्छा और सममित बनाता है।

इसके लिए कोई मौका 0.14 में जाने के लिए?

यदि आप एक अच्छा एपीआई डिजाइन करते हैं और इसे लागू करते हैं। :)

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

यह संभावना नहीं है कि हमारी पूर्णकालिक कोर टीम के पास इसके लिए समय होगा। :(

9 अप्रैल 2015 को, 1:32 बजे, दान अब्रामोव सूचनाएं @github.com ने लिखा:

इसके लिए कोई मौका 0.14 में जाने के लिए?

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें।

ज़रूर, मैं देख लूँगा!

क्षमा करें दोस्तों, मुझे अभी भी इस पर काम शुरू करने का समय नहीं मिल रहा है। लंबित रिएक्शन डीआईएनडी 1.0 रिलीज के बाद मैं इस तैयारी के लिए व्यस्त हो जाऊंगा, इसलिए इसकी बहुत संभावना नहीं है कि मैं जल्द ही इस पर काम कर पाऊंगा। :-(

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

एक बात जो मैं सोच रहा था कि निम्नलिखित कथन सत्य है या नहीं:

एक घटक के बच्चे का संदर्भ _always_ होना चाहिए यह राज्य सहारा, और संदर्भ की कमी है

यह सुनिश्चित करता है कि हम ज्ञात जीवनचक्र के भीतर डेटा को विश्वसनीय रूप से प्रवाहित कर सकते हैं। यह इस कथन के समान है कि "एक घटक का प्रस्तुतिकरण हमेशा राज्य और सहारा की कमी है"।

यह है कि मैं वर्तमान में इसे कैसे लागू कर रहा हूं - यह देखना अच्छा होगा कि क्या मैं पूरी तरह से बंद हूं!

shouldUpdateChildContext यह निर्धारित करता है कि क्या उप-पेड़ को नए संदर्भ के साथ अद्यतन किया जाना चाहिए। जीवनचक्र के इस हिस्से को घटक के राज्य के प्रॉप्स या संदर्भ में बदलाव से ट्रिगर किया जाता है।

shouldComponentUpdate 3 मापदंडों के साथ रहता है इसलिए उपर्युक्त उप-वृक्ष में एक घटक यह तय कर सकता है कि क्या इसे वास्तव में कुछ भी अपडेट करना चाहिए (ध्यान दें: यहां झूठे लौटना उप-वृक्ष के नीचे बहने वाले संदर्भ को प्रभावित नहीं करता है)

एक और बात मैं यहाँ सोच रहा हूँ कि क्या कोई दूसरा नया जीवनचक्र तरीका componentWillReceiveContext होना चाहिए? - समान समय पर componentWillReceiveProps पर कॉल किया जाता है, लेकिन संदर्भ डेटा प्रवाह में होता है। यहाँ संभव है कि इन दोनों विधियों को "उसी समय" कहा जाए।

@Chrisui

कृपया इस पर कूदें! मैं इस समय अन्य सामान के साथ व्यस्त हूं।

यह सुनिश्चित करता है कि हम ज्ञात जीवनचक्र के भीतर डेटा को विश्वसनीय रूप से प्रवाहित कर सकते हैं।

यह भी ध्यान रखें कि 0.14 में observe हुक हो सकता है या लागू नहीं हो सकता है । जिसका अर्थ है कि data / observed / जो कुछ भी कहा जाता है, प्राप्त नहीं किया जा सकता है। लेकिन यह शायद आपके कार्य के लिए अप्रासंगिक है।

मेरे कांटे पर इस का एक बहुत प्रारंभिक मसौदा मिला है और आप इसे examples/context/index.html पर चलते हुए देख सकते हैं

मैं एक साधारण "संदर्भ माता-पिता" / "संदर्भ बच्चे" संबंध स्थापित करने के साथ गया हूं। एक "संदर्भ माता-पिता" कोई भी घटक है जो इसे बदल सकता है बाल संदर्भ (यानी, childContextTypes ) है और "संदर्भ बच्चा" कोई भी घटक है जो संदर्भ पर निर्भर करता है या बदल सकता है यह बाल संदर्भ (यानी। contextTypes या childContextTypes )। जब घटक वर्तमान में माउंट किए जाते हैं तो यह संबंध सेटअप होता है।

जब घटक अद्यतन जीवनचक्र खेल में आता है तो हमारे पास दो मामले आते हैं:

1. यदि घटक का कहना है कि _not_ अपडेट करें (यानी shouldComponentUpdate() === false ) तो हम जांचते हैं कि क्या हमें shouldUpdateChildContext साथ बाल संदर्भ को अपडेट करना चाहिए। यदि यह true (डिफ़ॉल्ट) है, तो यदि इस घटक में कोई भी "संदर्भ बच्चे" हैं, हम बच्चे के घटक को अद्यतन जीवनचक्र में बदल देते हैं। यह तब तक जारी रहता है जब तक हम संदर्भ वृक्ष के अंत तक नहीं पहुंच जाते हैं या हम shouldUpdateChildContext() === false भर में आ जाते हैं
2. अगर किसी कंपोनेंट का अपडेट अपडेट है तो कुछ भी अलग नहीं है। इस मामले में संदर्भ डेटा का कोई साइड चैनलिंग नहीं है और हम सामान्य प्रवाह को तब तक जारी रहने देते हैं जब तक कि कोई घटक # 1 केस को हिट नहीं कर सकता।

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

एक त्वरित psuedo- उदाहरण के लिए निम्नलिखित पर विचार करें:

<Root num={1}>  // Gives context {num: this.props.num}
  <Mid>         // Ignores any context and shouldComponentUpdate() === false
    <Child>     // Requires context {num: propTypes.number}

शुरुआती रेंडर (माउंटिंग) के लिए सब कुछ वैसा ही है जैसा हम उम्मीद करते हैं। (Impl। विस्तार: एक माता-पिता / बच्चे का संबंध Root और Child के बीच निर्मित होता है)

हम Root num 2 मूल्य का मूल्य अपडेट करते हैं

<Root num={2} />

Mid भी shouldComponentUpdate() पद्धति लागू करती है जो false लौटती है क्योंकि यह render() पद्धति context.num बारे में परवाह नहीं है और कुछ भी नहीं बदला है - तो इसे अपडेट क्यों करना चाहिए?

यह वह जगह है जहां पुराने मामलों में Child घटक कभी भी नए संदर्भ को नहीं देखेगा क्योंकि हमने पेड़ से नीचे अपडेट प्राप्त किया है।

इन परिवर्तनों के साथ अब हम shouldUpdateChildContext() Mid shouldUpdateChildContext() विधि की जाँच करते हैं (जो हम डिफ़ॉल्ट क्रियाओं को हमारे उदाहरणों में कर सकते हैं) एक साधारण समानता की जाँच करें कि क्या कोई संदर्भ मान है बदला हुआ। नोट: shouldUpdateChildContext() का हस्ताक्षर वर्तमान में shouldComponentUpdate() समान है।

यदि shouldUpdateChildContext() true (यह डिफ़ॉल्ट रूप से है) तो हम अपने निकटतम 'संदर्भ बच्चों' में से प्रत्येक को अपडेट करते हैं (उदाहरण मामले में Child ) यदि कोई संबंध पहले से सेटअप था । यह उस घटक को अद्यतन जीवनचक्र में डाल देगा (जो मैंने पहले देखी गई चर्चाओं के विपरीत है। _still_ shouldComponentUpdate() _

उम्मीद है कि इस प्रक्रिया को अच्छी तरह से समझाता है!

@ क्रिसहुई कूल, इस पर कुछ प्रगति देखने के लिए महान! हमें इकाई परीक्षणों का एक समूह भी करना चाहिए जो कि बुनियादी कार्यक्षमता की जांच करता है। न्यूनतम:

• यदि पैरेंट shouldComponentUpdate() रिटर्न गलत है तो भी बच्चे के अपडेट की पुष्टि करें।
• यदि माता-पिता shouldUpdateChildContext() झूठे हैं तो भी बच्चे के अपडेट की पुष्टि करें।
• सत्यापित करें कि घटक shouldUpdateChildContext() गलत होने पर बच्चा अपडेट नहीं करता है।

इसके अतिरिक्त, यदि ये समर्थित सुविधाएँ हैं, तो हम सत्यापित करना चाहते हैं:

• सत्यापित करें shouldUpdateChildContext() नहीं कहा जाता है अगर एक दादा दादी उनके प्रदान किए गए संदर्भ को बदलता है, लेकिन एक प्रत्यक्ष माता-पिता उस संदर्भ को ओवरराइड करता है और बदलता नहीं है।
• सत्यापित करें कि घटक बदले गए संदर्भ चर से नहीं पढ़ता है, तो shouldUpdateChildContext() नहीं मिलता है।
• सत्यापित करें कि यदि कोई प्रोप बदलता है और संदर्भ चर बदलता है, तो हम दो बार अपडेट / रेंडर नहीं करते हैं।

cc: एपीआई डिजाइन / विचार पर प्रतिक्रिया के लिए @sebmark कचरा ।

@ क्रिसहुई यह अब तक शानदार लग रहा है, इस काम को करने के लिए धन्यवाद।

@jimfb निश्चित रूप से कुछ इकाई परीक्षण प्राप्त करना शुरू कर देगा - बस इसके साथ खेलने के लिए कुछ करना चाहता था और पुष्टि करता है कि हम सभी को लगता है कि इसके साथ काम करना चाहिए!

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

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

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

मेरे पास एक त्वरित हैक होगा और इसे अभी मॉक करने की कोशिश करें!

वास्तव में कार्यक्षमता के विशिष्ट संदर्भ प्रमुख तुलनात्मक भाग के लिए मेरे बाद के सुझाव के बारे में यह अद्यतन क्रम को बनाए रखने के लिए उतना मुश्किल नहीं हो सकता है अगर हम पहले से ही उपयोग किए गए माउंट ऑर्डर बैच तर्क द्वारा छाँटे गए समान का पालन करते हैं!

@Chrisui @sebmark कचरा तो मेरी चिंता (जब तक कि मैं कुछ स्पष्ट नहीं भूल / याद कर रहा हूं) यह है कि हर बार एक संदर्भ-प्रदाता फिर से प्रस्तुत करता है, यह बच्चे के सभी घटकों (संभावित सैकड़ों) का कारण होगा जो प्रदान किए गए संदर्भ चर पर निर्भर करता है भले ही संदर्भ चर नहीं बदला है, फिर से प्रस्तुत करना। मेरा अंतर्ज्ञान यह है कि हमें केवल एक संदर्भ पुन: प्रसार को ट्रिगर करना चाहिए अगर हमारे पास कुछ प्रकार का संकेत है कि एक नया मूल्य उपलब्ध है (जैसे नया मूल्य ट्रिपल मूल्य पुराने मूल्य या कुछ ध्वज / अधिसूचना के बराबर नहीं है)।

दरअसल, यह कार्यान्वयन एक सदस्यता प्रणाली की तरह लग रहा है। चूँकि context प्रभावी रूप से एक स्कोप ग्लोबल है, हो सकता है कि सही समाधान के लिए संदर्भ चर की सदस्यता के लिए घटकों की आवश्यकता होती है, जिससे हमें संदर्भ के लिए उसी तंत्र का उपयोग करने की अनुमति मिलती है जिसे हम अन्य सभी सदस्यता के लिए उपयोग करने जा रहे हैं। डेटा। Https://github.com/facebook/react/issues/3398 , https://github.com/facebook/react/issues/3858 , और https://github.com/facebook/react/pull/3920 देखें प्रासंगिक जानकारी।

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

@jimfb आप सैकड़ों घटकों को फिर से प्रस्तुत करने के बारे में सही हैं, लेकिन मुझे यकीन नहीं है कि यह अब अलग है अगर आप कुछ राज्य परिवर्तन को ट्रिगर करते हैं और एक बड़े पैमाने पर अद्यतन को रोकने से रोकने के लिए shouldComponentUpdate को लागू करना होगा।

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

ब्याज से बाहर मैंने अपने मसौदे में कार्यक्षमता को केवल घटकों के बीच माता-पिता / बच्चे के संबंध बनाने के लिए जोड़ा है यदि उनके पास एक मिलान संदर्भ / बाल संदर्भ कुंजी है (निरर्थक पेड़ ट्रैवर्सल रोकता है) और एक अद्यतन को रोकना अगर संदर्भ वास्तव में नहीं बदला है तो बस के साथ किया जाएगा हमेशा की तरह PureRenderMixin।

@Chrisui मुझे लगता है कि अंतर यह है कि एक बच्चे के घटक में एक एकल shouldComponentUpdate पेड़ की विशाल शाखाओं को काट सकता है, जबकि संदर्भ के साथ, उन सभी स्थानों को ढूंढना / ठीक करना बहुत कठिन है जो फिर से प्रदान किए जाएंगे। यहां तक ​​कि अगर आप जमानत करते हैं, तो एक बच्चा जो संदर्भ चर पर निर्भर करता है, फिर भी रेंडर करेगा।

हां, मैं यह देखने के लिए उत्सुक हूं कि अन्य लोग डेटा लोडिंग समाधान के उपयोग के बारे में क्या सोचते हैं।

मुझे लगता है कि डेटा लोड करने के संदर्भ में ज्यादातर ऑर्थोगोनल है

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

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

26 मई 2015 को 22:10 बजे, जिम नोटिफिकेशन @ithub.com ने लिखा:

@Chrisui मुझे लगता है कि अंतर यह है कि एक बच्चे के घटक में एक एकल shouldComponentUpdate पेड़ की विशाल शाखाओं को काट सकता है, जबकि संदर्भ के साथ, उन सभी स्थानों को ढूंढना / ठीक करना बहुत कठिन है जो फिर से प्रदान किए जाएंगे। यहां तक ​​कि अगर आप जमानत करते हैं, तो एक बच्चा जो संदर्भ चर पर निर्भर करता है, फिर भी रेंडर करेगा।

हां, मैं यह देखने के लिए उत्सुक हूं कि अन्य लोग डेटा लोडिंग समाधान के उपयोग के बारे में क्या सोचते हैं।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें।

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

class Mid extends Component {
  shouldComponentUpdate() { return false; }
  shouldUpdateChildContext() { return false; }
  ...
}

मैं संदर्भ के सापेक्ष सादगी से खुश हूं क्योंकि यह खड़ा है + shouldUpdateChildContext। उम्मीद है कि अंतर्निहित तंत्र अन्य वैश्विक सब्सक्रिप्शन के अनुरूप हो सकता है और इसका उपयोग बहुत आसानी से कम नहीं करेगा।

@jimfb
जैसा कि @eplawless ने बताया है कि

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

एक अन्य सुझाव: हम इस नए व्यवहार को डिफ़ॉल्ट रूप से रोकने और इसे ऑप्ट-इन बनाने के लिए झूठी toUpdateChildContext () को भी गलत बना सकते हैं।

पुनरावृत्ति की खातिर और परीक्षण करने के लिए जंगली में कुछ प्राप्त करना (उसी शैली में संदर्भ की विशेषता हमेशा से रही है - इसलिए अनैच्छिक) क्या हमें 0.14 के लिए इस एपीआई प्रस्ताव को आगे बढ़ाना चाहिए? (द्वारपालों से सुनना अच्छा होगा!)

मैंने आपके लिए एक PR खोला: https://github.com/facebook/react/pull/3973

यह अधिक संभावना है कि आपको पीआर पर त्वरित प्रतिक्रिया मिलेगी क्योंकि वे मास्टर की तुलना में अधिक आसानी से समीक्षा करने योग्य हैं और मुद्दों पर प्राथमिकता प्राप्त करते हैं।

आप जानते हैं कि मुझे लगता है कि मैं मूल रूप से shouldUpdateChildContext बारे में गलत था। क्या हमें वास्तव में इसकी आवश्यकता है? थ्रश के बारे में क्षमा करें।

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

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

मैं इसके बारे में कुछ और सोचूंगा और विवरण के साथ पीआर पर टिप्पणी करूंगा ...

@sebmark कचरा मैं shouldUpdateChildContext पर किसी भी तरह से जा सकता था। मेरी प्राथमिकता हमेशा एपीआई सतह को कम करने की होती है। हम इसे हमेशा प्रारंभिक API से बाहर छोड़ सकते हैं (संदर्भ केवल इसके माध्यम से कूदता है और संदर्भ चर को पढ़ता है किसी भी घटक पर पुन: रेंडर करता है)। यदि लोगों को अतिरिक्त पलायन हैच की आवश्यकता होती है, तो हम इसे बाद में जोड़ते हैं।

मुझे लगता है कि @mjackson ने कहा कि बड़ी समस्या यह है कि हम नहीं जानते कि संदर्भ चर कब बदल गया है। क्या हम वास्तव में हर fbt / i18n टेक्स्ट नोड को हर बार फिर से प्रस्तुत करना चाहते हैं, i18n कॉन्टेक्स्टप्रॉइडर फिर से रेंडर करने के लिए होता है? हमने अभी तक यह कहने का तरीका प्रदान नहीं किया है कि "चिंता न करें, कुछ भी नहीं बदला है, पृष्ठ पर प्रत्येक पाठ तत्व को फिर से प्रस्तुत करने के लिए परेशान न करें"।

मैं आपके अंतिम पैराग्राफ के बारे में थोड़ा भ्रमित हूं; क्या आप विस्तार से समझा सकते हैं? मुझे लगता है कि आप सुझाव नहीं दे रहे हैं कि निम्नलिखित संदर्भ का एक विरोधी पैटर्न है: एक i18n घटक सभी i18n- जागरूक बाल घटकों को उपयोगकर्ता की पसंदीदा भाषा / समयक्षेत्र / स्वरूपण / आदि के लिए 'प्रसारण' करता है।

पीआर पर टिप्पणी की, यहाँ पुन: प्रस्तुत करना चाहिए मुझे लगता है:

@sebmarkbage @Chrisui @jimfb

पुन :: shouldUpdateChildContext , मुझे लगता है कि यह एक उपयोगी अतिरिक्त है। डिफ़ॉल्ट रूप से shouldComponentUpdate रिटर्न सही है, जो यह निर्धारित करने के लिए बच्चे की जिम्मेदारी बनाता है कि क्या कुछ बदल गया है। shouldComponentUpdate लागू करने का अर्थ है कि आप उस ज़िम्मेदारी को उस मामले में दूर ले जा रहे हैं जहाँ माता-पिता बेहतर जानते हैं। यह shouldUpdateChildContext का सच है, यह केवल अनुकूलन के रूप में अपने बच्चों से जिम्मेदारी लेने के लिए मौजूद है।

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

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

मैंने वास्तव में सोचा था कि "वर्महोल" पैटर्न एंटीपैटर्न था, और प्रसारण अपेक्षित पैटर्न था। प्रसंग केवल तभी दिलचस्प होता है जब चर के बहुत सारे उपभोक्ता होते हैं (अर्थात यदि प्रस्ताव को स्पष्ट रूप से पास करने से परिणाम लगभग हर घटक में जोड़ा जाएगा और इसलिए बहुत अधिक बॉयलरप्लेट है), अन्यथा, संभवतः इसे स्पष्ट रूप से पारित करने के लिए बेहतर है सहारा। लेकिन @sebmark कचरा ने कहा कि इसके विपरीत (और वह आमतौर पर इस सामान के बारे में सही है), इसलिए अब मैं उलझन में हूं और उससे स्पष्टीकरण प्राप्त करना चाहूंगा।

@sebmark कचरा @eplawless वर्महोल पैटर्न का एक उदाहरण है जो आपको लगता है कि वैध है? माता-पिता क्या प्रदान कर रहे हैं, इसका उपयोग बच्चे द्वारा कैसे किया जा रहा है, यह सिर्फ बच्चे पर एक प्रस्ताव क्यों नहीं हो सकता है, आदि।

<Table>
  <Cell />
  <Cell />
  <FancyCell />
</Table>

class FancyCell {
  render() {
    return <SomeWhatFancyCell>Some content</SomeWhatFancyCell>;
  }
}

class SomeWhatFancyCell {
  render() {
    return <Cell>{this.props.children}</Cell>;
  }
}

borderWidth और इसे तालिका में borderLeft/Top/Right/Bottom के रूप में सभी कक्षों में पास करें।

एक साफ तरीका यह है कि borderWidth से <Table /> , इसे विभाजित करें और संदर्भ से गुजरें।

यह किसी ऐसी चीज के लिए एक रास्ता प्रदान करता है जो किसी सेल को अपने वैचारिक माता-पिता के साथ एक छिपे हुए चैनल के माध्यम से तालिका के रूप में संवाद करने के लिए प्रस्तुत कर सकता है। यह पहले से ही डोम तत्व एक दूसरे के साथ करते हैं और संभवत: रिएक्ट में लेआउट करने के लिए आवश्यक है।

एक "संदर्भ" की अवधारणा पर ओवरफोकस न करें। वर्तमान अवधारणा आदर्श नहीं है। हो सकता है कि आदर्श दो अलग अवधारणाओं या किसी अन्य चैनल की तरह हो?

प्रशंसनीय वैकल्पिक एपीआई:

class Table {
  render() {
    var w = this.props.borderWidth;
    var borderStyle = { left: w, right: w, top: w, bottom: w };
    return <context key={someSymbol} value={borderStyle}>{this.props.children}</context>
  }
}
class Cell {
  static contextKey = someSymbol;
  render() {
    var borderStyle = this.context;
    ...
  }
}

बस यहाँ थूकना है।

स्पिटबॉलिंग जारी है ...

एक वैकल्पिक वाक्यविन्यास का उपयोग कर सकता है ...

<Table borderStyleChannelKey="myKey">
  <Cell borderStyle={myKey} />
  <Cell borderStyle={myKey} />
  <FancyCell borderStyle={myKey} />
</Table>

अब आपने संचार चैनल को स्पष्ट कर दिया है, नाम के टकराव और आदि की सभी संभावनाओं से बचा है (https://github.com/reactjs/react-future/pull/28)

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

Btw, प्रतिक्रिया का सार पहले से ही एक छिपा संचार चैनल है: राज्य। यह स्पष्ट रूप से प्रत्येक बच्चे के माध्यम से पारित नहीं करता है।

इसे 'बॉर्डर स्टाइल' के बजाय 'स्टाइलिनफो' या 'सीलडेटा' कहें, और इसे एक वस्तु बनाएं। फिर फ़ील्ड / जानकारी को जोड़ने के लिए Table और Cell बीच API अनुबंध को बदलने की आवश्यकता नहीं है।

मेरे वैरिएंट और आपके वैरिएंट के बीच एकमात्र अंतर यह है कि (मेरे वेरिएंट में) बच्चे के लिए वास्तव में "रीड" करने का एकमात्र तरीका यह है कि वह पैरेंट से एक प्रॉप के रूप में स्पष्ट रूप से पास हो। कार्यात्मक रूप से, आपका नवीनतम प्रस्ताव वस्तुतः https://github.com/reactjs/react-future/pull/28 से मेरे प्रस्ताव के समान है

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

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

मेरा मतलब एक वैश्विक प्रतीक (राजधानी एस) है जिसे किसी चैनल के माध्यम से एक सामान्य मॉड्यूल के रूप में परिक्रमा करनी होगी। https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol

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

ओह, आईसी, @sebmark कचरा फिर से फैंसी नई जावास्क्रिप्ट खींच रहा है :)। मुझे पता होना चाहिए; वह आज TC39 की बैठक में हैं।

ठीक है, तुम सही हो। यह नाम संघर्ष से बचने में बहुत प्रभावी होगा, और प्रसारण समस्या को हल करेगा। तुमने मुझे बेच दिया है। मुझें यह पसंद है!

काश आज तुम दफ्तर में होते! मुझे लगता है कि यह व्यक्ति में होने के लिए एक काल्पनिक आकर्षक बातचीत होगी!

व्यक्तिगत रूप से मुझे खुशी है कि वह नहीं था, क्योंकि यह हम सभी को भी लूप में रखता है ;-)।

मुझे सिंबल वाली चीज बहुत पसंद है। एक संभावित विदेशी पेड़ पर स्ट्रिंग कुंजी पर संदर्भ की अधिक निर्भरता हमेशा कुछ बुरा खिंचाव थी।

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

निष्पक्ष होने के लिए, प्रतीकों को पहले से ही वर्तमान वस्तुओं पर काम करना संभव है। यहां तक ​​कि अगर आप प्रतीक का उपयोग करते हैं, तो आप संभवतः एक संभावित वैश्विक नामस्थान जैसे कि npm शीर्ष स्तर मॉड्यूल नाम (हालांकि उम्मीद है कि यह सापेक्ष है) के माध्यम से एक मॉड्यूल की आवश्यकता होती है।

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

@sebmark कचरा आप UUIDs (उर्फ प्रतीक) का उपयोग कर सकते हैं, हाँ, लेकिन आपका नया प्रस्ताव कुंजी को रनटाइम पर तय करने की अनुमति देता है, जिसका अर्थ है कि मूल COULD इसे प्रॉप्स के माध्यम से प्रभावित करता है (सुनिश्चित करें कि आप उस बारे में क्या सोचते हैं हालांकि) नहीं। यह कहते हुए कि, मुझे यकीन नहीं है कि जेएसएक्स के दायरे में उपलब्ध मूल्यों के बिना यह कितना उपयोगी है, मुझे इस पर अधिक सोचने की आवश्यकता होगी, लेकिन यह कुछ शांत लचीलेपन (शायद) को जोड़ता है।

मैं "वर्महोल" सादृश्य के बारे में इतना निश्चित नहीं हूं, प्रसारण परिदृश्य और i18n उदाहरण वे हैं जहां मैं समस्या में चला गया हूं प्रस्तावित पीआर को हल करना है।

मैं यह भी पूरी तरह से स्पष्ट नहीं कर पाया कि https://github.com/facebook/react/issues/2517#issuecomment -106597895 कैसे मदद करता है - यह शब्दशः रूप से मुझे प्राप्त होने वालेChildContext और referenceTypes के बराबर लगता है।

मुझे shouldUpdateChildContext PR के बारे में क्या पसंद है कि यह संदर्भ परिवर्तन का प्रचार करने के लिए किसी भी गहराई से सभी बच्चों की गणना करने की आवश्यकता नहीं है।

AIUI मूल समस्या हमेशा से थी, हालांकि shouldComponentUpdate context पारित किया गया है, संदर्भ की प्रकृति का अर्थ है कि "ब्रॉडकास्टर" और "रिसीवर" के बीच के घटक झूठे लौट सकते हैं क्योंकि यह संदर्भ नहीं जानता था इसे पारित कर रहा था।

ऐसा लगता है कि इस मुद्दे के आसपास आने के दो तरीके ट्रैक करने के लिए हैं कि कौन से घटक पेड़ में उनके ऊपर एक संदर्भ से पढ़ रहे हैं, या पेड़ के नीचे संदर्भ परिवर्तन के प्रचार के लिए एक अतिरिक्त तंत्र है।

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

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

संदर्भ स्पष्ट रूप से उन घटकों से कुछ हद तक "संरक्षित" होने की आवश्यकता है जिनके पास विशेष संदर्भ के साथ कोई व्यवसाय नहीं है _ लेकिन _ अगर घटक को चाहिए तो डेटा स्ट्रीम में कूदने के लिए सरल होने की आवश्यकता है। हमारे फॉर्म घटकों के विशिष्ट मामले में, Form अधिकांश बच्चों को उस संदर्भ से अलग किया जाना चाहिए जो नीचे से गुजरता है, और केवल Field घटक को इसे प्राप्त करना चाहिए। हालाँकि, यदि कोई उपभोक्ता एक HoC में ( Field ) डिफॉल्ट (व्यवहार को समायोजित करने या व्यवहार को समायोजित करने के लिए) को लपेटना चाहता है, तो ऐसा करने के लिए कुछ सरल तरीका होना चाहिए।

जो सभी को यह कहना है कि किसी भी संदर्भ एपीआई को वास्तव में मध्यवर्ती (अधिकृत) घटकों को अनुमति देने के लिए कहा जाना चाहिए, जैसा कि संदर्भ के लिए reducers के रूप में कार्य करता है, उसी तरह घटक बच्चों को पास करने के लिए / मैप प्रॉप्स को कम कर सकते हैं। अंतर यह है कि जबकि प्रॉप्स एक "सार्वजनिक" भाप हैं, संदर्भ एक निजी, ऑप्ट इन, स्ट्रीम है

मैंने प्रतिक्रिया-पक्ष-संदर्भ में सदस्यता आधारित संदर्भ के विचार के साथ थोड़ा सा खेला है।

हुड के तहत, प्रसारक प्रसारकों ने अपने बच्चों को { subscribe(key, cb), getValue(key) } इंटरफ़ेस दिया। एक संदर्भ कुंजी की सदस्यता तब तक संदर्भ ट्री को बुलबुले बना देती है जब तक कि वह उस विशेष कुंजी या पेड़ के शीर्ष के ब्रॉडकास्टर तक नहीं पहुंच जाती। प्रसारक broadcast({ [key]: newValue, ...otherKeys }) माध्यम से संदर्भ कुंजियों में परिवर्तन का उत्सर्जन करते हैं।

@broadcasts([...keys]) और @observes([...keys]) वर्ग सज्जाकारों ने इस API को रिएक्ट घटकों में बाँध दिया है, घटक ट्री के माध्यम से संदर्भ ट्री को प्रचारित करने के लिए context का उपयोग कर रहे हैं और setState को अपडेट अपडेट करने के लिए एक संदर्भ परिवर्तन की प्रतिक्रिया।

बॉयलरप्लेट के एक बिट के साथ, आप वर्तमान shouldUpdateChildContext प्रस्ताव के बराबर एक एपीआई सेटअप कर सकते हैं।

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

मैंने कभी भी किसी भी डायनामिक मान को नीचे लाने के लिए संदर्भ का उपयोग नहीं किया है, केवल अपरिवर्तित संदर्भ। मुझे यहाँ कुछ खिलौना उदाहरण दिखाई देते हैं, लेकिन क्या किसी ने इसका उपयोग उत्पादन ऐप्स में गतिशील मूल्यों को पारित करने के लिए किया है? मैं अक्सर वास्तविक दुनिया के मामलों को अधिक ज्ञानवर्धक पाता हूं।

उदाहरण के लिए I18n के लिए, क्या कोई भी कुंजी-मूल्य जोड़े को सीधे पारित कर रहा है? या आप बस एक अपरिवर्तित संदर्भ को पास कर रहे हैं एक वस्तु घटकों से मान प्राप्त कर सकते हैं और निरीक्षण कर सकते हैं?

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

अपने 2 सेंट को यहाँ जोड़ने के लिए, मैं दृढ़ता से पसंद करूँगा अगर यहाँ कोई भी फिक्स इस तरह से लागू किया गया हो कि StaticContainer न टूटे।

मुझे लगता है कि यह सबसे अधिक समझ में आता है StaticContainer ने काम करना जारी रखा, और माता-पिता से आने वाले सभी अपडेट को अवरुद्ध कर दिया, दोनों props और context ।

IMO को संभालने का सबसे अच्छा तरीका यह होगा कि shouldComponentUpdate को संभवतः बच्चों द्वारा उपयोग किए जाने वाले संदर्भों में संभावित रूप से परिवर्तन का पता लगाने के बजाय shouldComponentUpdate पूरी तरह से अनदेखा करें जब भी संदर्भ शामिल हो।

@ jedwards1211 मेरा उपयोग मामला एक I18nProvider घटक के अंदर अनुवाद संदेश लाने और फिर Jed उदाहरण (गेटटेक्स्ट विधियों के साथ) पास करने के लिए होगा।

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

मुझे वास्तव में दृश्य घटकों में gettext() कॉल करने की आवश्यकता है ताकि मैं स्ट्रिंग्स निकाल सकूं (इस मामले में xgettext का उपयोग करके)।

Reactiflux पर @jquense के साथ इसे चारों ओर मारना; अगर वहाँ एक "सुपर थे यह उपयोगी होगा false " के लिए अवधारणा shouldComponentUpdate ।

हालांकि सामान्य तौर पर ऐसा लगता है कि संदर्भ अद्यतन shouldComponentUpdate false (या कम से कम यह सबसे अधिक उपयोग के मामलों को सरल बना देगा) का प्रचार करना चाहिए, मुझे भी लगता है कि <StaticContainer> जैसे विशेष मामले हैं <StaticContainer> ।

उदाहरण के लिए, https://github.com/rackt/react-router/pull/2454 पर विचार

मैं समझौता कर रहा हूं कि shouldComponentUpdate false रिटर्न के लिए व्यवहार को संदर्भ अपडेट को अवरुद्ध नहीं करना चाहिए, लेकिन <StaticContainer> रखने के लिए SUPER_FALSE प्रहरी के कुछ प्रकार होने चाहिए। <StaticContainer> रूप में काम कर रहा है।

@taion

ट्रांसफ़ॉर्मिंग-आउट रूट घटक पर सक्रिय स्थिति को लिंक करने के लिए अपडेट को आसानी से रोकने में सक्षम नहीं होगा।

मैं उलझन में हूँ, वांछित उपयोग का मामला क्या है? सामान्य तौर पर, अपडेट को अवरुद्ध करने के लिए shouldComponentUpdate उपयोग नहीं किया जाना चाहिए, जिसके परिणामस्वरूप UI परिवर्तन होगा। यह एक संकेत है जो विशुद्ध रूप से एक अनुकूलन तंत्र के रूप में है जो आपको अनावश्यक सुलह कार्य करने से बचने की अनुमति देता है।

@jimfb आप पहले से ही रिले में <StaticContainer> का उपयोग कर रहे हैं, हालांकि - हालांकि, अपने डेटा को लोड करते समय अपडेट ब्लॉक करने के लिए।

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

ऐसा लगता है कि वर्तमान में यह हमेशा पूरा हो रहा है, जबकि नया राउटर राज्य लोड हो रहा है, हमेशा false shouldComponentUpdate लौट रहा है।

@ अंत में मैं रिले लोगों के साथ बात करूंगा और यह पता

cc @sebmark कचरा

@jimfb

शायद आपके लिए ऐसा करना आसान हो (:

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

false shouldComponentUpdate , रिले रूट कंटेनर / रेंडरर के पास जो कुछ भी पहले था, उसे रेंडर करने का एक आसान तरीका है।

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

@taion हाँ, मैं समझता हूँ कि यह क्या कर रहा है, लेकिन मुझे संदेह है कि यह एक पैटर्न है जिसका हम समर्थन करना चाहते हैं। मैं सेबस्टियन और रिले लोगों के साथ बात करूंगा, लेकिन मेरा अनुमान है कि उत्तर "हाँ, यह हैक था, ऐसा मत करो"।

आम तौर पर, जिस तरह से आप उस व्यवहार को पूरा करते हैं, वह पुराने मूल्यों को राज्य में लाने के लिए है (जब तक कि नए मूल्य दिखाई / न आए हों) और राज्य से पुराने मूल्यों को प्रस्तुत करना।

@jimfb

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

सामान्य async डेटा पुस्तकालयों के लिए, यह एक सामान्य और सुविधाजनक पैटर्न की तरह लगता है।

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

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

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

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

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

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

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

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

धन्यवाद!

मैं एक और सवाल भी जोड़ना चाहता हूं। मेरे पास कुछ ऐसा है।

var BlogPosts = React.createClass({
  getChildContext: function() {
    return {
      currentBlogPost: this.props.currentBlogPost,
      currentUser: this.props.currentUser
    };
  },

  childContextTypes: {
    currentBlogPost: React.PropTypes.object,
    currentUser: React.PropTypes.object
  },

  render: function() {
    return <BlogPosts blogPosts={this.props.blogPosts}/>
  }
});

function select(state) {
  const { blogPosts, currentUser, currentBlogId } = state;
  console.log( state.blogs[currentBlogId]); 
  // first time the above is undefined and then blogs get populated and I have the object;
  return { blogPosts, currentUser, currentBlogPost: state.blogs[currentBlogId] };
};

export default connect(select)(BlogPosts);

अब BlogPosts घटक में BlogPostText, BlogPostImage, PodCast ... यह निर्भर करता है कि क्या BlogPosts [index] .type पाठ, छवि या ऑडियो है।

एक घटक में मैंने मालिक के लिए इस तरह की जाँच की है,

var BlogPostText = React.createClass({
  canDeleteMemory: function(post, blog, user) {
    return user && (blog.userId == user.id || post.userId == user.id)
  },
  render: function() {
    let isOwner = this.canDeleteMemory(this.context.currentBlogPost, post, this.context.currentUser);
    return isOwner ? <a>Delete</a> : null;
  }
});

फिर मुझे हमेशा blog.userId पर एक त्रुटि मिलती है क्योंकि ब्लॉग अपरिभाषित है ... इसलिए मैं इस तरह की स्थिति को बदल देता हूं let isOwner = this.context.currentBlogPost && this.canDeleteMemory(this.context.currentBlogPost, post, this.context.currentUser);
लेकिन फिर डिलीट आइकन कभी नहीं दिखा ... लेकिन संदर्भ के उपयोग के बजाय अगर मैं BlogPostText घटक को Redux के साथ लपेटता हूं और इस का उपयोग करता हूं। Props.currentBlogPost तो यह ठीक काम करता है ..

संदर्भ में इतना परिवर्तन फिर से प्रस्तुत करना या ऐसा कुछ ट्रिगर नहीं करता ... या क्या मैं इसे गलत उपयोग कर रहा हूं।

@ aghosh47 मुझे लगता है कि एक संदर्भ परिवर्तन एक

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

@jimfb ठीक है, मैं अपने कोड को फिर से देखूंगा, अगर मुझे कुछ याद नहीं है और अगर मैं हल नहीं कर सकता तो एक नया सूत्र

@ जिम्फब जहां वंशज के बिना

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

@ jedwards1211 ईमानदार होने के लिए, मुझे याद नहीं है कि इसकी चर्चा कहाँ की गई थी। यह पूरी तरह से संभव है कि यह एक इन-पर्सन चर्चा थी, लेकिन ऑनलाइन कई पुनर्विचार चर्चाएं हैं और शायद आप इसे वहां पाएंगे।

Ping @aghosh47

hahaha

@jimfb अच्छी तरह से, इस मुद्दे को हल किया गया था ... कोड में कुछ त्रुटि थी और कोड लिखने वाले लोगों ने वादों से किसी भी त्रुटि को हल करने के लिए कैच का उपयोग नहीं किया था, इसलिए reducer राज्य ठीक से अपडेट नहीं हो रहा था और इसलिए परिवर्तन नहीं हुआ था 'परिलक्षित हो रहा है।

तो, अगर माता-पिता में परिवर्तन होता है, तो बच्चों में संदर्भप्रकार परिलक्षित होता है ... धन्यवाद।

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

@Kuburtin यह वास्तव में सर्वर-साइड पर काम नहीं करता है जहाँ सभी निर्मित घटक समान वैश्विक स्थिति साझा करते हैं। प्रसंग वैश्विक एक ही पेड़ में प्रस्तुत घटकों के सभी wrt है, लेकिन स्थानीय पेड़ के लिए ही। यह वैश्विक राज्य के विपरीत, अन्य पेड़ों के लिए लीक नहीं करता है।

एक साइड नोट पर, इस सवाल का इस मुद्दे से कोई लेना-देना नहीं है, क्या यह है? :आँख मारना:

@fatfisz मैं आपके उपयोग के मामलों को अच्छी तरह से नहीं जानता, आपके पास एक आवश्यकता ('फू') भी हो सकती है जो केवल क्लाइंट पर एक विंडो प्रॉपर्टी की ओर

मेरे ऐप में btw, मैंने सभी घटकों के प्रॉप्स में एक ऑब्जेक्ट को पास करना समाप्त कर दिया, क्योंकि संदर्भ अस्पष्ट लगता है, और चूंकि लगभग सभी घटक मेरे मामले में इसका उपयोग करते हैं

धन्यवाद

क्या गलत है:

// context.js
module.exports  = { // sorry for using commonjs, since most of you use import/export I guess
  // some shared variables, initialized and used by components
};

तब आवश्यकता होती है ('./ reference.js'); सभी फ़ाइलों में संदर्भ चर और विधियों का उपयोग करने की आवश्यकता है

एन्कैप्सुलेशन शायद सम्मानित नहीं है, लेकिन अच्छी तरह से ।।

(@Gaeron)

@ क्यूबर्टिन प्रसंग उपयोगी है क्योंकि:

1) यह मॉड्यूल निर्यात के विपरीत री-रेंडरिंग को बदल और ट्रिगर कर सकता है
2) यह माता-पिता द्वारा अतिदेय हो सकता है, जो इसकी सबसे उपयोगी विशेषता है
3) यह एक सिंगलटन होने की जरूरत नहीं है, जो सर्वर रेंडरिंग के लिए उपयोगी है जहां आप डेटा को अलग करना चाहते हैं

2 के लिए सहमत) और 3)
1) के लिए मुझे अभी तक ऐसा करने की आवश्यकता नहीं है, लेकिन आप संदर्भ में एक प्रतिक्रिया उदाहरण भी पारित कर सकते हैं (मैंने अक्सर सुना है कि यह बुरा अभ्यास है, आप शायद यह भी सोचते हैं, लेकिन यह डॉक्स में भी उल्लिखित है: याद करें आप चाहे तो प्रॉप्स में पूरे रिएक्ट कंपोनेंट को पास कर सकते हैं (

इसे अच्छी तरह से लिखते हुए, मुझे एहसास हुआ कि सिंगलटन संदर्भ विचार बुरा है :)

भ्रामक बात यह है कि प्रतिक्रिया डॉक्स संदर्भ का उपयोग करने के लिए ज्यादा आमंत्रित नहीं करते हैं, वे वास्तव में वैकल्पिक सहारा की तरह हैं, जहां आप उनसे पूछने पर उन्हें प्राप्त करते हैं?

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

'use strict';

    var React = require('react-native');
    var { View,
          StyleSheet,
          TouchableHighlight,
          } = React;

    var DrawerLayout = require('react-native-drawer-layout');
    var DrawerScreen = require('./DrawerScreen');
    var DrawerMenu = require('./DrawerMenu');

    var DrawerLayoutExample = React.createClass({

      render: function() {
        var navigationView = (
          <View >
               <DrawerMenu/>
          </View>
        );

        return (
          <DrawerLayout
            onDrawerSlide={(e) => this.setState({drawerSlideOutput: JSON.stringify(e.nativeEvent)})}
            onDrawerStateChanged={(e) => this.setState({drawerStateChangedOutput: JSON.stringify(e)})}
            drawerWidth={200}
            ref={(drawer) => { return this.drawer = drawer  }}
            keyboardDismissMode="on-drag"
            renderNavigationView={() => navigationView}>
            <View style={styles.container}>
 // Here is content component for drawer, need to refer drawer reference
            <DrawerScreen ></DrawerScreen>
            </View>
          </DrawerLayout>
        );
      }
    });

    var styles = StyleSheet.create({
      container: {
        alignItems: 'center',
        justifyContent: 'center',
        flex: 1,
        flexDirection: 'column',
      },
     });

    module.exports = DrawerLayoutExample;

DrawerScreen.js

'use strict';
var React = require('react-native');
var {
  AppRegistry,
  StyleSheet,
  Text,
  View,
  Dimensions,
  Image,
  TouchableHighlight,
  TextInput,
} = React;

var deviceWidth = Dimensions.get('window').width;

var DrawerScreen = React.createClass({


  render: function() {
    return (

        <View style={styles.container}>

          <Text style={styles.welcome}>Content!</Text>

          <TouchableHighlight onPress={() => this.state.openDrawer()}>
            <Text>Open drawer</Text>
          </TouchableHighlight>
          <TextInput style={styles.inputField} />
        </View>
    );
  },

});

var styles = StyleSheet.create({
   container: {
      alignItems: 'center',
      justifyContent: 'center',
      flex: 1,
          flexDirection: 'column',
    },
    inputField: {
      backgroundColor: '#F2F2F2',
      height: 40,
    },
});

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

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

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

@ यह एक ऐसी चीज़ है जिसे सिर्फ कंपोनेंटडिमाउंट पर ही किया जाना चाहिए?

@Kuburtin बिल्कुल भी नहीं, किसी भी बिंदु पर उपयोगकर्ता एक अलग भाषा चुन सकता है, और किसी भी बिंदु पर उपयोगकर्ता ब्राउज़र का आकार बदल सकता है ...

आकार बदलने के लिए, आप ComponentsDidMount में सुन सकते हैं, भाषाओं के लिए मैं सब कुछ फिर से प्रस्तुत करूंगा

मैं पसंद करता हूं कि सभी आकार बदलने वाले तर्क को न दोहराएं जब मेरे पास कुछ अच्छा हो
redux actioncreator जो पूरे एपो के लिए सुनता है और सर्वर साइड काम करता है
भी ...
मेरे पास सर्वर पर State.responsive.isPhone / isPrerender / screenwidth आदि हैं।
मैं उपयोगकर्ता एजेंट के आधार पर प्रेषण करता हूं। साफ।

शुक्र पर, 29 अप्रैल, 2016, 4:52 बजे सिरिल ऑबर्टिन सूचनाएं @github.com
लिखा था:

आकार बदलने के लिए, आप मेरे लिए भाषाओं के लिए घटकडाइमाउंट में सुन सकते हैं
सब कुछ फिर से प्रस्तुत करना

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/facebook/react/issues/2517#issuecomment -215742327

Wout।
(मोबाइल पर टाइप किया हुआ, बहाना)

लेकिन हाँ, पेड़ के शीर्ष पर एक साधारण कुंजी = {लैंग} के लिए पर्याप्त होना चाहिए
भाषाओं। एनिमेशन के साथ साइटों के लिए इतना अच्छा नहीं है।

शुक्र पर, अप्रैल 29, 2016, 6:07 अपराह्न Wout Mertens wout। [email protected] ने लिखा है:

मैं पसंद करता हूं कि सभी आकार बदलने वाले तर्क को न दोहराएं जब मेरे पास कुछ अच्छा हो
redux actioncreator जो पूरे एपो के लिए सुनता है और सर्वर साइड काम करता है
भी ...
मेरे पास State.responsive.isPhone / isPrerender / screenwidth आदि ऑन हैं
सर्वर, मैं उपयोगकर्ता एजेंट पर आधारित प्रेषण। साफ।

शुक्र पर, 29 अप्रैल, 2016, 4:52 बजे सिरिल ऑबर्टिन सूचनाएं @github.com
लिखा था:

आकार बदलने के लिए, आप मेरे लिए भाषाओं के लिए घटकडाइमाउंट में सुन सकते हैं
सब कुछ फिर से प्रस्तुत करना

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/facebook/react/issues/2517#issuecomment -215742327

Wout।
(मोबाइल पर टाइप किया हुआ, बहाना)

Wout।
(मोबाइल पर टाइप किया हुआ, बहाना)

मैं आप की तरह था, लेकिन घटना श्रोताओं का आकार वास्तव में सस्ता है, मुझे नहीं लगता कि एक ही प्रकार के कई श्रोताओं का होना बुरा है

नोनो, मुझे संदेह नहीं है कि वे सस्ते हैं, यह सिर्फ इतना है कि यह बहुत आसान है
आकार बदलने वालों को प्रबंधित करने की तुलना में this.context.isPhone लिखना।

शुक्र पर, 29 अप्रैल, 2016 को शाम 6:38 बजे सिरिल ऑबर्टिन सूचनाएं @github.com
लिखा था:

मैं आप जैसा था, लेकिन घटना श्रोताओं का आकार वास्तव में सस्ता है, मैं नहीं
लगता है कि एक ही तरह के कई श्रोताओं का होना बुरा है

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/facebook/react/issues/2517#issuecomment -215797819

Wout।
(मोबाइल पर टाइप किया हुआ, बहाना)

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

Redux के साथ काम करने के लिए, https://github.com/reactjs/react-router/issues/470 और PRs में निरंतर चर्चा देखें।

कुछ बिंदुओं पर हम वास्तव में https://github.com/reactjs/react-router/issues/3484 को हल करने के लिए अन्य पुस्तकालयों के लिए इस आसान का उपयोग करने के लिए, लेकिन यह मूल रूप से हमने सोचा था कि यह कठिन है।

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

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

दो दृष्टिकोणों के बीच यह कम से कम _somewhat_ जेनेरिक है ... हालांकि सबसे अच्छा हम अभी के लिए कर सकते हैं मुझे लगता है कि at

हाँ संकेत दिया: पी, सिर्फ यह है कि इसकी अभी भी उप-अपनाने और सामान्य रूप से काम करने के तरीके को ठीक करने के लिए एक अच्छा प्रतिस्थापन नहीं है

@jquense बीच में घटक नहीं contextTypes घोषणा करता है, और उस संदर्भ की एक संशोधित प्रति प्रदान करने के लिए childContextTypes getChildContext() इसके वंशज

@DarylCantrell घटकों को उनके द्वारा अनुरोध किए जाने वाले प्रत्येक संदर्भ में ऑप्ट-इन करने की आवश्यकता होती है। पूरे संदर्भ थोक को एक घटक में पारित करने के लिए contextTypes घोषित करने का कोई तरीका नहीं है।

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

@ 1000 हर्ट्ज ज़रूर, लेकिन वह "संदर्भ के कुछ हिस्सों को समायोजित करने के बारे में बात कर रहा था जैसा कि यह गुजरता है"। उस परिदृश्य में आपको "संपूर्ण" संदर्भ प्राप्त करने की आवश्यकता नहीं है, जिस हिस्से को आप ओवरराइड करने की योजना बना रहे हैं।

@DarylCantrell वूप्स, मैंने आपके इरादे को गलत बताया।

मैंने इस मुद्दे के लिए एक पुल अनुरोध प्रस्तुत किया है: # 7213

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

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

चूँकि ऐसे घटक जो संदर्भ में रुचि नहीं रखते हैं, आमतौर पर संदर्भ तर्क का उपयोग नहीं करते हैं, संदर्भ को मास्किंग नहीं करने से कोई मौजूदा घटक टूटने का कारण नहीं होगा, जब तक कि स्पष्ट रूप से घटक यह नहीं जाँच रहे हैं कि संदर्भ परम अपरिभाषित है। हालांकि, यह एक शुद्ध शुद्ध घटक के लिए एक अवसर पैदा करेगा, एक ContextAwarePureComponent को कहना चाहिए जो कि राज्य की तुलना करेगा, props और संदर्भ shouldComponentUpdate में, संदर्भ को शुद्ध घटकों के पुन: रेंडर करने का कारण बनता है।

मैं वर्तमान में इस पैच के साथ विकास में दौड़ रहा हूं, रेडियम और कुछ प्रतिक्रिया-बूटस्ट्रैप घटकों का उपयोग कर रहा हूं, और किसी भी मुद्दे का अनुभव नहीं किया

नमस्कार @bvella , मुझे लगता है कि आपका यह अनुरोध है: # 7213, 7212 नहीं।

@DarylCantrell आप सही हैं, धन्यवाद

मुझे लगता है कि https://github.com/facebook/react/pull/7213 / https://github.com/facebook/react/pull/7225 , एक अच्छा है और इसे अनुकूलित किया जाना चाहिए

मेरी समझ यह है कि संदर्भ वैश्विक चर की तरह है और इसलिए इसका उपयोग करने से रोकना चाहिए;
हालाँकि, इसका मतलब यह नहीं है कि उपयोगकर्ता को वैश्विक चरों पर पहुंचने से पहले घोषणा करनी होगी;
वैश्विक चर हमेशा सुलभ होना चाहिए, भले ही आप घोषणा करें या नहीं;

संदर्भप्रकार की घोषणा केवल प्रोपराइट्स की तरह ही सत्यापन के उद्देश्य से काम करना चाहिए

फिर से, कृपया इसके बारे में सोचें क्योंकि यह हमारे लिए बहुत परेशानी का कारण है
(मैं प्रतिक्रिया रिले का उपयोग कर रहा हूं और यह सभी संदर्भ वस्तुओं को छिपाता है)

मैंने https://github.com/facebook/react/pull/7225#issuecomment -276618328 पर टिप्पणी करते हुए कहा कि इस संदर्भ में बस सब कुछ अपडेट करना चाहिए, और sCU केवल यह तय करने के लिए कार्य करता है कि क्या घटक को फिर से प्रस्तुत करने की आवश्यकता है? ; इसकी परवाह किए बिना बच्चों का सत्यापन किया जाएगा।

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

शुद्ध घटक

https://60devs.com/pure-component-in-react.html

https://hackernoon.com/react-purecomponent-considered-harmful-8155b5c1d4bc

क्या अभी इसका कोई समाधान है?

जैसा कि हम इस सूत्र से जानते हैं कि मौजूदा समाधान बहुत मौलिक रूप से टूट गया है।
हम सभी ऐप्स को धीमा किए बिना वर्तमान API को ठीक नहीं कर सकते हैं (जिसे हम :-) से बचना चाहते हैं।

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

चर्चा देखें: https://github.com/reactjs/rfcs/pull/2

@acdlite ने नए संदर्भ API: https://github.com/facebook/react/pull/11818 के साथ एक पीआर उतारा

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

नया एपीआई अगले मामूली प्रतिक्रिया 16.x रिलीज में से एक में उपलब्ध और प्रलेखित होगा।

@gaearon यकीन नहीं होता कि आप इसे अक्सर सुनते हैं, लेकिन: आप लोग बहुत अच्छा काम कर रहे हैं और मैं आपके काम की सराहना करता हूं। 🍺