हम फ्लक्स/रेडक्स आर्किटेक्चर में कार्रवाइयों और reducers क्यों decouple?

Question

मैं फ्लक्स पहले और Redux बाद में एक बहुत लंबे समय के लिए उपयोग कर रहा है, और मैं उनकी तरह कर , और मैं उनके लाभ देखते हैं, लेकिन एक सवाल मेरे मन में पॉपिंग रहता है:

क्यों हम दसगुणा करना क्रियाओं और reducers और कॉल के बीच अतिरिक्त संकेत जोड़ें जो राज्य (कार्रवाई) और राज्य (reducer) को बदलने के वास्तविक तरीके को बदलने के इरादे को व्यक्त करेगा, इस तरह से स्थिर या रनटाइम गारंटी और त्रुटि प्रदान करना अधिक कठिन है जाँच? राज्यों को संशोधित करने वाले तरीकों या कार्यों का उपयोग क्यों न करें?

तरीके या समारोह, स्थिर guaranties (टाइपप्रति या प्रवाह का उपयोग) और रनटाइम guaranties (विधि/समारोह नहीं मिला, आदि) प्रदान करेगा, जबकि एक कार्रवाई नहीं संभाला सब (या तो स्थिर या क्रम), तो आप 'में कोई त्रुटियों को बढ़ा देंगे आपको सिर्फ यह देखना होगा कि अपेक्षित व्यवहार नहीं हो रहा है।

• यह बहुत ही आसान है
इसके बारे में
• Think घटक के राज्य इंटरफ़ेस प्रतिक्रिया के रूप में (setState, this.state), बिना:

  मुझे इसे थोड़ा बेहतर उदाहरण देना हमारी सैद्धांतिक राज्य कंटेनर (टीएससी) के साथ करते हैं प्रतिपादन भाग।

तो, केवल एक चीज आप की जरूरत अपने घटकों के एक फिर से प्रस्तुत करना है जब हमारे टीएससी परिवर्तन में राज्य और संभावना है कि राज्य है, जो हमारे मामले में सादे तरीके कि राज्य को संशोधित कि हो जाएगा बदलने के लिए गति प्रदान करने के लिए है : fetchData, setError, setLoading, आदि

क्या मुझे लगता है कि कार्रवाई और reducers कोड के गतिशील या स्थिर प्रेषण की एक decoupling हैं, इसलिए बजाय myStateContainer.doSomethingAndUpdateState(...) आप actions.doSomethingAndUpdateState(...) फोन पर कॉल करने की है, और आप पूरे प्रवाह करते है/redux मशीनरी उस कार्रवाई को राज्य के वास्तविक संशोधन के लिए जोड़ती है। यह पूरी बात केवल नियमित जावास्क्रिप्ट नियंत्रण प्रवाह का उपयोग करने के बजाय, अधिक जटिल कार्रवाइयों को संभालने के लिए थंक्स, सागा और अन्य मिडलवेयर की आवश्यकता को भी लाती है। कार्य प्रकारों - - कार्रवाई पेलोड - - कार्रवाई निर्माता कार्य (तर्क) के इंटरफेस के आकार :

मुख्य समस्या यह है कि इस decoupling सामान का एक बहुत लिखने के लिए आवश्यक है कि आप सिर्फ इतना है कि decoupling प्राप्त करने के लिए है अपने राज्य - कैसे आप अपने राज्य को अद्यतन

हमारे सैद्धांतिक राज्य कंटेनर (टीएससी) के लिए इस की तुलना करें: - अपने तरीकों के इंटरफेस - अपने राज्य के आकार - कैसे आप अपने राज्य को अद्यतन

तो मैं यहाँ क्या याद कर रहा हूँ? इस decoupling के क्या फायदे हैं?

यह बहुत ही इस अन्य सवाल के समान है: Redux actions/reducers vs. directly setting state

और क्यों उस प्रश्न का सबसे मतदान जवाब उत्तर नहीं मिलता है मुझे समझाती हूँ या तो मेरी या मूल प्रश्न: - क्रिया/कम करने वाली आप प्रश्न पूछ जाने कौन और कैसे? यह हमारे टीएससी के साथ किया जा सकता है, यह सिर्फ एक कार्यान्वयन विस्तार है और उसके पास कार्यों/reducers खुद के साथ कुछ भी नहीं है। - क्रियाएं/Reducers आपको अपने राज्य के साथ समय पर वापस जाने देते हैं: फिर यह राज्य कंटेनर के कार्यान्वयन विवरण का मामला है और हमारे टीएससी के साथ प्राप्त किया जा सकता है। - आदि: राज्य परिवर्तन आदेश, मिडलवेयर, और जो कुछ भी वर्तमान में कार्यों/reducers के साथ हासिल किया जाता है हमारे टीएससी के साथ हासिल किया जा सकता है, यह सिर्फ इसके कार्यान्वयन का मामला है।

बहुत बहुत धन्यवाद! फ़्रैन

Answer 1

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

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

एक और कारण कोड में डेटा प्रवाह को केवल एक दिशा में होने के लिए बाध्य करना है। अगर हम मनमाने ढंग से अपरिवर्तित राज्य संशोधनों की अनुमति देते हैं, तो हमें राज्य में परिवर्तन हो सकते हैं जिससे राज्य परिवर्तन में अधिक परिवर्तन हो सकता है ... यही कारण है कि यह एक reducer में कार्यों को प्रेषित करने के लिए एक विरोधी पैटर्न है। हम जानना चाहते हैं कि कार्यों के कैस्केड बनाने के बजाय प्रत्येक कार्य कहां से आ रहा है।

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

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

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