क्या रेडक्स को पब/उप या पर्यवेक्षक पैटर्न के रूप में देखा जा सकता है?

Question

मैं सिर्फ अपने सिर को रिएक्ट.जेएस के आसपास लाने की कोशिश कर रहा हूं, कहा जा रहा है, मैंने अभी वेब पर कुछ ट्यूटोरियल समाप्त किए हैं।

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

रेडक्स के साथ हम अब पूरे आवेदन राज्य को वैश्विक बनाने की कोशिश करते हैं और हमें क्रियाओं को परिभाषित करने के लिए क्रियाओं को परिभाषित करना है (वैश्विक) राज्य, तो "सामान्य" जावास्क्रिप्ट पब/उप या पर्यवेक्षक पैटर्न के अलावा ये क्रियाएं क्या हैं? या शायद मुझे यह गलत हो रहा है? - स्पष्टीकरण की अत्यधिक सराहना की जाएगी।

Answer 1

रेडक्स को "प्रतिक्रिया.जेएस के प्रारंभिक विचार को प्रतिस्थापित नहीं करना" माना जाता है, इसके बारे में सोचें कि लाइब्रेरी की तरह साझा करने के लिए घटकों के बीच प्रबंधित स्थिति और राज्य उत्परिवर्तनों को समन्वयित करना है। रेडक्स वास्तव में एक पब/उप पैटर्न का उपयोग करता है, यहां स्टोर विधियों को देखें: http://redux.js.org/docs/api/Store.html#store-methods आपको subscribe विधि मिल जाएगी जो घटकों द्वारा राज्य के पेड़ में बदलावों की सदस्यता लेने के लिए उपयोग की जाती है। आम तौर पर आप redux-react bindings (Redux connect मूल रूप से) के रूप में, store.s सदस्यता का सीधे उपयोग नहीं करते हैं। आप यहां वास्तविक कार्यान्वयन की जांच कर सकते हैं, यह वास्तव में जटिल नहीं है (वास्तव में मेरे लिए अन्य फ्लक्स कार्यान्वयन पर रेडक्स का मुख्य लाभ है): https://github.com/reactjs/react-redux/blob/master/src/components/connect.js#L199

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

यह भी विचार करें कि रेडक्स के साथ घटक आंतरिक स्थिति का उपयोग करना जारी रखना बिल्कुल ठीक है। आप उस राज्य को स्टोर करने के लिए आंतरिक स्थिति का उपयोग कर सकते हैं जिसकी आपको आवश्यकता नहीं है/अन्य घटकों के साथ साझा करना चाहते हैं।

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

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

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

इस अर्थ में, एक reducer एक ऐसा कार्य है जो क्रियाओं को संसाधित करता है और आवश्यकतानुसार राज्य को अद्यतन करता है।

बदले में, जब एक रेड्यूसर राज्य की एक नई प्रतिलिपि लौटाकर राज्य को अद्यतन करता है, जुड़े घटक (राज्य में परिवर्तनों की सदस्यता लेते हैं) नए प्रोप पारित किए जाएंगे और परिवर्तनों को दर्शाने के लिए फिर से प्रस्तुत करेंगे।

कभी-कभी, केवल सादे जेएस ऑब्जेक्ट्स को प्रेषित करना पर्याप्त नहीं है और आपको अधिक नियंत्रण की आवश्यकता है। जब आपको अधिक जटिल तर्क करने की आवश्यकता होती है तो यह स्पष्ट हो जाता है, उदाहरण के लिए जब आपको AJAX कॉल से प्रतिक्रिया के आधार पर राज्य में काउंटर अपडेट करने की आवश्यकता होती है।

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

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

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

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

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

Answer 2

Fabios दो बार जवाब देने वोट दें नहीं कर सकता और टिप्पणी अनुभाग छोटे के लिए है:

मेरे विचार में यह एक सम्मेलन के साथ एक पब/उप तरह है में हां।

यह बताते हुए कि प्रोप को कैसे गुजरना दर्द हो सकता है, यहां एक उदाहरण दिया गया है।

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