रेडक्स - राज्य एक ही स्थान पर क्यों है, यहां तक ​​कि राज्य भी वैश्विक नहीं है?

Question

मैं प्रतिक्रिया करने के लिए नया हूं और रेडक्स के लिए भी नया हूं। अब तक, एक छोटे से sandbox आवेदन के लिए दोनों एक साथ इस्तेमाल किया, मुझे उन्हें पसंद है।

जब यह एक बड़े एप्लिकेशन की बात आती है, हालांकि, मुझे इसके बारे में आश्चर्यचकित होना शुरू हो रहा है: रेडक्स आपके पूरे एप्लिकेशन स्थिति को एक ही स्टोर में क्यों रखता है?

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

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

क्या मेरे पास रूट पर वैश्विक रूप से प्रभावित राज्य नहीं हो सकता है, और राज्य अपने घटकों में प्रत्येक घटक के लिए विशिष्ट है? मैं सभी घटक-विशिष्ट राज्य को श्रृंखला को वैश्विक स्थिति के लिए सभी तरह से फेंकने के बारे में चिंतित हूं (विशेष रूप से जब प्रतिक्रिया शीर्ष-प्रवाह प्रवाह पर जोर देती है)।

Answer 1

उपयोगकर्ता-इंटरफ़ेस एप्लिकेशन के लिए वैश्विक स्थिति का प्राथमिक लाभ यह है कि आप संपूर्ण एप्लिकेशन के राज्य परिवर्तनों को ट्रैक कर सकते हैं।

tldr; आप हमेशा ऐप की स्थिति को आसानी से सहेज सकते हैं और भविष्यवाणी कर सकते हैं क्योंकि सच्चाई का एक स्रोत है।

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

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

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

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

रेडक्स में अलगाव-संबंधी-चिंताओं का पृथक्करण reducer है क्योंकि आप एकाधिक reducers बना सकते हैं और स्टोर अपडेट के लिए तर्क-श्रृंखला बनाने के लिए उन्हें गठबंधन कर सकते हैं।

reducers के साथ, आप अभी भी अपने राज्य तर्क को कोड में "अलग" कर रहे हैं, लेकिन वास्तव में इसे चलते समय सभी को एक पेड़ के रूप में माना जा रहा है। यह आपके राज्य को अनुमानित और परमाणु बदलता रहता है, लेकिन अच्छे संगठन, encapsulation और चिंताओं को अलग करने की अनुमति देता है।

Answer 2

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

क्योंकि यह हमारे समग्र आवेदन स्थिति को क्वेरी, डीबग और क्रमबद्ध करने में बहुत आसान बनाता है।

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

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

मैं इस अवधारणा पाया बहुत आसान जानने के लिए और ClojureScript के Re-frame से निपटने और डेविड Nolen के videos on Om Next देख जबकि समझने के लिए। परियोजना के लिए Re-frame README भी एक महान शिक्षण संसाधन है।

यहां मेरे कुछ निजी अधिग्रहण हैं कि क्यों वैश्विक राज्य एक अधिक सुरुचिपूर्ण समाधान है।

सरल अवयव

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

उदाहरण के लिए

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

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

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

शुद्ध कार्य

आपके आवेदन राज्य एक ही स्थान में रहता है, घटक है कि प्रस्तुत करना यह शुद्ध कार्यों कि एक तर्क के रूप में राज्य ले जा सकता है। वे सिर्फ डेटा देखते हैं, और एक ऐसा दृश्य वापस करते हैं जो अद्यतन करने के लिए क्रियाएं प्रेषित कर सकता है।

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

क्रमबद्धता

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

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

वैश्विक स्थिति के साथ, आप बस इसे ठीक से एन्कोड और डीकोड कर सकते हैं।

पूर्ववत करें/फिर

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

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

कार्रवाई प्लेबैक

Redux में (और सामान्य रूप में फ्लक्स पैटर्न) हम कार्रवाई खेला गया है कि का ट्रैक रख सकते तो ठीक उसी राज्य का निर्माण करने के लिए एक और संदर्भ में वापस उन्हें खेलने,।

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