Redux: प्रश्न: Redux के स्टोर और रिएक्ट की स्थिति के बीच चयन कैसे करें?

एपर्मेरल स्टेट के लिए रिएक्ट का उपयोग करें जो विश्व स्तर पर ऐप के लिए महत्वपूर्ण नहीं है और जटिल तरीकों से उत्परिवर्तित नहीं करता है। उदाहरण के लिए, कुछ UI तत्व में एक टॉगल, एक फॉर्म इनपुट स्थिति। राज्य के लिए Redux का उपयोग करें जो विश्व स्तर पर मायने रखता है या जटिल तरीकों से उत्परिवर्तित होता है। उदाहरण के लिए, कैश्ड उपयोगकर्ता, या पोस्ट ड्राफ्ट।

कभी-कभी आप Redux राज्य से React राज्य में स्थानांतरित करना चाहते हैं (जब Redux में कुछ संग्रहीत करना अजीब हो जाता है) या अन्य तरीके से (जब अधिक घटकों को कुछ राज्य तक पहुंच की आवश्यकता होती है जो स्थानीय हुआ करते थे)।

अंगूठे का नियम है: जो भी कम अजीब है उसे करो।

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

उन राज्यों के लिए दो या दो से अधिक कंटेनरों द्वारा सुनी जाने वाली दुकानों के लिए भी होना चाहिए?

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

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

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

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

एप्लिकेशन राज्य Redux का डोमेन है और UI राज्य प्रतिक्रिया का डोमेन है।

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

जिस तरह से मैं इसके बारे में सोचता हूं, यदि आप Redux के साथ एक ऐप बनाते हैं, तो एकल राज्य के पेड़ को गले लगाओ। वहाँ भी UI स्थिति रखें। हालांकि अगर यह थकाऊ और निराशाजनक हो जाता है तो घटकों को राज्य में रखने से डरो मत। मेरा कहना है कि एकल राज्य के पेड़ का उपयोग करें जब तक कि यह अजीब न हो, और केवल यह तब करें जब यह आपके लिए चीजों को सरल बनाता है बजाय उन्हें उलझाए। यही एकमात्र दिशानिर्देश है।

सबसे पहले, मैं निश्चित रूप से @gaearon के मुंह में शब्दों को डालने के लिए नहीं था, इसके लिए क्षमा करें।

दूसरा, मैं पूरी तरह से @gaearon से सहमत हूं। मैं एकल राज्य वृक्ष दृष्टिकोण में भी दृढ़ता से विश्वास करता हूं। जब मैंने UI स्थिति के बारे में बात की थी, तो मेरे दिमाग में वास्तव में मामूली चीजें थीं (जैसे कि वर्तमान टैब क्या चुना गया है) जहां यह वास्तव में आवेदन राज्य के लिए प्रासंगिक नहीं हो सकता है (बिल्कुल @gaearon पर चर्चा की गई है)।

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

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

मुझे लगता है कि यह प्रश्न वास्तव में व्यक्तिपरक और जटिल है, इसलिए मैंने आज अपनी टीम के साथ एक कठिन निर्णय लिया, परेशान न हों:

• गैर-पुन: प्रयोज्य कंटेनर के लिए, जिसका संबंध Redux से है, बस सब कुछ Redux स्टोर में रख दिया, यहां तक ​​कि छोटे UI स्थिति जैसे कि यदि कोई मोडल खुला है, तो this.setState उपयोग न करें।
• पुन: प्रयोज्य घटक के लिए, जिसका Redux से कोई लेना-देना नहीं है, प्रतिक्रिया स्थिति का उपयोग करें।

और अब हम छोटे यूआई राज्य का प्रबंधन करने के लिए इसे कम थकाऊ बनाने के लिए कुछ सहायकों को लागू कर रहे हैं।

@gaearon @ lionng429 @xogeny आप इस दृष्टिकोण के बारे में सोच सकते हैं?

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

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

अगर किसी को परवाह है, तो मुझे https://gist.github.com/markerikson/554cab15d83fd994dfab पर एक Gist के रूप में HOC मिला है।

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

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

हमारे अनुप्रयोगों में हमने कनेक्ट-जैसी शैली में इस समस्या को हल किया। https://github.com/Babo-.in/redux-state

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

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

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

@gaearon आप अपने अनुभवों को साझा करना चाहते हैं कि यह कैसे तय किया जाए कि यह कब और कैसे माना जाता है _awkward_? निर्वासन के लिए, क्या आप कुछ विशिष्ट परिदृश्य / उदाहरण दे सकते हैं जो आपको लगता है कि यह काफी अजीब है अगर उन्हें आवेदन राज्य परमाणु में डाल दिया जाए? अग्रिम में धन्यवाद!

@idavollen मैं एक जोड़ी दे सकता हूं:

• एक ड्रॉपडाउन ओपन / क्लोज स्टेट, अन्यथा आपको अपने स्टोर में सभी ड्रॉपडाउन घटकों का ट्रैक रखना होगा
• जब आप <input> परिवर्तन की बहस कर रहे हों, तो आप राज्य का उपयोग तुरंत मूल्य अपडेट करने के लिए कर सकते हैं (और आप अनावश्यक रूप से पुन: रेंडर करने के लिए अन्य घटकों को जोखिम में नहीं डाल रहे हैं) और स्टोर को एक विवादित तरीके से अपडेट करें

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

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

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

मैं सोच रहा हूँ कि इस मामले में इन राज्यों के चेकबॉक्स का प्रबंधन करने का सबसे अच्छा तरीका क्या है?

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

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

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

यह तय करना आपके लिए है कि Redux में कौन सा राज्य जाता है, और एक घटक के लिए स्थानीय क्या रहता है। आप http://redux.js.org/docs/faq/OrganizingState.html#organizing -state-only-redux-state और http://redux.js.org/docs/faq/Prformance के माध्यम से पढ़ना चाह सकते हैं

@dowk प्रदर्शन के मामले पर अपना ज्ञान साझा करने के लिए धन्यवाद, मैंने वही सोचा लेकिन पुष्टि की जरूरत है।
इसके अलावा, लिंक के लिए @markerikson धन्यवाद, मैं एक बार फिर उन पर एक नज़र

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

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

या, जैसा कि डैन ने बताया है, आप एक घटक की स्थिति को अपडेट करने के लिए एक रिड्यूसर-शैली के दृष्टिकोण को भी लागू कर सकते हैं! Https://twitter.com/dan_abramov/status/736310245945933824 देखें

मैं जानना चाहता हूं कि कहां यूआई राज्य को स्टोर करना है जैसे गतिविधि संकेतक और मोडल ओपन या क्लोज। क्या सेटस्टैट का उपयोग करने से प्रतिक्रिया घटकों की इकाई परीक्षण में समस्या होती है?

@ akshay2604 : फिर से, यह आपके ऊपर है। इस थ्रेड में मैंने पिछली टिप्पणियों में पोस्ट किए गए लिंक देखें। घटकों का परीक्षण करते समय आप निश्चित रूप से setState का उपयोग कर सकते हैं, खासकर यदि आप उन्हें परीक्षण करने में मदद करने के लिए एंजाइम लाइब्रेरी का उपयोग कर रहे हैं।

मुझे अपने विचार साझा करने दें।

मैं राज्य को 3 व्यापक श्रेणियों में वर्गीकृत करता हूं, जिसके अनुसार यह एप्लिकेशन के इनपुट / आउटपुट से संबंधित है:

• "कैश": एक ऐसी स्थिति जो लगातार डेटा का दर्पण है। उदाहरण:

{ "todos": [{ id: 1, title: "title" }, { id: 2, title: "title" }] }

• "परिवर्तन": एक स्थिति जो निरंतर डेटा में लंबित परिवर्तनों का वर्णन करती है। उदाहरण:

{ "changeTodo": { title: "title", action: "add", done: false },
{ id: 1, title: "changed title", action: "modify", done: true }, { id: 2, action: "delete" } }

• "दृश्य": एक राज्य जो वर्तमान फ़िल्टरिंग, सॉर्टिंग, आदि जैसे दृश्य विकल्पों को बताता है उदाहरण:

{ "displayOptions": { searchTerm: "title", sort: ["title", "desc"], filter: "done=false" } }

आप cache changes मिक्स नहीं करते हैं, आप cache view मिश्रण नहीं करते हैं, आप view साथ मिश्रण नहीं करते हैं changes ।

बेशक आपको इसे किसी एक रिएक्शन कंपोनेंट में प्रदर्शित करने के लिए किसी तरह मर्ज करने की आवश्यकता है। ताकि आपकी "मर्ज" वस्तु बन जाए:

{ "todos": [{id: undefined, title: "title", done: false }, { id: 1, title: "changed title" }] }

लेकिन यह एक राज्य नहीं है, यह आपके आवेदन तर्क का एक परिणाम है। इसलिए आपको इसे कहीं भी नहीं रखना चाहिए।
आप चयनकर्ताओं में इस मर्ज किए गए राज्य को कैश कर सकते हैं, आप इसे स्टोर में कैश कर सकते हैं, आप इसे घटकों में कैश कर सकते हैं, लेकिन यह "राज्य" नहीं है, यह महत्वपूर्ण नहीं है, आप आसानी से अपने आवेदन तर्क फ़ंक्शन को सभी 3 राज्य टुकड़ों में पुनः प्राप्त कर सकते हैं और फिर से एक विलय राज्य प्राप्त करें। यही क्रियात्मक दृष्टिकोण है।

Redux अनुरक्षक आपको बताएंगे "अरे, आपको अपने आवेदन तर्क को कई reducers और कई घटनाओं के रूप में लागू करना चाहिए, जो आपके" मर्ज किए गए "ऑब्जेक्ट के विभिन्न भागों का निर्माण करेगा।"
मुझे लगता है कि यह एक गलत तरीका है। इसका मतलब है कि आप redux से दूर नहीं जा पाएंगे। आपके राज्य का प्रबंधन करने के लिए एक उपकरण के रूप में क्या होना चाहिए था अनिवार्य रूप से आपके आवेदन तर्क का कार्यान्वयन हो जाता

नमस्ते, मैं कुछ दिनों के लिए React / Redux में खुदाई करता हूं, यह चुनने के लिए किए गए निर्णय को समझें कि क्या कुछ जानकारी को स्टोर करने के लिए प्रचारित किया जाना चाहिए या घटक स्थानीय स्थिति में रखा जाना चाहिए।

लेकिन क्या होगा अगर 1 कार्रवाई के लिए दोनों की आवश्यकता हो? यहाँ उपयोग-मामला है, जो बहुत आम है:

1. [संदर्भ] Redux स्टोर एक एकल पत्ता { modelItems: myModelItems } । यह सर्वर मॉडल को कैश करता है (/ का एक प्रक्षेपण)
2. [संदर्भ] दृश्य एक एकल स्मार्ट घटक MyItemsView से बना है जो संग्रहीत / कैश्ड वस्तुओं की एक यूआई-सूची प्रदर्शित करता है। घुड़सवार होने पर, घटक एक मॉडल-आइटम लाने में सक्षम होता है। घटक इनपुट: myModelItems । घटक आउटपुट: एक fetchModelItems एक्शन-ट्रिगर। घटक इंटर्नल्स: state.busy और state.errorId
3. [योजना] जब MyItemsView चलाता fetchModelItems , एक HTTP अनुरोध आदेश मॉडल और दुकान में यह कैश लाने के लिए में सर्वर के लिए भेजा है। इस async कार्रवाई में 4 चरण हैं और जितने भी हुक हैं: onStarted (HTTP अनुरोध ले-ऑफ, लोडिंग स्पिनर घटक में शुरू होता है), onEnded (HTTP प्रतिक्रिया उतरा, घटक में लोडिंग स्पिनर स्टॉप , एक अभी भी प्रतिक्रिया की स्थिति पर ध्यान नहीं देता है), onFailed (एक त्रुटि अधिसूचना घटक में दिखाई गई है) और onSucceed (Redux स्टोर अपडेट किया गया है तो इसे रखने वाले मॉडल-कैश को आगे भेज दिया जाता है। प्रतिपादन के लिए घटक)

इसलिए, fetchModelItems एक्शन-ट्रिगर को कैसे विभाजित किया जाए:

• onStarted , onEnded और onFailed Redux स्टोर को हिट नहीं करते हैं? ऐसा इसलिए है क्योंकि onStarted और onEnded क्षणिक यूआई स्टेट्स हैं जिनका मॉडल-कैश के साथ कोई इंटरैक्शन नहीं होना चाहिए। वही onFailed लिए चला जाता है (मॉडल-कैश अपरिवर्तित रहता है और UI एक त्रुटि सूचना प्रदान करेगा)। MyItemsView यूआई-राज्य को यहां प्रस्तुत करेगा, कैश्ड-मॉडल नहीं
• onSucceed Redux स्टोर हिट करता है? क्योंकि इसने मॉडल-कैश लॉटरी जीती है, इसे सत्य के स्रोत तक पहुंच प्रदान की जाती है, शॉवर और रिहाइड्रेट किया जाएगा, फिर ताजा myModelItems MyItemsView

मेरे वर्तमान प्रयास में कार्यान्वयन के बारे में, Redux Thunk fetchModelItems एक्शन-ट्रिगर का ध्यान रखता है। मुझे ऐसा लगता है कि मैंने वहां Redux पथ को चुना है, और मैं अपना मन अब यह बताने के लिए नहीं बदल सकता हूं कि "Redux स्टोर पर सिर्फ Async सफलता को पास करें, रिएक्ट कंपोनेंट स्टेट में कुछ और रखें"।

इस से हैरान, मैं स्टोर करने के लिए सफलताओं को प्राप्त करता हूं, जो कि जुड़े घटक (यानी रेडक्स कंटेनर) के लिए आगे की तरफ है। लेकिन कोई लोडिंग स्पिनर और एक दयनीय सांत्वना-लॉग त्रुटि-संदेश atm। मैं store.ui.myItemsView.busy और न ही store.ui.myItemsView.errorId को परिभाषित नहीं करना चाहता, लेकिन बस घटक राज्य में उन जानकारी को प्राप्त करें।

@ पास्कलव :
यह एक बग ट्रैकर है, समर्थन प्रणाली नहीं है। उपयोग के प्रश्नों के लिए, कृपया स्टैक ओवरफ्लो या रिएक्टिफ्लक्स का उपयोग करें जहां आपकी सहायता करने के लिए बहुत अधिक लोग तैयार हैं - आपको शायद बेहतर उत्तर मिलेगा। धन्यवाद!