React: कंपोनेंटडिडरिसीवप्रॉप्स कृपया

क्यों नहीं setup(props) ?

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

setup(props) {
  props = props || this.props
  UserActions.load(props.id)
}

@syranide मुसीबत तब होती है जब सेटअप को उन तरीकों को कॉल करने की आवश्यकता होती है जिन्हें प्रॉप्स की भी आवश्यकता होती है, जिन्हें कॉल करने के तरीकों की भी आवश्यकता होती है ...

+1 वर्तमान पैटर्न के साथ ऐप में अनावश्यक तारों का एक गुच्छा जैसा लगता है। समस्या को हल करने का एक संक्षिप्त मानकीकृत तरीका हो सकता है। ComponentWillReceiveProps के अंदर this.props पर लोगों के एक झुंड को जलते देखा गया, यह एक स्पष्ट संकेत है कि यह सहज नहीं है।

+1, मुझे यह निराशाजनक भी लगता है।

अब यह कोई मुद्दा नहीं लगता।

+1, मैं खुद को प्रॉप्स के आसपास से गुजरते हुए भी पा रहा हूं। ऊपर @insin के समान मैं थोड़ी देर के लिए डिफ़ॉल्ट

setup(props = this.props) {
  doSomething(props);
}

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

+1

मुझे लगता है कि इसके उपलब्ध नहीं होने का कारण यह है कि this.props और this.state _always_ प्रदान किए गए मानों के अनुरूप हैं। componentDidReceiveProps को लागू करने का कोई तरीका नहीं है जो इस बाधा को तोड़े बिना किसी अन्य रेंडर को ट्रिगर नहीं करता है।

अधिकांश बार, यदि आप componentWillReceiveProps का उपयोग कर रहे हैं, तो आप वास्तव में या तो एक उच्च ऑर्डर घटक ला रिले चाहते हैं , या observe हुक जैसा कुछ

+1
साथ ही, आप componentDidReceiveProps को this.props या this.state बदले बिना लागू कर सकते हैं। यदि आपको केवल इनसे पढ़ने की आवश्यकता है, तो आप दूसरे रेंडर को ट्रिगर नहीं करेंगे। यदि आप इस प्रस्तावित फ़ंक्शन कॉल के भीतर प्रॉप्स या स्टेट को लिख रहे हैं, तो आप अपने आप को पैर में गोली मार रहे हैं, लेकिन जीवनचक्र में हर दूसरी विधि के लिए यही स्थिति है।

+1

जब shouldComponentUpdate false लौटाता है, तो मैं नए प्रॉप्स इवेंट का जवाब देने में सक्षम होना चाहता हूं, इसलिए मेरे मामले में मैं componentDidUpdate उपयोग नहीं कर सकता।

+1

+1

componentWillMount और componentWillUpdate @iammerrick . के बारे में क्या

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

componentWillReceiveProps उपयोग करें?

+1

+1 यह DRY कोड और तर्क को सरल बनाने में मदद करता है।

मैं इस थ्रेड को केवल एक फ़ंक्शन शुरू करने का उदाहरण बनाने के लिए प्रारंभिक सेटअप पर कंपोनेंटडिडरिसिवप्रॉप्स के लिए खुला रहूंगा:

componentDidReceiveProps() {
  UserActions.load(this.props.id);
}

विचार?

componentWillReceiveProps() {
  setTimeout(()=> {
    if(this.isMounted()) {
      this.componentDidReceiveProps();
    }
  });
}
componentDidReceiveProps() {
  UserActions.load(this.props.id);
}

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

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

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

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

+1 कृपया। बहुत बदसूरत।

नाह मैं अच्छा हूँ। बेहतर उपाय हैं।

+1

componentDidReceiveProps() पहले से मौजूद है: इसे render() कहा जाता है। हालांकि एक मामला हो सकता है (जैसे @iammerrick के उदाहरण में) जहां आपको रेंडर करने से पहले कुछ लोड/ट्रिगर/आदि की आवश्यकता होती है। इसका मतलब केवल एक ही चीज है: आप कुछ गलत करते हैं।

जब आप जैसी चीजें करते हैं

setup(id) {
    UserActions.load(id);
}

आप या तो घटक में या बाहर (बहुत खराब) स्टेटफुलनेस का परिचय देते हैं। हर बार जब कोई घटक प्रॉप्स प्राप्त करता है तो आपको load() डेटा की आवश्यकता क्यों होती है (वे नए होने की गारंटी भी नहीं देते हैं)? यदि आप आलसी-लोडिंग करते हैं, तो render() विधि में डेटा का अनुरोध करने का उचित तरीका है:

render() {
    var actions = UserActions.load(id);
    if (actions) // render
    else // show spinner or return null, etc.
}

UserActions.load = function(id) {
    if (data) return data;
    else // request the data, emit change on success
}

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

तो मुझे बताओ, @ मुझे-आंद्रे, हमारे पास componentWillUpdate और componentWillReceiveProps दोनों क्यों हैं?

मेरी राय में, ऐसा इसलिए है क्योंकि वे विभिन्न उद्देश्यों की पूर्ति करते हैं और दोनों सहायक हैं। जैसे वे दोनों समान नहीं हैं, render काल्पनिक componentDidReceiveProps क्योंकि इसे नए प्रॉप्स के अलावा अन्य कारणों से कहा जाता है; साथ ही, आपको पिछले प्रॉप्स तक पहुंच नहीं दी जाती है।

पिछले प्रॉप्स का लाभ यह है कि आपको हर बार डेटा लोड नहीं करना पड़ेगा; यह सहारा के आधार पर सशर्त हो सकता है और क्या वे बदल गए हैं।

जाहिर है, "[कुरूपता] देखने वाले की नज़र में है", क्योंकि एक उचित जीवनचक्र पद्धति को जोड़ना मेरे लिए एक अधिक स्वच्छ समाधान जैसा लगता है।

शायद इसे देखने का एक और तरीका है ...

मान लें कि यहां मुख्य लक्ष्य हैं:

(१) मानवीय त्रुटि को कम करें - मैं मापदंडों को पारित करना भूल गया या फिर से props = props || this.props उपयोग करना भूल गया
(2) गैर-मूल्य जोड़ने वाले बॉयलरप्लेट कोड को कम करने के लिए - अनावश्यक रूप से कुछ क्यों लिखें
(३) यह तय करने के संज्ञानात्मक बोझ को कम करने के लिए कि कौन सी जीवनचक्र विधियों का उपयोग करना है - मुझे इस तरह के बारे में सोचने की आवश्यकता क्यों है, मैं उस दिन कैसा महसूस करता हूं, इसके आधार पर मैं थोड़ा अलग दृष्टिकोण का उपयोग क्यों करता हूं, आदि

तो शायद समाधान स्थान इन लक्ष्यों को प्राप्त करने के लिए रिएक्ट और रिएक्ट एपीआई के उपयोग दोनों को सरल बनाने के आसपास है।

यदि आप इन लक्ष्यों के साथ समस्या के बारे में सोचते हैं, तो शायद कुछ जीवनचक्र विधियों को मिला दिया जा सकता है और यदि आप यह जानने में रुचि रखते हैं कि यह आरंभीकरण बनाम अद्यतन है, तो आप कॉलिंग हस्ताक्षर/तर्कों द्वारा बता सकते हैं। उदाहरण के लिए: beforeRender(prevProps, prevState) या update(prevProps, prevState) ।

व्यक्तिगत रूप से, ऐसा लगता है कि बहुत अधिक जीवनचक्र विधियां हैं और यदि उन्हें लगातार (बिना या प्रारंभिक पास और अद्यतन पर prevProps / prevState के साथ) कहा जाता है, तो यह मेरे कोड को सरल बना सकता है और मेरी उत्पादकता बढ़ा सकता है। साथ ही, जीवनचक्र पद्धति के नाम बहुत लंबे होते हैं (मैं उन्हें टाइप करने के बजाय उन्हें कॉपी/पेस्ट नहीं करता) और यह याद रखना मुश्किल है कि कौन सा/क्या मौजूद है जो मुझे लगता है कि उन्हें सरल/सरल किया जा सकता है।

@robyoder , संक्षिप्त उत्तर क्यों हमारे पास componentWillUpdate और componentDidReceiveProps दोनों हैं, उनके बीच एक बड़ा अंतर है। वे निश्चित रूप से समान हैं, लेकिन मुख्य रूप से componentWill साथ उपसर्ग किए जा रहे हैं।

| | राज्य बदल गया है | घटक अद्यतन नहीं हुआ |
| --- | --- | --- |
| कंपोनेंटविलअपडेट () | हाँ | नहीं |
| कंपोनेंटविल रिसीवप्रॉप्स () | नहीं | हाँ |

जैसा कि आपने देखा होगा कि जीवन चक्र बिंदु/स्थितियां हैं जहां एक विधि को कॉल किया जाता है और दूसरा नहीं। इसलिए हमारे पास 2 अलग जीवनचक्र विधियां हैं।

हालांकि componentDidReceiveProps() जैसा कि इस विषय में वर्णित किया गया था, किसी भी घटक स्थिति या स्थिति का प्रतिनिधित्व नहीं करता है और यह किसी भी चीज़ तक पहुंच नहीं देता है componentWillReceiveProps() नहीं। यह सिर्फ एक मामूली वाक्य रचनात्मक चीनी जोड़ता है जो उपयोगी या आसान लग सकता है या नहीं - यह एक व्यक्तिगत वरीयता है, तकनीकी आवश्यकता नहीं है । और यही कारण है कि इसे क्यों नहीं जोड़ा जाना चाहिए: यह व्यक्तिपरक है। आप कहते हैं कि तर्क-वितर्क करना कुरूप है - लेकिन आपने यह भी कहा कि "[कुरूपता] देखने वाले की नज़र में है"। मेरे लिए ऐसा लगता है कि आपने स्वयं उत्तर दिया है।

@ मुझे-आंद्रे आप एक ही समय में मुझे (@kmalakoff) और @robyoder का जवाब दे रहे होंगे। या शायद नहीं, लेकिन मैं इस अवसर पर चर्चा को आगे बढ़ाऊंगा...

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

आइए जानते हैं अभ्यास के बारे में....

आइए मान लें कि इस विषय का अनुसरण किया जा रहा है और +1-ed क्योंकि इसमें कुछ महत्वपूर्ण है और मान लें कि componentDidReceiveProps को जोड़ना एक अच्छा विचार नहीं है क्योंकि यह API सतह क्षेत्र को बढ़ाता है।

तालिका और 3 लक्ष्यों को ध्यान में रखते हुए, क्या किसी के पास एपीआई को सरल बनाने के लिए कोई विचार है और / या इस धागे में लोगों को वे क्या चाहते हैं और एपीआई का विस्तार नहीं करने का कोई अन्य तरीका है (शायद इसे कम करना/सरल बनाना भी) )?

@kmalakoff , आप जिन 3 बिंदुओं के बारे में बात करते हैं, वे केवल एपीआई से जुड़े होते हैं, जब आप उनका सामना करते हैं तो आप एपीआई का उपयोग करते हैं। वे खराब डिजाइन के कारण नहीं हैं।

आप जिस पहली समस्या के बारे में बात कर रहे हैं, वह यह है कि जीवनचक्र के तरीके अलग-अलग तर्क देते हैं। खैर, यह पूरी तरह से स्वाभाविक है - वे विभिन्न उद्देश्यों की पूर्ति करते हैं। componentWillReceiveProps सहारा लेता है इसलिए नहीं कि जब इस विधि को जोड़ा गया था तब चंद्रमा भरा हुआ था - बल्कि इसलिए कि यह उन प्रॉप्स को प्राप्त करने के बारे में है जो अभी तक घटक को नहीं सौंपा गया है। props केवल उन तरीकों से पारित किए जा रहे हैं जहां वे (हो सकता है) this.props से भिन्न हों। यह वास्तव में एक संकेत है, कोई मुद्दा नहीं।
समस्या # 3 यह है कि आपके लिए यह तय करना कठिन है कि किस कॉलबैक/दृष्टिकोण का उपयोग करना है। खैर, यह वास्तव में कोई समस्या नहीं है state और this.state , props और this.props हो जाते हैं, जो अधिकांश तरीकों से समान (अर्थहीन पढ़ें) हैं, तो आप अतिरिक्त विकल्पों में उलझ जाते हैं और विकल्प।
समस्या # 2 बॉयलरप्लेट कोड के बारे में है ... ठीक है, रिएक्ट एक पतली लाइब्रेरी है - और इसके कारण यह सुंदर, आसान और सख्त है। यदि आप एक ऐसा आवरण बनाना चाहते हैं जो हमारे जीवन को सरल बना दे और हमारे द्वारा प्रतिदिन लिखे जाने वाले कोड की मात्रा को कम कर दे - ऐसा क्यों नहीं करते? इसे अपने स्वयं के npm रूप में प्रकाशित करें जो react पर निर्भर करता है और आपका काम हो गया।

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

और एक और बात...
एक अच्छी तरह से डिज़ाइन किए गए रिएक्ट एप्लिकेशन में, आपको उन अधिकांश विधियों की आवश्यकता नहीं होती है जिनके बारे में हम बात करते हैं या आप उनका उपयोग बहुत ही कम करते हैं। getInitialState , componentWillMount , componentWillUnmount 99% समय पर्याप्त है। मेरे वर्तमान प्रोजेक्ट में जो एक अपेक्षाकृत बड़ा व्यावसायिक ऐप है, componentWillReceiveProps पूरे ऐप में दो बार उपयोग किया जाता है। मैं इसका बिल्कुल भी उपयोग नहीं करूंगा, लेकिन पर्यावरण (ब्राउज़र पढ़ें) अपूर्ण है - कुछ "स्टेटफुल-इन-ही" चीजों में हेरफेर करना जैसे कि scrollTop या भविष्य के लिए लेआउट कंप्यूटेशंस पर भरोसा करना render s props संक्रमणों और DOM परिवर्तनों के बीच मैन्युअल रूप से सिंक्रनाइज़ करने की आवश्यकता है। हालांकि अधिकांश "सामान्य" मामलों में, आपको केवल यह जानने की आवश्यकता नहीं है कि props संक्रमण कब होता है।

@ मुझे-आंद्रे रिएक्ट के साथ काम करने के अपने अनुभव के आधार पर, मेरा मानना ​​​​है कि एपीआई में सुधार/सरल बनाने के लिए जगह है। मैं अकेला नहीं हूं इसलिए इस मुद्दे को सबसे पहले उठाया गया और इसे +1-ed किया जा रहा है।

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

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

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

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

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

क्या कोई एपीआई बदलने का मामला बना सकता है? उदाहरण के लिए विभिन्न विकल्पों का तुलनात्मक विश्लेषण प्रदान करना (घटक जोड़ेंDidReceiveProps बनाम मर्ज / एपीआई को सरल बनाएं बनाम कोई परिवर्तन नहीं)

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

हमारे लिए सबसे उपयोगी क्या होगा (या कम से कम मेरे लिए) यह समझना है कि लोग इस जीवन चक्र पद्धति को क्यों चाहते हैं। आप इस जीवनचक्र में क्या करने की कोशिश कर रहे हैं जो अन्य जीवनचक्र विधियों द्वारा पर्याप्त रूप से कवर नहीं किया गया है? https://github.com/facebook/react/issues/3279#issuecomment -163875454 में सुझाए गए रेंडर के बजाय कोई UserActions.load(id); componentDidReceiveProps के भीतर क्यों करना चाहेगा (मैं इसके बारे में सोच सकता हूं एक कारण, लेकिन मैं उत्सुक हूं कि आपके कारण क्या हैं)? क्या प्रॉप्स के आधार पर डेटा-लोड शुरू करने के अलावा कोई उपयोग के मामले हैं?

@jimfb मेरा मानना ​​​​है कि componentDidReceiveProps वही है जो मुझे चाहिए और अन्य विधियां अनुचित हैं, लेकिन मैं गलत हो सकता हूं। मैं खुशी-खुशी अपने उपयोग के मामले की व्याख्या करूँगा।

मेरे पास मेरे react-router में एक मार्ग है जो इस तरह दिखता है:

    <Route path="/profile/:username" component={ProfilePage} />

मुझे बाहरी स्रोत से प्रोफ़ाइल के लिए डेटा लाने की आवश्यकता है, और इसे ठीक से करने के लिए, मुझे componentDidMount विधि में एक HTTP अनुरोध करने की आवश्यकता है।

दुर्भाग्य से, जब मैं एक प्रोफ़ाइल से दूसरे प्रोफ़ाइल पर नेविगेट करता हूं, तो रिएक्ट राउटर कंस्ट्रक्टर विधि या componentDidMount विधि को फिर से कॉल नहीं करता है (बेशक यह एक बग हो सकता है लेकिन मुझे लगता है कि यह अभी के लिए नहीं है) .

मैंने सैद्धांतिक componentDidReceiveProps का उपयोग करके इसे ठीक करने का विचार किया। दुर्भाग्य से यह अभी तक अस्तित्व में नहीं है, और componentWillReceiveProps मेरी आवश्यकताओं की पूर्ति नहीं करेगा।

इस पर किसी भी संकेत की बहुत सराहना की जाएगी।

मेरा झुकाव यह है कि componentDidReceiveProps वही है जो मुझे चाहिए।

@ shea256 क्या आप विस्तार से componentWillReceiveProps आपकी आवश्यकताओं की पूर्ति क्यों नहीं करता है?

@ shea256 इसके अलावा, आपके घटक को HTTP अनुरोध करने की आवश्यकता क्यों है? उस http अनुरोध में क्या है? यदि डेटा है, तो डेटा कॉलबैक वापस आने पर आप अपने घटक को एसिंक्रोनस रूप से अपडेट क्यों नहीं कर रहे हैं?

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

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

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

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

@jimfb मुझे routeParam में नया उपयोगकर्ता नाम प्राप्त करने की आवश्यकता है और componentWillReceiveProps मेरे पास अभी तक यह नहीं है।

बाहरी स्रोत से प्रोफ़ाइल डेटा लोड करने के लिए मुझे एक HTTP अनुरोध करने की आवश्यकता है (डेटा स्थानीय रूप से संग्रहीत नहीं है)।

और मैं अपने घटक को रेंडर विधि में अपडेट कर सकता हूं लेकिन यह थोड़ा गंदा लगता है:

constructor(props) {
  super(props)

  this.state = {
    id: this.props.routeParams.id,
    profile: {}
  }
}

componentDidMount() {
  this.getProfile(this.state.id)
}

render() {
  if (this.props.routeParams.id !== this.state.id) {
    this.getProfile(this.props.routeParams.id)
  }

  return (
    <div>
      <div className="name">
       {this.state.profile.name}
      </div>
    </div>
  )
}

@ ग्रासिक ने लिखा:

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

हाँ, यह बिल्कुल मेरा उपयोग-मामला है।

नए प्रॉप्स को माउंट करना और प्राप्त करना दोनों को इसी लोडिंग चक्र को ट्रिगर करना चाहिए, इसलिए कंपोनेंटडिडमाउंट और कंपोनेंटविल रिसीवप्रॉप्स अपडेट फ़ंक्शन को कॉल करने का स्थान है।

ख़ूब कहा है।

@ shea256 क्या इसके बजाय componentWillReceiveProps का उपयोग करके ऐसा नहीं किया जा सकता है?

constructor(props) {
  super(props)

  this.state = {
    id: this.props.routeParams.id,
    profile: {}
  }
}

componentDidMount() {
  this.getProfile(this.state.id)
}

componentWillReceiveProps(nextProps) {
  let { id } = nextProps.params
  if(id !== this.state.id) {
    this.getProfile(id, (profile) => {
      this.setState({ id: id, profile: profile })
    })
  }
}

render() {
  return (
    <div>
      <div className="name">
       {this.state.profile.name}
      </div>
    </div>
  )
}

@ ग्रासिक ने लिखा:

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

@ ग्रासिक ने लिखा:

रेंडर में इस बारे में जानकारी नहीं है कि यह एक नया प्रोप है, और वैसे भी, रेंडर से सेटस्टेट एक नहीं-नहीं है।

बस यहां स्पिटबॉल करना: यदि componentDidUpdate प्रारंभिक रेंडर (बाद के रेंडर के अलावा) पर लागू हो गया, तो क्या यह आपके उपयोग के मामले को हल करेगा? आप जाँच सकते हैं कि क्या प्रॉप्स बदल गए हैं और क्या आपका सारा डेटा componentDidUpdate में लोड हो रहा है, है ना? और रेंडर में, आपको पता चल जाएगा कि आप डेटा लोड कर रहे थे यदि this.state.profileName != this.props.profileName । क्या वह विकल्प आपके उपयोग के मामलों के लिए पर्याप्त होगा?

क्या ऐसे कोई उपयोग के मामले हैं जिनमें लोगों के पास प्रॉप्स के आधार पर डेटा लोड करने वाले घटक शामिल नहीं हैं?

@calmdev एचएम, मुझे विश्वास है कि आप सही हैं। मैं इसे आजमाउंगा।

@jimfb शायद, हालांकि मैंने componentDidUpdate का उपयोग करने का प्रयास किया और मैंने सोचा कि यह काम नहीं करता है। मैं एक और नज़र डाल सकता हूँ।

और ऐसा लगता है कि मैं पूरी तरह से this.state.profileName != this.props.profileName पर एक चेक कर सकता था लेकिन यह भी एक हैक की तरह लगता है, है ना? इस बिंदु पर, यदि componentWillReceiveProps(nextProps) काम करना समाप्त कर देता है, तो मैं बस यही पसंद करूंगा। अब, componentDidMount साथ समरूपता की कमी मुझे परेशान करती है। क्या मैं componentWillMount के बदले componentDidMount उपयोग कर सकता हूं?

मुझे बस ऐसा लगता है कि पूरा जीवनचक्र साफ हो सकता है।

@ shea256 , मेरे पास आपके लिए एक प्रश्न है ... क्या आपने प्रतिक्रिया के लिए README पढ़ा है?
मैं यह कहने में सहज महसूस नहीं करता, लेकिन यदि नहीं, तो संभवतः आपको उस टूल के लिए नई सुविधाओं का अनुरोध नहीं करना चाहिए जिससे आप परिचित नहीं हैं। मेरे लिए यह भी लगता है... बेतुका।
"क्या मैं componentWillMount के बदले componentDidMount उपयोग कर सकता हूं?"
नहीं, आप ऐसा नहीं कर सकते क्योंकि जैसा कि रीडमी में बताया गया है, componentWillMount को आपके घटक को डीओएम और componentDidMount - उसके बाद कहा जाता है। ठीक है, आप निश्चित रूप से एक विधि को दूसरे के साथ बदल सकते हैं और इससे आपका कोड टूट जाएगा। हमारे यहां 2 तरीके हैं इसका कारण सौंदर्यशास्त्र नहीं है ("समरूपता" पढ़ें)। ऐसा इसलिए है क्योंकि हमें प्रस्तुत करने से पहले तैयारी करने के लिए एक विधि की आवश्यकता हो सकती है और दूसरी पहली रेंडर के बाद कुछ प्रारंभिक डीओएम पूछताछ/हेरफेर के लिए। लेकिन यह भी एक औसत प्रतिक्रिया घटक के लिए आकर्षक है। आम तौर पर, आपको केवल डीओएम को मैन्युअल रूप से एक्सेस करने की आवश्यकता नहीं होती है।
"और ऐसा लगता है कि मैं पूरी तरह से this.state.profileName != this.props.profileName पर जांच कर सकता हूं लेकिन यह भी एक हैक की तरह लगता है, है ना?"
हां, आपका पूरा दृष्टिकोण एक हैक है। और आपको किसने बताया कि componentDidReceiveProps गारंटी देगा कि props बदल दिया गया है? जब तक आप shouldComponentUpdate को परिभाषित नहीं करते तब तक कुछ भी ऐसा नहीं करेगा।
यह ठीक उसी तरह है जैसे रिएक्ट काम करता है।

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

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

प्रोफ़ाइल डेटा लोड करने में आपकी समस्या के संबंध में। आप एक कार्यात्मक-उन्मुख ढांचे के लिए क्लासिक अनिवार्य दृष्टिकोण को लागू करने की समस्या को हल करने का प्रयास कर रहे हैं। रिएक्ट में एक दृश्य सहारा, राज्य और पर्यावरण का एक कार्य है। जैसे function(state, props) { return // whatever you've computed from it } (लेकिन वास्तविक दुनिया में चीजें थोड़ी अधिक जटिल हो जाती हैं - अन्यथा प्रतिक्रिया बिल्कुल भी मौजूद नहीं होती)। हालांकि 0.14 हमें शुद्ध कार्यात्मक घटक मिलते हैं, अधिकांश घटकों के लिए यह प्रविष्टि फ़ंक्शन render() ।

इसका मतलब है कि आप render() से लिखना शुरू करते हैं और आप मानते हैं कि आपके प्रॉप्स हमेशा अप टू डेट हैं और आपको परवाह नहीं है कि props बदले गए हैं या नहीं, कितनी बार और कहां । आप मामले को निम्नलिखित तरीके से लागू किया जा सकता है:

// profile-view.js

var React = require('react');

module.exports = React.createClass({
    contextTypes: {
        app: React.PropTypes.object.isRequired
        // another option is var app = require('app')
        // or even var profiles = require('stores/profiles')
    },
    componentWillMount() {
        var {app} = this.context; // another option is to require('app')
        app.profiles.addListener('change', this.onStoreChange);
    },
    componentWillUnmount() {
        var {app} = this.context; // another option is to require('app')
        app.profiles.removeChangeListener('change', this.onStoreChange);
    },
    onStoreChange() {
        this.forceUpdate();
    },
    render() {
        var {app} = this.context;
        var profile = app.profiles.read(this.props.routeParams.id);
        if (profile) { // profile's been loaded
            return <div>{profile.name}</div>;
        } else { // not yet
            return <div>Loading...</div>;
        }
    }
});

// profiles-store.js
// app.profiles = new Profiles() on app initialization

var EventEmitter = require('events');
var {inherits} = require('util');

module.exports = Profiles;

function Profiles() {
    this.profiles = {};
}

inherits(Profiles, EventEmitter);

Profiles.prototype.read = function(id) {
    var profile = this.profiles[id];
    if (!profile) {
        $.get(`profiles/${id}`).then(profile => {
            this.profiles[id] = profile;
            this.emit('change');
        });
    }
    return profile;
};

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

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

@ shea256 this.state.profileName != this.props.profileName यह देखने के लिए जांच कर रहा है कि आंतरिक स्थिति (घटक क्या प्रस्तुत कर रहा है) माता-पिता घटक को प्रस्तुत करने के लिए कह रहा है या नहीं। यह लगभग "घटक अद्यतन हो रहा है" या "घटक अद्यतित है" की परिभाषा है, इसलिए मैं इसे हैकी के रूप में नहीं देखता। कम से कम, "डेटा-अपडेट अनुरोध को आग लगाना जब प्रोप बदलता है और कॉलबैक में एक सेटस्टेट करता है" के विचार से अधिक हैकी नहीं है।

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

और आपको किसने बताया कि कंपोनेंटडिडरिसिवप्रॉप्स गारंटी देगा कि प्रॉप्स बदल दिए गए हैं?

@ मी-आंद्रे यहाँ सही है। अधिकांश जीवनचक्र विधियां वास्तव में इस बात की गारंटी नहीं देती हैं कि कुछ बदल गया है; वे केवल संकेत देते हैं कि कुछ _शायद_ बदल गया है। इस कारण से, आपको हमेशा यह जांचना होगा कि क्या आप previous === next यदि आप http अनुरोध करने जैसा कुछ करने जा रहे हैं। इस धागे में लोगों का एक समूह यह धारणा बना रहा है कि उनका मूल्य केवल इसलिए बदल गया है क्योंकि जीवनचक्र पद्धति को निकाल दिया गया है।

@ मी-आंद्रे ने लिखा:

आप एक कार्यात्मक-उन्मुख ढांचे के लिए क्लासिक अनिवार्य दृष्टिकोण को लागू करने की समस्या को हल करने का प्रयास कर रहे हैं।

मुझे लगता है कि यह इस नई जीवनचक्र पद्धति को चाहने वाले लोगों का मूल कारण हो सकता है, लेकिन मैं अभी भी यह पता लगाने की कोशिश कर रहा हूं कि लोग इस पद्धति का उपयोग क्यों/कैसे करना चाहते हैं। यह पूरी तरह से संभव है कि वर्तमान जीवनचक्र शब्दार्थ कुछ हद तक गलत-गठबंधन है जो लोग आमतौर पर करना चाहते हैं।

सभी: क्या componentDidReceiveProps लिए "प्रोप चेंज के जवाब में डेटा को अतुल्यकालिक रूप से लोड करने" के अलावा कोई अन्य उपयोग के मामले हैं?

cc @grasick @iammerrick

@jimfb मैंने अपना कोड खोजा और मैं रेंडर के लिए आवश्यक महंगी-से-बनाने वाली वस्तुओं को बनाने के लिए componentWillReceiveProps का भी उपयोग करता हूं। यह मामला उसी समस्या से ग्रस्त है जिसमें उसे प्रॉप्स पास करने होते हैं और सावधान रहें कि कोड में this.props का उपयोग न करें।

@jimfb ने लिखा:

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

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

@jimfb ने लिखा:

@ shea256 this.state.profileName != this.props.profileName यह देखने के लिए जाँच कर रहा है कि क्या आंतरिक स्थिति (घटक क्या प्रस्तुत कर रहा है) माता-पिता द्वारा घटक को प्रस्तुत करने के लिए कह रहा है। यह लगभग "घटक अद्यतन हो रहा है" या "घटक अद्यतित है" की परिभाषा है, इसलिए मैं इसे हैकी के रूप में नहीं देखता। कम से कम, "डेटा-अपडेट अनुरोध को आग लगाना जब प्रोप बदलता है और कॉलबैक में एक सेटस्टेट करता है" के विचार से अधिक हैकी नहीं है।

हाँ, यह उचित प्रतीत होता है।

@jimfb ने लिखा:

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

मैं इससे बहुत सहमत हूं। मैंने इस पर सहायता प्राप्त करने के लिए अपना विशेष उपयोग-मामला पोस्ट नहीं किया। मैंने कुछ अंतर्दृष्टि प्रदान करने के लिए पोस्ट किया कि मुझे क्यों लगा कि componentDidReceiveProps उपयोगी होगा।

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

@jimfb ने लिखा:

@ मी-आंद्रे यहाँ सही है। अधिकांश जीवनचक्र विधियां वास्तव में इस बात की गारंटी नहीं देती हैं कि कुछ बदल गया है; वे केवल संकेत देते हैं कि कुछ बदल गया होगा। इस कारण से, आपको हमेशा यह जांचना होगा कि क्या पिछला === अगला यदि आप http अनुरोध करने जैसा कुछ करने जा रहे हैं। इस धागे में लोगों का एक समूह यह धारणा बना रहा है कि उनका मूल्य केवल इसलिए बदल गया है क्योंकि जीवनचक्र पद्धति को निकाल दिया गया है।

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

@jimfb ने लिखा:

मुझे लगता है कि यह इस नई जीवनचक्र पद्धति को चाहने वाले लोगों का मूल कारण हो सकता है, लेकिन मैं अभी भी यह पता लगाने की कोशिश कर रहा हूं कि लोग इस पद्धति का उपयोग क्यों/कैसे करना चाहते हैं। यह पूरी तरह से संभव है कि वर्तमान जीवनचक्र शब्दार्थ कुछ हद तक गलत-गठबंधन है जो लोग आमतौर पर करना चाहते हैं।

शायद। मैं इसके बारे में और सोचूंगा।

componentDidReceiveProps मेरे पास मौजूद विशिष्ट उपयोग के मामले में सहायक होगा।

मैं ReactRouter और Flux आर्किटेक्चर का उपयोग कर रहा हूं। जब मेरे घटक को तत्काल किया जाता है, तो मैं अपने राज्य को किसी स्टोर से किसी आइटम पर सेट करता हूं। जब वह स्टोर एक परिवर्तन ईवेंट उत्सर्जित करता है, तो मैं उसी पुनर्प्राप्ति क्वेरी का उपयोग करके अपना राज्य अपडेट करता हूं।

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

वर्तमान में, जब componentWillReceiveProps को कॉल किया जाता है, तो मैं यह देखने के लिए जांच करता हूं कि क्या मेरा कोई रूट पैरा बदल गया है, और यदि उन्होंने किया है, तो मैं updateItemState को कॉल करता हूं। लेकिन, क्योंकि प्रॉप्स वास्तव में अभी तक नहीं बदले हैं, मुझे अब प्रॉप्स को अपने तरीके से पास करना होगा।

this.updateItemState( nextProps );

updateItemState( props ) {
    props = props || this.props;

    this.setState( {
        item: this.getItemState( props )
    } );
}

getItemState( props ) {
    props = props || this.props;

    return this.ItemStore.get( props.params[ this.paramName ] );
}

बस बन जाएगा

this.updateItemState();

updateItemState() {
    this.setState( {
        item: this.getItemState()
    } );
}

getItemState() {
    return this.ItemStore.get( this.props.params[ this.paramName ] );
}

मुझे लगता है कि यह एक उचित उपयोग का मामला है।

@ akinnee-gl et al: यदि कंपोनेंटडिडअपडेट अपडेट के अलावा प्रारंभिक माउंट के बाद निकाल दिया गया, तो क्या यह आपके उपयोग के मामले को हल करेगा?

@ akinnee-gl, यदि आप फ्लक्स का उपयोग करते हैं, तो आपको राज्य को किसी स्टोर से सेट करने की आवश्यकता नहीं है। जब तक यह बिल्कुल असंभव न हो, आपको राज्य को एक ही स्थान पर बनाए रखना चाहिए। जब फ्लक्स की बात आती है तो वह जगह ही स्टोर होती है। जब स्टोर परिवर्तन का उत्सर्जन करता है, तो आप केवल forceUpdate() और फिर render() आप read() अपने स्टोर में।

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

कभी नहीँ।

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

    var item = this.props.store.read(this.props.id);
    return <div>{item.name}</div>;

यह आपका घटक है, और कुछ नहीं।
फ्लक्स के साथ इस नाटक को बनाने के लिए, आप स्टोर बाइंडिंग/अनबाइंडिंग के लिए एक पुन: प्रयोज्य घटक लिख सकते हैं:

<FluxWrapper store={store} component={Component} id={this.props.routeParams.id} />

var FluxWrapper = React.createClass({
    componentWillMount() {
        this.props.store.addListener('change', this.onStoreChange);
    },
    componentWillUnmount() {
        this.props.store.removeListener('change', this.onStoreChange);
    },
    onStoreChange() {
        this.forceUpdate();
    },
    render() {
        var Component = this.props.component;
        return <Component {...this.props} />;
    }
});

var Component = React.createClass({
    render() {
        var item = this.props.store.read(this.props.id);
        return <div>{item.name}</div>;
    }
});

देखें कि यदि आप रिएक्ट का ठीक से उपयोग करते हैं तो आपके घटक कितने छोटे हो सकते हैं।

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

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

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

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

@ akinnee-gl componentWillReceiveProps को प्रॉप्स बदलने के अलावा अन्य कारणों से भी बुलाया जा सकता है (देखें: https://github.com/facebook/react/issues/3279#issuecomment-164713518), इसलिए आपको अवश्य देखना चाहिए यदि प्रोप वास्तव में वैसे भी बदल गया है (चाहे आप किस जीवनचक्र को चुनें)। साथ ही, यदि आप वास्तव में एसिंक्रोनस डेटा कर रहे हैं, तो आप अगले ईवेंट लूप की प्रतीक्षा कर रहे हैं इससे पहले कि आपका कॉलबैक किसी भी तरह से निकाल दिया जाएगा, इसलिए मुझे नहीं लगता कि इससे कोई फर्क नहीं पड़ता कि आपका फ़ंक्शन आपके पहले/बाद में तुरंत लागू हो गया है समारोह प्रस्तुत करना, है ना?

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

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

मैं चर्चा की निगरानी कर रहा हूं और मैं तीसरे विकल्प को फिर से पेश करना चाहता हूं: (1) एपीआई बहुत बढ़िया है, (2) इसे घटकडिडरिसिवप्रॉप्स की जरूरत है, और (3) शायद एक आसान एपीआई है।

मैं इस मुद्दे को यह देखने के अवसर के रूप में देख रहा हूं कि क्या हम इस मुद्दे द्वारा उठाई गई अंतर्निहित आवश्यकता को हल कर सकते हैं (1) और (2) से समाधान स्थान पर चर्चा को सीमित करने के बजाय एपीआई को और अधिक गहरा परिवर्तन करके।

एक सरलीकृत एपीआई निम्नलिखित सिद्धांतों पर आधारित हो सकता है:

(ए) कोड संरचना को सरल बनाना / बॉयलरप्लेट को कम करना
(बी) प्रोप (इनपुट) को राज्य (आंतरिक) से अलग रखें

(ए) का मुख्य कारण यह है कि मैं खुद को गैर-मूल्य वर्धित बॉयलरप्लेट लिखता हुआ पाता हूं। उदाहरण:

componentWillMount() { this.actuallyCheckThePropsAndMaybeDoSomething(); }
componentWillReceiveProps(nextProps) { this.actuallyCheckThePropsAndMaybeDoSomething(nextProps); }

actuallyCheckThePropsAndMaybeDoSomething(props) {
  props = props || this.props;

  let relatedProps1 = _.pick(props, KEYS1);
  if (!shallowEqual(this.relatedProps1, relatedProps1) { // changed
   this.relatedProps1 = relatedProps1;

   // do something
  }

  let relatedProps2 = _.pick(props, KEYS2);
  if (!shallowEqual(this.relatedProps1, relatedProps2) { // changed
   this.relatedProps2 = relatedProps2;

   // do something else
  }
}

मैं वास्तव में निम्नलिखित करना चाहता हूं और पहली बार बनाम बदले के लिए एक अलग कोड पथ नहीं है:

propsUpdated(prevProps) {
  if (!shallowEqual(_.pick(prevProps || {}, KEYS1), _.pick(this.props, KEYS1)) { // changed
   // do something
  }

  if (!shallowEqual(_.pick(prevProps || {}, KEYS2), _.pick(this.props, KEYS2)) { // changed
   // do something
  }
}

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

डिजाइन सिद्धांतों के साथ शुरू करने के आधार पर (मुझे यकीन है कि और भी हैं!), मैं सोच रहा हूं कि propsUpdated और stateUpdated की तर्ज पर कुछ इस चर्चा के लिए संभावित तीसरा विकल्प हो सकता है। ?

@kmalakoff आपको हमेशा यह जांचना होगा कि क्या प्रोप बदल गया है, क्योंकि हम आपको निश्चित रूप से यह बताने में सक्षम नहीं होंगे कि प्रोप बदल गया/नहीं बदला (क्योंकि जावास्क्रिप्ट में मूल्य-प्रकार नहीं है और इसमें परिवर्तनशीलता है)।

उस नोट पर, शायद यह shouldComponentUpdate को यह बताने के लिए कॉल कर सकता है कि उसे propsDidChange या जो कुछ भी कॉल करना चाहिए। हालांकि अलग मुद्दा।

@jimfb उस भाषा की सीमा का ठीक-ठीक पालन नहीं कर रहा है जिसका आप उल्लेख कर रहे हैं और यह सामान्य रूप से एपीआई को सरल बनाने से कैसे संबंधित है। क्या आप कृपया थोड़ा और विस्तार से या उदाहरण के साथ समझा सकते हैं? मुझे इस स्पष्टीकरण को समझने के लिए सरलीकृत/थोड़ा विस्तारित करने की आवश्यकता है ...

मुझे लगता है कि उसका मतलब है कि this.props === nextProps जांच करने के लिए कोई अंतर्निहित, तेज़ तरीका नहीं है क्योंकि वे दो अलग-अलग ऑब्जेक्ट हो सकते हैं या नहीं।

{ a: 1 } === { a: 1 } झूठी उपज देता है क्योंकि वे दो अलग-अलग वस्तुएं हैं, लेकिन

var a = { a: 1 };
var b = a;
a === b

उपज सच है क्योंकि वे वास्तव में दोनों एक ही वस्तु के संदर्भ हैं।

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

@kmalakoff मैं इस सूत्र को https://gist.github.com/jimfb/9ef9b46741efbb949744

TLDR: @ akinnee-gl अपने स्पष्टीकरण में बिल्कुल सही है (धन्यवाद!)। मामूली सुधार के साथ कि हम हमेशा रिकर्सिव चेक नहीं कर सकते थे (भले ही हम चाहते थे, और प्रदर्शन एक गैर-मुद्दा था), क्योंकि प्रोप के रूप में पारित कॉलबैक फ़ंक्शन को दोबारा जांचने का कोई तरीका नहीं है।

आइए इस सूत्र को विषय पर रखें हालांकि: पी।

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

यदि कोई समाधान की विस्तृत श्रृंखला में भाग लेना चाहता है, तो कृपया हमसे वहां जुड़ें!

@jimfb @calmdev मैंने आपके सुझावों की कोशिश की है और अब मुझे पूरी समझ है कि क्यों componentDidReceiveProps वास्तव में कुछ नया नहीं जोड़ता है और इसे अतिरिक्त फ़ंक्शन के रूप में नहीं जोड़ा जाना चाहिए। जबकि मैंने पहले आपकी बात पर भरोसा किया था, अब यह मेरे लिए सहज समझ में आता है कि ऐसा क्यों है।

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

मेरे प्रोफ़ाइल पृष्ठ घटक पर एक नज़र डालें:

class ProfilePage extends Component {
  static propTypes = {
    fetchCurrentProfile: PropTypes.func.isRequired,
    currentProfile: PropTypes.object.isRequired
  }

  constructor(props) {
    super(props)
    this.state = { currentProfile: {} }
  }

  componentHasNewRouteParams(routeParams) {
    this.props.fetchCurrentProfile(routeParams.id)
  }

  componentWillMount() {
    this.componentHasNewRouteParams(this.props.routeParams)
  }

  componentWillReceiveProps(nextProps) {
    if (nextProps.routeParams.id !== this.props.routeParams.id) {
      this.componentHasNewRouteParams(nextProps.routeParams)
    }
    this.setState({
      currentProfile: nextProps.currentProfile
    })
  }

  render() {
    var profile = this.state.currentProfile
    return (
      <div>
        <h1>{ profile.name ? profile.name : null }</h1>
      </div>
    )
  }
}

जब घटक माउंट किया जाता है, तो उसके पास कोई प्रोफ़ाइल डेटा नहीं होता है और उसे बाहरी स्रोत से प्रोफ़ाइल लोड करने की आवश्यकता होती है।

तो... मैंने इसे fetchCurrentProfile फ़ंक्शन ( componentHasNewIdProp में लपेटा) कहा है जो बाहरी स्रोत से डेटा प्राप्त करता है, फिर Redux को एक अद्यतन कार्रवाई प्रेषित करता है। रेड्यूसर इस क्रिया को प्राप्त करता है और एप्लिकेशन स्थिति को अपडेट करता है, जो तब ProfilePage घटक के लिए प्रॉप्स को अपडेट करता है।

अब, चूंकि प्रॉप्स को अपडेट कर दिया गया है, componentWillReceiveProps फ़ंक्शन को कॉल किया जाता है। लेकिन हम प्रोप चेंज इवेंट के संदर्भ को नहीं जानते हैं, इसलिए हमें यह पता लगाने की जरूरत है कि कौन से प्रॉप्स (यदि कोई हैं) को बदल दिया गया है। हम देखते हैं कि आईडी वही है, इसलिए हमें fetchCurrentProfile फिर से कॉल करने की आवश्यकता नहीं है। फिर हम state.currentProfile अपडेट करते हैं ताकि घटक नए प्रोफ़ाइल डेटा के साथ फिर से प्रस्तुत करना जानता हो (हाँ मैं इसे प्रॉप्स के साथ कर सकता था, लेकिन इसका एक और कारण है कि मैं यहाँ नहीं जाना चाहता)। इस समय, हम यह देखने के लिए जांच कर सकते हैं कि राज्य को अपडेट करने से पहले props.currentProfile बदल गया है या नहीं, लेकिन यह एक महंगा ऑपरेशन नहीं है इसलिए अगर हम जांचते हैं तो इससे कोई फर्क नहीं पड़ता।

फिर... मान लें कि हम एक प्रोफ़ाइल से दूसरी प्रोफ़ाइल पर नेविगेट करना चाहते हैं। हम एक लिंक पर क्लिक करते हैं और राउटर मार्ग परिवर्तन को ट्रिगर करता है। अब हमारे पास नए मार्ग पैरामीटर हैं और componentWillReceiveProps फ़ंक्शन चालू हो जाता है। हम देखते हैं कि id बदल गया है और इसलिए हम fetchCurrentProfile फिर से कॉल करते हैं ( componentHasNewIdProp )।

जब नया फ़ेच वापस आता है और रेडक्स क्रिया भेजता है, तो currentProfile प्रोप को फिर से अपडेट किया जाता है, फिर राज्य को अपडेट किया जाता है, और घटक नए दृश्य के साथ फिर से प्रस्तुत करता है।

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

पीछे मुड़कर देखें, तो अनिवार्य रूप से मैं जो चाहता था वह एक ऐसा फ़ंक्शन था जो केवल तभी अपडेट होता है जब routeParams बदल जाता है। हालाँकि, किसी अन्य फ़ंक्शन को जोड़ने की कोई आवश्यकता नहीं है क्योंकि हम मौजूदा कार्यों के साथ वह सब कुछ कर सकते हैं जो हम चाहते हैं, साथ ही हम जीवनचक्र को जटिल नहीं करना चाहते हैं।

कुछ ऐसा जो यहां मदद कर सकता है, हालांकि, जीवन चक्र, कामकाजी उदाहरण इत्यादि पर अधिक दस्तावेज है।

दोस्तों, आपके सहयोग के लिए धन्यवाद। कृपया मुझे बताएं कि क्या यहां कुछ भी गलत है। मुझे आशा है कि यह भविष्य में इस धागे पर ठोकर खाने वाले किसी भी व्यक्ति के लिए सहायक होगा।

@ shea256 आपका उदाहरण एक नए एपीआई की जरूरत नहीं होने के कारण एक उचित मामले की तरह लगता है जो आपको एक नए एपीआई दृष्टिकोण के बिना प्राप्त करने में सक्षम है।

मैंने और विचारों को इसमें रेखांकित किया: https://gist.github.com/jimfb/9ef9b46741efbb949744 , लेकिन मुझे अभी भी ऐसा लगता है कि हमें कम कोड लिखने के लिए एपीआई को कारगर बनाने में सक्षम होना चाहिए ...

कल्पना कीजिए कि एपीआई ने आपको समान कार्यक्षमता लिखने की अनुमति दी है, लेकिन कम बॉयलरप्लेट के साथ:

class ProfilePage extends Component {
  static propTypes = {
    fetchCurrentProfile: PropTypes.func.isRequired,
    currentProfile: PropTypes.object.isRequired
  }
  state = {currentProfile: {}}; // not material to example (babel-stage-1)

  // called both on init and update
  willReceiveProps(nextProps) {
    if (!this.props || (this.props.routeParams.id !== nextProps.routeParams.id)
      nextProps.fetchCurrentProfile(nextProps.routeParams.id)
  }

  render() {
    var profile = this.props.currentProfile;
    return (
      <div>
        <h1>{ profile.name ? profile.name : null }</h1>
      </div>
    )
  }
}

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

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

बॉयलरप्लेट में कमी प्राप्त करना मैं उम्मीद कर रहा हूं कि यह समस्या प्राप्त कर सकती है (मेरी आवश्यकता/समस्या को स्पष्ट करने के लिए!) जीवनचक्र विधियों में महत्वपूर्ण रूप से, विधि नामों को छोटा करना अब ES6 व्यापक रूप से उपलब्ध है और घटक आगे का रास्ता प्रतीत होते हैं, आदि)।

@ akinnee-gl, कई छोटे घटकों से बना एक आवेदन कई कारणों से कुछ भारी घटकों की तुलना में काफी बेहतर है:

1. यह दृष्टिकोण "एकल जिम्मेदारी सिद्धांत" से जुड़ता है
2. आप स्पष्ट रूप से देख सकते हैं कि कौन सा घटक क्या करता है
3. आप आसानी से सुविधाओं की रचना कर सकते हैं और लपेटकर घटकों का विस्तार कर सकते हैं
4. तरीके और गुण आपस में नहीं टकराते
5. किसी सुविधा का विस्तार करना आसान है क्योंकि एक घटक एक विशेषता को समाहित करता है

आपके नोटिस के संबंध में कि प्रत्येक रेंडर पर एक स्टोर से पढ़ना अक्षम हो सकता है, मैंने एक सार बनाया है जो एक बुनियादी विचार दिखाता है कि कैशिंग के लिए मिडलवेयर घटक कैसे लागू किया जाए: https://gist.github.com/me-andre/0ca8b80239cd4624e6fc

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

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

उनमें से कुछ पर सार में स्पष्टीकरण हैं।

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

@kmalakoff आप जिन बिंदुओं का उल्लेख कर रहे हैं उनमें से कई अन्य मुद्दों के विषय हैं। उदाहरण के लिए (डी) का उत्तर https://github.com/reactjs/react-future/issues/40#issuecomment -142442124 और https://github.com/reactjs/react-future/issues/40#issuecomment द्वारा दिया जाता है - १५३४४०६५१. उस चर्चा के लिए वे उपयुक्त सूत्र हैं। यदि आप अधिक सामान्य/समग्र डिज़ाइन/एपीआई चर्चाओं की तलाश कर रहे हैं, तो संभवतः सही माध्यम https://discuss.reactjs.org/ है।

@jimfb मैंने इस पर कुछ विचार किया है जब आपने सुझाव दिया था कि मैं इसे

कृपया मुझे सुनें ... बॉयलरप्लेट को कम

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

उस ने कहा, मुझे एपीआई सुधारों को कम करने की कोशिश करने में खुशी होगी और उदाहरण के लिए, केवल इस मुद्दे में प्रॉप्स से संबंधित एपीआई को बेहतर बनाने के लिए समाधान स्थान की खोज पर ध्यान केंद्रित करें।

@kmalakoff धागे का विषय शीर्षक और पहली पोस्ट द्वारा परिभाषित किया गया है। शीर्षक है componentDidReceiveProps Please न कि lots of general ways to reduce boilerplate । यह धागा विशेष रूप से एक बहुत विशिष्ट जीवनचक्र पद्धति की शुरूआत के माध्यम से बॉयलरप्लेट को कम करने के बारे में है। अतिरिक्त विषयों (जैसे सभी कार्यों का नाम बदलना) को पेश किए बिना, जो पहले से ही अन्य मुद्दों पर चर्चा की जा रही है, वह चर्चा पहले से ही पर्याप्त है।

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

@jimfb लोग componentDidReceiveProps क्यों मांग रहे हैं? जिस कारण से मुझे इसमें दिलचस्पी है, वह है प्रॉप्स से संबंधित बॉयलरप्लेट को

आपने समस्याओं और मामलों का उपयोग करने के लिए कहा है, और मैंने इसे मेरे लिए समस्या के रूप में बताया है और ऊपर एक उपयोग केस दिखाया है (@ shea256 का जवाब) जो विषय पर, दायरे में और, मेरे परिप्रेक्ष्य से, हल करने के लिए महत्वपूर्ण है यह मुद्दा।

मैं सामान्य एपीआई मुद्दों/सुधारों और इच्छा के दायरे का विस्तार करने पर सहमत हूं। मे वादा करता हु! :आँख मारना:

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

@kmalakoff , ठीक है, बॉयलरप्लेट को कम करने के लिए आप बस पुन: प्रयोज्य कक्षाएं या घटक बनाते हैं जिनसे आप उपवर्ग करते हैं या अन्य घटकों की रचना करते हैं। आपके ऐप में सभी घटकों के लिए एक सामान्य विधि को परिभाषित करने से आपको कोई नहीं रोकता है। रिएक्ट उत्कृष्ट विस्तारशीलता प्रदान करता है: आप घटकों को वस्तुओं, कार्यों या कक्षाओं के रूप में परिभाषित कर सकते हैं। आप उपवर्ग, मिश्रण या कारखानों द्वारा घटकों का विस्तार कर सकते हैं।

@ मी-आंद्रे यह बिल्कुल एक विकल्प है यदि यह समस्या एपीआई सुधार की ओर नहीं ले जाती है।

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

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

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

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

उपयोग-मामले क्या हैं जहां आप केवल नए प्रोप प्राप्त करने पर कुछ ट्रिगर करना चाहते हैं (और प्रारंभिक प्रोप रिसेप्शन पर नहीं)?

मैं यहाँ कुछ स्पष्ट याद कर रहा था, लेकिन विभिन्न दलों के दृष्टिकोणों को समेटने की कोशिश कर रहा था।

किसी भी मामले में, अगर कुछ मामलों में componentWillReceiveNewProps महत्वपूर्ण थे, तो कोई भी आने वाले प्रोप पर चेक करके संशोधित componentWillReceiveProps साथ इसका अनुकरण कर सकता है।

@kmalakoff अगर componentWillReceiveProps पहली बार ट्रिगर हुआ, तो क्या यह एपीआई सरलीकरण के लिए आपके मानकों को पूरा करेगा?

componentWillReceiveProps माउंट पर ट्रिगर नहीं होने का कारण यह नहीं है कि लोग componentDidReceiveProps मांग रहे हैं। लोग componentDidReceiveProps मांग रहे हैं क्योंकि उन्होंने this.props तक पहुंचने के अपने सभी तरीकों को लिखा है। जब componentWillReceiveProps को कॉल किया जाता है, तो नेक्स्टप्रॉप्स पास हो जाते हैं, लेकिन this.props अभी तक नहीं बदला है, जिसका अर्थ है कि हमें nextProps को उन सभी तरीकों में पास करना होगा जिन्हें componentWillReceiveProps जवाब में कहा जाता है। props = props || this.props एक टन और हमारे द्वारा कॉल किए जाने वाले प्रत्येक फ़ंक्शन में props पास करने के एक टन के साथ समाप्त होते हैं।

@ shea256 अच्छे अंक। आरंभीकरण बनाम परिवर्तन के लिए अलग-अलग कोड पथ होना प्रोप बॉयलरप्लेट के मूल कारणों में से एक है। अन्य मूल कारण @ akinnee-gl पॉइंट आउट जैसे प्रॉप्स को संभालने के लिए अलग-अलग हस्ताक्षर हैं।

यही कारण है कि मैं विचार किए जा रहे समाधान स्थान का विस्तार करने की कोशिश कर रहा हूं (उदाहरण के लिए init पर भी कॉल करें) क्योंकि वास्तव में प्रोप बॉयलरप्लेट को और कम करने के लिए एक बेहतर समाधान हो सकता है।

मुझे आशा है कि हम आगे बढ़ने में सक्षम होंगे:

न्यू हुक से पहले

componentWillMount() {
  this.setup(this.props.id);
}

componentWillReceiveProps(next) {
  this.setup(next.id);
}

setup(id) {
  UserActions.load(id);
}

न्यू हुक के बाद (संशोधित)

componentDidReceiveProps(prevProps) {
  UserActions.load(this.props.id);
}

या यदि UserActions.load वर्तमान में लोड की गई आईडी की जांच नहीं कर सकता है:

componentDidReceiveProps(prevProps) {
  if (!prevProps || (prevProps.id !== this.props.id))
    UserActions.load(this.props.id);
}

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

@ shea256 , componentWillReceiveProps पहले रेंडर से पहले ट्रिगर न होने का एक संभावित कारण यह है कि उस समय this.props जैसी कोई चीज़ नहीं है। आप आमतौर पर componentWillReceiveProps जो करते हैं वह this.props[propName] तुलना newProps[propName] । पहली रेंडर से पहले विधि को ट्रिगर करने से आपको this.props उपस्थिति की भी जांच करनी होगी। इसके अलावा, प्रारंभिक रेंडर से पहले props प्राप्त होने पर पूरा घटक पूरी तरह से प्रारंभ नहीं होता है, इसमें state भी नहीं होता है।

@kmalakoff , मैंने दो बार कोड नमूने पोस्ट किए हैं जो दिखाते हैं कि कैसे एक प्रतिक्रिया घटक को इस तरह व्यवस्थित करना है कि उसे किसी भी setup या इसी तरह के हैक की आवश्यकता नहीं है। क्या आप कृपया बता सकते हैं कि आप अपने कोड को समायोजित करने के बजाय रिएक्ट घटक के व्यवहार को बदलने का प्रयास क्यों करते हैं ताकि यह रिएक्ट के साथ एकीकृत हो जाए? यह बहुत अच्छा होगा यदि आप केवल यह इंगित करें कि मेरे नमूने आपके उपयोग-मामले के लिए अनुपयुक्त हैं।

@ akinnee-gl, अपडेट पर केवल this.props तक पहुंचने के लिए एक नई विधि पेश नहीं करने का कारण यह है कि हमारे पास ऐसी विधि है - इसे render() कहा जाता है। इसे shouldComponentUpdate() चेक के बाद भी कॉल किया जाता है - जो आम तौर पर एक ऐसा स्थान होता है जहां आप this.props !== newProps या _.isEqual(this.props, newProps) आदि करते हैं।
यदि आपको लगता है कि आपके पास कुछ सेटअप के लिए एक अलग विधि होनी चाहिए, तो क्यों न केवल एक प्रतिक्रिया घटक को उपवर्गित करें और निम्नलिखित render() विधि को परिभाषित करें

this.setup(this.props);
return this._render();

मैं यह नहीं देखता कि यह रिएक्ट इकोसिस्टम में चीजों को कैसे सरल करता है, लेकिन आप यही अनुरोध करते रहते हैं।

@ me-andre इस मुद्दे का आधार यह नहीं है कि हम वर्तमान एपीआई के साथ जो चाहते हैं उसे प्राप्त नहीं कर सकते हैं और न ही हम क्लाइंट कोड में वर्तमान एपीआई के आसपास काम नहीं कर सकते हैं। इस मुद्दे का आधार यह है कि वर्तमान रिएक्ट एपीआई उप-इष्टतम है और इसमें सुधार की आवश्यकता है ; उदाहरण के लिए, यदि आप एक इष्टतम एपीआई के सिद्धांतों के साथ आने वाले थे (जैसे मैंने ऊपर की कोशिश की), तो वर्तमान रिएक्ट एपीआई एक मध्य-स्तर की सीमा में स्कोर करेगा क्योंकि यह कई क्षेत्रों में उप-रूपी / कमी है।

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

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

प्रतिक्रिया 1.0 का लक्ष्य शीर्ष पर होना चाहिए, न कि मध्य के लिए। एक प्रमुख संस्करण वृद्धि पश्चगामी संगतता को तोड़ सकती है, तो आइए 0.x संस्करण का उपयोग करने के इन सभी वर्षों से हमने जो कुछ सीखा है, उसके आधार पर सर्वोत्तम संभव एपीआई के लिए चलते हैं।

(FYI करें: मुझे लगता है कि लोग आपके उदाहरणों के साथ उतना नहीं जुड़ रहे हैं जितना आप उम्मीद कर रहे हैं क्योंकि वे वर्तमान एपीआई के बारे में सिखाने के लिए यहां नहीं आ रहे हैं, बल्कि इसलिए कि वे एपीआई में सुधार की तलाश/उम्मीद कर रहे हैं, उदाहरण के लिए वे अच्छे इरादों के रूप में माना जा सकता है, लेकिन थोड़ा गलत तरीके से किया जा रहा है)

मुझे लगता है कि लोग आपके उदाहरणों के साथ उतना नहीं जुड़ रहे हैं जितना आप उम्मीद कर रहे हैं क्योंकि वे यहां वर्तमान एपीआई के बारे में सिखाने के लिए नहीं आ रहे हैं, बल्कि इसलिए कि वे एपीआई में सुधार की तलाश/उम्मीद कर रहे हैं

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

दुर्भाग्य से, रिएक्ट एपीआई के आसपास काम करने के लिए क्लाइंट कोड में तरीके प्रदान करने से समस्या के मूल कारणों का समाधान नहीं होता है

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

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

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

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

@ मुझे-आंद्रे मैं आपको सुनता हूं और आपके तर्क की रेखा स्पष्ट है।

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

आप प्रॉप्स के इर्द-गिर्द मौजूदा रिएक्ट एपीआई को कैसे रेट करेंगे? (मान लें कि अक्षर ग्रेड का उपयोग करते हुए: F से A+), क्यों, और यदि यह A+ से कम है तो आप इसे सुधारने के लिए क्या करेंगे?

@ मुझे-आंद्रे क्या आपको अपनी रैंकिंग और विश्लेषण तैयार करने का मौका मिला है? मुझे यह जानने में दिलचस्पी है कि आप वर्तमान एपीआई की ताकत, कमजोरियों और अवसरों को क्या मानते हैं।

+1

+1 कृपया

क्या आसपास कोई काम है? मुझे ComponentDidReceiveProps की आवश्यकता है

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

@AlexCppns आप क्या करने की कोशिश कर रहे हैं?

@iammerrick , वास्तव में यह ठीक है, मैंने अभी गलत समझा है कि कैसे कंपोनेंटविल

संबंधित चर्चा: https://github.com/facebook/react/issues/7678

मैं इसमें कुछ बार भाग चुका हूं, और मैंने जो किया वह था:

componentWillReceiveProps(nextProps) {
  if (this.props.foo !== nextProps.foo) this.needsUpdate = true;
}
componentDidUpdate() {
  if (this.needsUpdate) {
    this.needsUpdate = false;
    // update the dom
  }
}

यह बहुत खराब नहीं है।

@ब्रिगैंड , ध्वज की कोई आवश्यकता नहीं है - आप componentDidUpdate() भीतर प्रोप की तुलना कर सकते हैं:

componentDidUpdate(prevProps) {
    let needsUpdate = prevProps.foo !== this.props.foo;
    // ...whatever
}

इसके अलावा, आपके समाधान को shouldComponentUpdate() द्वारा आसानी से तोड़ा जा सकता है, जो पुन: प्रतिपादन को रोक सकता है।

ओह कूल, धन्यवाद!

@jimfb मुझे लगता है कि मेरे पास नीचे एक तुल्यकालिक उपयोग का मामला है। मुझे लगता है कि एक componetDidReceiveProps इसके लिए एकदम सही होता।

  componentDidMount() {
    this._selectAll()
  }

  componentDidUpdate(prevProps) {
    let shouldUpdateSelected = (prevProps.recordTypeFilter !== this.props.recordTypeFilter) ||
      (prevProps.statusFilter !== this.props.statusFilter) ||
      (prevProps.list !== this.props.list)

    if (shouldUpdateSelected) { this._selectAll() }
  }

  _selectAll() {
    this.setState({ selectedIds: this._getFilteredOrders().map((order) => ( order.id )) })
  }

  _getFilteredOrders() {
    let filteredOrders = this.props.list

    // recordTypeFilter
    let recordTypeFilter = this.props.recordTypeFilter
    filteredOrders = _.filter(filteredOrders, (order) => {
        // somelogic
    })

    // statusFilter
    let statusFilter = this.props.statusFilter
    filteredOrders = _.filter(filteredOrders, (order) => {
        // somelogic
    })

    return filteredOrders
  }

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

1. यह componentWillReceiveProps का उपयोग मामला है, न कि componentDidUpdate । यदि आप componentWillReceiveProps स्विच करते हैं, तो आपका घटक उसी तर्क को संरक्षित करते हुए दो बार कम प्रस्तुत करेगा। इस चर्चा को छोड़ने के एक साल बाद भी मुझे अभी भी componentDidUpdate लिए डीओएम परिवर्तनों पर प्रतिक्रिया के अलावा शून्य उपयोग केस दिखाई देता है।
2. बहुत बेहतर है, हालांकि हुक से बचना होगा और सभी तर्कों को render() विधि/स्टेटलेस घटक में माइग्रेट करना होगा, क्योंकि this.state.selectedIds वास्तव में एक राज्य नहीं है। यह पूरी तरह से प्रॉप्स से गणना की जाती है।

हाय @ मी-आंद्रे, उत्तर देने के लिए समय निकालने के लिए धन्यवाद। मैंने इस पृष्ठ पर चर्चा पढ़ी है और इसमें भाग लेने के लिए मैं आपको धन्यवाद देना चाहता हूं।

हां, componentDidReceiveProps की जरूरत नहीं है, लेकिन इसके बिना चीजें रहस्यमयी लगती हैं।
आपने your component would re-render twice as less यदि मैं componentWillReceiveProps उपयोग करता हूं। यह अभी भी मेरे लिए एक रहस्य है।

मैंने उन दो चीजों के बारे में सोचा और कोशिश की जिन्हें आपने पहले सुझाया था, लेकिन असफल रहा।

1. कंपोनेंटविल रिसीवप्रॉप्स काम नहीं करेगा क्योंकि _getFilteredOrders() फ़ंक्शन को _selectAll() से कॉल किया गया है, जिसे न्यूप्रॉप्स की आवश्यकता है।
2. मैं इसे राज्य में संग्रहीत किए बिना selectedIds प्राप्त करने के तरीके के बारे में नहीं सोच सका।

मैंने अभी अपने उपयोग के मामले से एक पूरा उदाहरण बनाया है। मैंने जितना संभव हो उतना समझना आसान बना दिया है।

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

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

हालांकि मैं आपको सही दिशा में इंगित कर सकता हूं:

1. componentWillReceiveProps() और componentDidUpdate() ही पिछले और अगले प्रॉप्स तक पहुंच सकते हैं। यह आधिकारिक रिएक्ट डॉक्स से स्पष्ट रूप से देखा जाता है।
2. आपके कोड के पूर्ण कॉपीपेस्ट से अब यह स्पष्ट है कि आप राज्य का उपयोग चयनित आईडी को संग्रहीत करने के लिए करते हैं जिसे उपयोगकर्ता टॉगल कर सकता है। तब राज्य का उपयोग करना ठीक है, लेकिन फिर भी componentWillReceiveProps() कम से कम दो बार फिर से प्रस्तुत करना ट्रिगर करेगा। (क्योंकि किसी भी तरह से componentWillReceiveProps() बाद एक रेंडर होने वाला है, setState() आगामी रेंडर के लिए बस स्थिति को अपडेट करेगा)।
3. कृपया डॉक्स पर एक नज़र डालें। अपना समय बचाएं और दूसरों का सम्मान करें।

@ मुझे-आंद्रे मुझे लगता है कि मैं दस्तावेज़ों में इस पंक्ति का उपयोग करके componentWillReceiveProps बारे में आपकी बात समझता हूं:

यदि आप इसे कॉल करते हैं तो कॉम्पोनेंटविल रिसीवप्रॉप्स () लागू नहीं होता है। सेटस्टेट ()

लेकिन componentWillReceiveProps का उपयोग करने की चेतावनी यह है कि मुझे नेक्स्टप्रॉप्स के साथ फ़ंक्शंस में जाना होगा।

मैं आपकी सलाह का पालन करने की कोशिश करूंगा। धन्यवाद मैं इसकी प्रशंसा करता हूँ।

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

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

मेरा काम वांछित फ़ंक्शन चलाने से पहले इसे सेट करना है। प्रॉप्स को नए प्रॉप्स पर सेट करना है

ComponentDidMount या उसके लिए कुछ हुक रखना वाकई अच्छा होगा। क्यों? क्योंकि, कभी-कभी, हमें अन्य गणनाएँ करने की आवश्यकता होती है जो रिएक्ट जीवनचक्र पर निर्भर नहीं करती हैं।

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