दिलचस्प दृष्टिकोण! ऐसा लगता है कि इसे आदर्श रूप से एसिंक्रोनस की प्रकृति से अलग किया जाना चाहिए, जैसे एक्सएचआर को चलाने के लिए इस्तेमाल की जाने वाली विधि, या यहां तक ​​​​कि वेब अनुरोध पहली जगह में एसिंक्रोनी का स्रोत है।

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

एक्शन क्रिएटर्स में साइड-इफेक्ट्स की समस्या

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

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

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

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

निहित अवस्था छिपी हुई है

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

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

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

राज्य को उस बिंदु पर रिवाइंड करना जहां प्रभाव के पूरा होने के बाद वृद्धि के संचालन को प्रगति के रूप में चिह्नित किया जाता है, वास्तव में साइड इफेक्ट को पुन: उत्पन्न नहीं करेगा और इस प्रकार अनिश्चित काल तक प्रगति पर रहेगा।

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

व्यापार तर्क का दोहराव

क्रियाओं का साइड इफेक्ट तभी उत्पन्न होना स्वाभाविक है जब आवेदन एक विशिष्ट स्थिति में हो। Redux में यदि किसी क्रिया निर्माता को राज्य की आवश्यकता होती है तो यह एक सरल और शुद्ध कार्य होना चाहिए या स्पष्ट रूप से राज्य के साथ प्रदान किया जाना चाहिए।

एक साधारण उदाहरण के रूप में, मान लें कि हम उदाहरण काउंटर एप्लिकेशन से शुरू करते हैं और हम काउंटर को हर बार एक यादृच्छिक फ़ॉन्ट रंग में बदलना चाहते हैं जब काउंटर 5 का गुणक हो।

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

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

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

संदर्भ धारणाएं और/या निर्भरताएं पुन: प्रयोज्यता को कम करती हैं

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

रेड्यूसर और कंपोनेंट एन्हांसर के रूप में जेनेरिक सूची कैसे बनाएं, इससे पहले इस पर चर्चा की जा चुकी है

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

इस मामले में माता-पिता किसी भी आवश्यक संदर्भ के साथ संदेश को बढ़ाने के लिए केवल एक्शन क्रिएटर्स या डिस्पैचर को लपेटता है, फिर वह स्थानीय स्थिति के साथ सीधे रेड्यूसर को कॉल कर सकता है।

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

IncrementIfOdd वर्तमान स्थिति को निर्धारित करने के लिए मिडलवेयर पर निर्भर करता है और इस प्रकार एप्लिकेशन स्थिति के भीतर इसके स्थान को जानने की आवश्यकता होती है।

IncrementAsync अंततः सीधे एक वृद्धिशील क्रिया भेजता है जो मूल घटक के संपर्क में नहीं है और इस प्रकार अतिरिक्त संदर्भ के साथ लपेटा नहीं जा सकता है।

जबकि आपका प्रस्ताव सीधे इस समस्या का समाधान नहीं करता है, अगर वृद्धिएसिंक को एक साधारण क्रिया के रूप में लागू किया गया था जिसने स्टोर श्रोता में साइड इफेक्ट को ट्रिगर करने के लिए राज्य को {counter: 0, incrementAfterDelay: 1000} बदल दिया था, तो इंक्रीमेंटएसिंक एक सरल संदेश बन जाता है। IncrementIfOdd शुद्ध है इसलिए इसे या तो रेड्यूसर में लागू किया जा सकता है या स्पष्ट रूप से राज्य प्रदान किया जा सकता है .... इस प्रकार वांछित होने पर एल्म आर्किटेक्चर को फिर से लागू करना संभव हो जाता है।

साइड इफेक्ट वाले एक्शन क्रिएटर्स का परीक्षण करना मुश्किल है

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

आपका प्रस्ताव किसी को आसानी से एक परीक्षण लिखने में सक्षम बनाता है कि एक राज्य संक्रमण वास्तव में उनमें से किसी को भी निष्पादित किए बिना वांछित प्रतिक्रियाओं वाला एक राज्य बनाएगा। प्रतिक्रियाओं का परीक्षण करना भी आसान होता है क्योंकि उन्हें किसी सशर्त स्थिति या व्यावसायिक तर्क की आवश्यकता नहीं होती है।

अनुकूलित या बैच नहीं किया जा सकता

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

FP . के लिए एक आधुनिक वास्तुकला

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

आपका प्रस्ताव fetchPostsIfNeeded समाप्त कर देता है और reactions फ़ंक्शन को लागू करना पूरी तरह से व्यवहार्य लगता है जो कई अनुरोधों को अनुकूलित कर सकता है और/या कम या ज्यादा डेटा का अनुरोध किए जाने पर आवश्यकतानुसार एपीआई के विभिन्न सेट का उपयोग कर सकता है।

मेरा कार्यान्वयन

मैंने हाल ही में रेडक्स का एक

मुझे यकीन नहीं था कि रेडक्स को फोर्क किए बिना इसे कैसे किया जाए क्योंकि मौजूदा रेड्यूसर कोड के साथ संगतता बनाए रखने के लिए मौजूदा रेड्यूसर पर प्रभाव उठाने के लिए कंपोज़ और कॉम्बिनेशन रेड्यूसर को संशोधित करना आवश्यक था।

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

सारांश

रिएक्ट की तरह "सिर्फ ui" है, और यह बहुत ही निर्देशात्मक नहीं है कि कोई वास्तव में एप्लिकेशन स्थिति को कैसे संग्रहीत या अपडेट करता है, Redux ज्यादातर "सिर्फ स्टोर" है और यह इस बारे में बहुत निर्देशात्मक नहीं है कि कोई साइड इफेक्ट को कैसे संभालता है।

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

रेडक्स कमाल का है। ये Redux के साथ ही आवश्यक मुद्दे नहीं हैं, लेकिन उम्मीद है कि मौजूदा वास्तुशिल्प पैटर्न की रचनात्मक आलोचनाएं और राज्य संशोधनों से पहले प्रभाव चलाने के लिए प्रेरणा और संभावित लाभ।

मैं इस दृष्टिकोण और redux-saga के बीच के अंतर को समझने की कोशिश कर रहा हूँ। मुझे इस दावे में दिलचस्पी है कि यह जेनरेटर में राज्य को निहित रूप से छुपाता है, क्योंकि पहले ऐसा लगता है कि यह वही काम कर रहा है। लेकिन मुझे लगता है कि यह इस बात पर निर्भर करता है कि io.take कैसे लागू किया जाता है। यदि गाथा केवल एक कार्रवाई को संसाधित करेगी यदि वह वर्तमान में उस yield पर अवरुद्ध हो जाती है, तो मैं निश्चित रूप से आपका मतलब देखता हूं। लेकिन अगर redux-saga ऐसे कार्यों को कतारबद्ध करता है जैसे io.take पिछले कार्यों को वापस कर देगा, ऐसा लगता है कि यह वही काम कर रहा है। किसी भी तरह से, आपके पास कुछ तर्क हैं जो dispatch क्रियाओं को एसिंक्रोनस रूप से कर सकते हैं, एक्शन स्ट्रीम को सुनकर ट्रिगर किया जा सकता है।

हालांकि ये एक रुचिकर विचार है। Redux को एक एक्शन स्ट्रीम के रूप में अवधारणा देना, जिससे राज्य के संक्रमण और प्रभाव शुरू हो जाते हैं। यह मुझे केवल एक राज्य प्रोसेसर मानने के बजाय एक वैकल्पिक दृष्टिकोण प्रतीत होता है।

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

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

स्टोर हिजिंक वर्णित https://github.com/rackt/redux/issues/1200

मैं इस दृष्टिकोण और redux-saga . के बीच अंतर को समझने की कोशिश कर रहा हूँ

जब तक मैं अपने दृष्टिकोण के साथ नहीं आया, तब तक मैंने redux-saga नहीं देखा, लेकिन निश्चित रूप से कुछ समानताएँ हैं। लेकिन मुझे अभी भी कुछ अंतर हैं:

1. मेरे दृष्टिकोण में केवल राज्य के लिए एक्शन स्ट्रीम तक पहुंच नहीं है। redux-saga प्रक्रिया को केवल इसलिए शुरू कर सकता है क्योंकि एक क्रिया थी। मेरे दृष्टिकोण की आवश्यकता है कि एक रेड्यूसर उस राज्य में बदलाव करे जो कार्रवाई का अनुरोध करने के लिए प्रतिक्रिया कार्य को ट्रिगर करता है।
2. मेरे दृष्टिकोण के लिए सभी राज्यों को redux के राज्य में मौजूद होने की आवश्यकता है। Redux-saga में अतिरिक्त स्थिति है जो सागा जनरेटर में रहती है (यह किस लाइन पर है, स्थानीय चर के मान)।
3. मेरा दृष्टिकोण अतुल्यकालिक भाग को अलग करता है। प्रतिक्रिया के वास्तविक तर्क को अतुल्यकालिक कार्यक्षमता से निपटने के बिना परीक्षण किया जा सकता है। गाथा इन्हें एक साथ रखती है।
4. गाथा एक ही तर्क के विभिन्न अंशों को एक साथ लाती है। मेरा दृष्टिकोण आपको एक गाथा को उन हिस्सों में विभाजित करने के लिए मजबूर करता है जो रेड्यूसर, प्रतिक्रियाओं और प्रतिक्रिया प्रकार के कार्यान्वयन से संबंधित हैं।

मूल रूप से, मेरा दृष्टिकोण शुद्ध कार्यों पर जोर देता है और सब कुछ रेडक्स स्थिति में रखता है। Redux-saga दृष्टिकोण अधिक अभिव्यंजक होने पर जोर देता है। मुझे लगता है कि पेशेवरों और विपक्ष हैं, लेकिन मुझे मेरा बेहतर पसंद है। लेकिन मैं पक्षपाती हूं।

यह वास्तव में आशाजनक लगता है। मुझे लगता है कि यह एक उदाहरण देखने के लिए और अधिक सम्मोहक होगा जो डोमेन तर्क से प्रतिक्रिया तंत्र को अलग करता है।

आपका प्रस्ताव fetchPostsIfNeeded को समाप्त कर देता है और यह एक प्रतिक्रिया फ़ंक्शन को लागू करने के लिए पूरी तरह से व्यवहार्य लगता है जो कई अनुरोधों को अनुकूलित कर सकता है और/या आवश्यकतानुसार एपीआई के विभिन्न सेट का उपयोग कर सकता है जब कम या ज्यादा डेटा का अनुरोध किया गया हो।

जैसा कि यह खड़ा है, आप वास्तव में प्रतिक्रिया समारोह में ऐसा नहीं कर सके। वहां के तर्क को यह जानने की आवश्यकता होगी कि कौन सी क्रियाएं पहले ही शुरू हो चुकी हैं (हम उनमें कुछ और बैच नहीं कर सकते हैं), लेकिन प्रतिक्रिया फ़ंक्शन में जानकारी नहीं है। प्रतिक्रियाओं () फ़ंक्शन का उपभोग करने वाली प्रतिक्रिया मशीनरी निश्चित रूप से उन चीजों को कर सकती है।

मुझे लगता है कि यह एक उदाहरण देखने के लिए और अधिक सम्मोहक होगा जो डोमेन तर्क से प्रतिक्रिया तंत्र को अलग करता है।

मुझे लगता है कि आपका मतलब है जिस तरह से doReactions() फ़ंक्शन XMLHttpRequest के प्रारंभ/रोक को संभालता है? मैं ऐसा करने के विभिन्न तरीकों की खोज कर रहा हूं। समस्या यह है कि यह पता लगाने का एक सामान्य तरीका खोजना मुश्किल है कि क्या दो प्रतिक्रियाएं वास्तव में एक ही प्रतिक्रिया हैं। लोदाश का isEqual लगभग काम करता है, लेकिन बंद होने में विफल रहता है।

मुझे लगता है कि आपका मतलब है जिस तरह से doReactions() फ़ंक्शन XMLHttpRequest के प्रारंभ/रोक को संभालता है?

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

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

हम्म... मुझे लगता है कि डोमेन लॉजिक से हमारा मतलब एक ही बात नहीं हो सकता है।

जिस तरह से मैं इसे देखता हूं, प्रतिक्रियाएं() फ़ंक्शन डोमेन तर्क को समाहित करता है, और doReactions() फ़ंक्शन से अलग होता है जो प्रतिक्रियाओं को लागू करने के तर्क को संभालता है। लेकिन ऐसा लगता है कि आपका मतलब कुछ अलग है ...

जैसा कि यह खड़ा है, आप वास्तव में प्रतिक्रिया समारोह में ऐसा नहीं कर सके। वहां के तर्क को यह जानने की आवश्यकता होगी कि कौन सी क्रियाएं पहले ही शुरू हो चुकी हैं (हम उनमें कुछ और बैच नहीं कर सकते हैं), लेकिन प्रतिक्रिया फ़ंक्शन में जानकारी नहीं है। प्रतिक्रियाओं () फ़ंक्शन का उपभोग करने वाली प्रतिक्रिया मशीनरी निश्चित रूप से उन चीजों को कर सकती है।

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

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

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

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

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

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

हम्म... मुझे लगता है कि डोमेन लॉजिक से हमारा मतलब एक ही बात नहीं हो सकता है।

जिस तरह से मैं इसे देखता हूं, प्रतिक्रियाएं() फ़ंक्शन डोमेन तर्क को समाहित करता है, और doReactions() फ़ंक्शन से अलग होता है जो प्रतिक्रियाओं को लागू करने के तर्क को संभालता है। लेकिन ऐसा लगता है कि आपका मतलब कुछ अलग है ...

मैंने पूरे /reactions/index मॉड्यूल को समग्र रूप से लिया, लेकिन हाँ, मैं सहमत हूँ कि reactions फ़ंक्शन विशुद्ध रूप से डोमेन लॉजिक है। लेकिन डोमेन-विशिष्ट मॉड्यूल में होने के बजाय, यह doReactions के बॉयलरप्लेट के साथ लिपटा हुआ है। यह आपकी कार्यप्रणाली को दस्तक देने के लिए नहीं है, यह सिर्फ एक नज़र में लाइब्रेरी कोड और ऐप कोड के बीच के अंतर को समझना कठिन बनाता है।

तब doReactions ही मुझे लगता है कि एपीआई से डेटा लाने वाले विशेष अधिनियम की एक विशेष विधि के साथ कसकर जुड़ा हुआ है। मुझे लगता है कि एक फ़्लेशेड आउट प्रतिक्रिया पुस्तकालय विभिन्न प्रकार के प्रभावों के लिए हैंडलर पंजीकृत करने का एक तरीका हो सकता है।

यह आपके तरीके को खटखटाने के लिए नहीं है; मुझे यह दृष्टिकोण वास्तव में आकर्षक लगता है।

मुझे यकीन नहीं है कि प्रतिक्रिया घटक राज्य एक अच्छा सादृश्य है क्योंकि अधिकांश प्रतिक्रिया राज्य है
ऐप स्थिति में होना चाहिए, लेकिन जाहिर तौर पर कुछ रास्ता होना चाहिए
प्रेषण घटनाओं के बीच स्थिति को बनाए रखने के लिए जिसे में नहीं रखा जा सकता है
दुकान।

मुझे लगता है कि इस तरह के राज्य को @yelouafi नियंत्रण राज्य के रूप में संदर्भित करता है और
शायद सागा गैर-क्रमिक स्थिति को मॉडल करने का एक अच्छा तरीका है
एक स्वतंत्र पर्यवेक्षक/अभिनेता के रूप में प्रणाली।

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

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

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

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

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/rackt/redux/issues/1182#issuecomment -168858051।

यह आपकी कार्यप्रणाली को दस्तक देने के लिए नहीं है, यह सिर्फ एक नज़र में लाइब्रेरी कोड और ऐप कोड के बीच के अंतर को समझना कठिन बनाता है।

यह पूरी तरह से उचित है।

फिर doReactions मुझे लगता है कि एपीआई से डेटा प्राप्त करने वाले विशेष अधिनियम की एक विशेष विधि के साथ कसकर जुड़ा हुआ है। मुझे लगता है कि एक फ़्लेशेड आउट प्रतिक्रिया पुस्तकालय विभिन्न प्रकार के प्रभावों के लिए हैंडलर पंजीकृत करने का एक तरीका हो सकता है।

हां। मैं अभी भी यह पता लगाने की कोशिश कर रहा हूं कि इसे अलग करने का सबसे अच्छा तरीका क्या है। यह समानता जाँच के मुद्दे से जटिल है।

मुझे यकीन नहीं है कि प्रतिक्रिया घटक राज्य एक अच्छा सादृश्य है क्योंकि अधिकांश प्रतिक्रिया राज्य है
ऐप स्थिति में होना चाहिए, लेकिन जाहिर तौर पर कुछ रास्ता होना चाहिए
प्रेषण घटनाओं के बीच स्थिति को बनाए रखने के लिए जिसे में नहीं रखा जा सकता है
दुकान।

क्षमा करें, मुझे लगता है कि मैंने सादृश्य को गड़बड़ कर दिया है। मेरा मुद्दा बाहरी क्रिया राज्य की तुलना घटक स्थिति पर प्रतिक्रिया करने के लिए नहीं है जितना कि डीओएम की स्थिति। अंतराल या XMLHttpRequest बल्कि DOM तत्वों की तरह हैं जो प्रतिक्रिया करते हैं और नष्ट करते हैं। आप बस प्रतिक्रिया बताएं कि वर्तमान डोम क्या होना चाहिए और इसे होने दें। इसी तरह, आप बस वर्तमान बाहरी प्रतिक्रियाओं के सेट को वापस कर देते हैं, और ढांचा इसे रद्द कर देता है या इसे सच करने के लिए कार्रवाई शुरू कर देता है।

मुझे वह दृष्टिकोण भी वास्तव में दिलचस्प लगता है। क्या आपने कई doReactions का उपयोग करने पर विचार किया है, जो अलग-अलग राज्य मैपिंग लेते हैं? मुझे लगता है कि यह साइकिल के समान होगा, जहां आप पुन: प्रयोज्य ड्राइवर बना सकते हैं:

function main(action$) {
  const state$ = action$.startWith(INITIAL_STATE).scan(reducer);

  return { 
    DOM: state$.map(describeDOM),
    HTTP: state$.map(describeRequests),
    ...
  };
}

एक अंतर यह है कि आप एक्शन स्ट्रीम ( const someEvent$ = sources.DOM.select('.class').events('click') ) प्राप्त करने के लिए घटनाओं के लिए ड्राइवरों से पूछताछ नहीं करते हैं, लेकिन सीधे सिंक में क्रियाओं को निर्दिष्ट करें ( <button onClick={() => dispatch(action())} /> ) जैसे आपने HTTP अनुरोधों के लिए किया है भी।

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

यहाँ एपीआई के लिए एक विचार है (प्रतिक्रिया का उपयोग करके; HTTP को इस तरह भी बनाया जा सकता है):

// usage
const describe = (state, dispatch) => <MyComponent state={state} dispatch={dispatch} />;
const driver = createReactDOMDriver({ container } /* opts */);
store.subscribe(() => driver.update(describe(store.getState(), store.dispatch)); 
// (could be simplified further to eg. `store.use(driver, describe)` )

// implementation
const createReactDOMDriver = ({ container }) => {
  return {
    update: (element) => ReactDOM.render(element, container),
    destroy: () => ReactDOM.unmountComponentAtNode(container),
  };
};

मेरे पास describe होगा getState (राज्य स्नैपशॉट के बजाय) और dispatch । इस तरह, यह उतना ही एसिंक्स हो सकता है जितना वह बनना चाहता है।

क्या आपने कई doReactions का उपयोग करने पर विचार किया है, जो अलग-अलग राज्य मैपिंग लेते हैं?

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

मेरे पास गेटस्टेट (राज्य स्नैपशॉट के बजाए) और प्रेषण का वर्णन होगा। इस तरह, यह उतना ही एसिंक्स हो सकता है जितना वह बनना चाहता है।

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

निष्पक्ष बिंदु। मैंने आपके विचार और @taurose के उदाहरण के बीच मानचित्रण के बारे में सोचा नहीं है। मैंने जल्दबाजी में मान लिया कि describe reactions फ़ंक्शन था, लेकिन यह सच नहीं हो सकता है।

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

मेरे पास गेटस्टेट (राज्य स्नैपशॉट के बजाए) और प्रेषण का वर्णन होगा। इस तरह, यह उतना ही एसिंक्स हो सकता है जितना वह बनना चाहता है।

describe प्रत्येक राज्य परिवर्तन पर कॉल किया जाता है, इसलिए मुझे इसकी आवश्यकता नहीं दिख रही है। इसका मतलब यह नहीं है कि यह async नहीं कर सकता। प्रतिक्रिया घटकों पर विचार करें: आप वर्तमान स्थिति प्राप्त करने के लिए अपने रेंडर विधियों या ईवेंट हैंडलर के अंदर getState को कॉल नहीं करेंगे, बल्कि इसे प्रॉप्स से पढ़ेंगे।

लेकिन आप सही कह रहे हैं कि यह एसिंक्स अपने आप कुछ भी नहीं कर सकता (नहीं करना चाहिए); इसे ड्राइवर को छोड़ देना चाहिए और बस इसे कुछ मैप किए गए राज्य और/या कॉलबैक पास करना चाहिए।

माना गया वर्णन प्रतिक्रिया कार्य था, लेकिन यह सच नहीं हो सकता है।

जहाँ तक मैं बता सकता हूँ, यह काफी हद तक समान है। एक अंतर यह होगा कि reactions को dispatch नहीं मिलता है। इसलिए जब describe कार्रवाई बनाने और भेजने वाले कॉलबैक लौटाता है, तो reactions कार्रवाई निर्माता देता है।

@winstonewert यह एक लंबा धागा है और मेरे पास अभी पढ़ने या अपना कोड जांचने का समय नहीं है लेकिन शायद @yelouafi आपको जवाब दे सकता है।

Redux-saga परियोजना यहाँ लंबी चर्चाओं से उत्पन्न हुई

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

• http://stackoverflow.com/a/33829400/82609
• http://stackoverflow.com/a/33501899/82609

यहां कार्यान्वयन सही से बहुत दूर है लेकिन यह सिर्फ एक विचार देता है।

@yelouafi उन जनरेटर का उपयोग करने के लिए निहित मुद्दों से अवगत है जो रेडक्स के बाहर राज्य को छुपाते हैं, और बैकएंड पर एक गाथा शुरू करना जटिल है, और उस छिपे हुए राज्य को सार्वभौमिक ऐप्स के लिए फ्रंटएंड पर प्रेषित करना (यदि वास्तव में आवश्यक है?)

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

मैं जनरेटर के अंदर छिपी स्थिति के बारे में आपकी बात समझता हूं। लेकिन क्या वास्तव में Redux एक Redux ऐप की सच्चाई का

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

मुझे आशा है कि मैं जो कुछ भी कह रहा हूं वह redux-saga पर हमले के रूप में सामने नहीं आया है। मैं बस इस बारे में बात कर रहा था कि मैं जिस दृष्टिकोण के साथ आया हूं उससे अलग कैसे है।

मैं जनरेटर के अंदर छिपी स्थिति के बारे में आपकी बात समझता हूं। लेकिन क्या वास्तव में Redux एक Redux ऐप की सच्चाई का असली स्रोत स्टोर करता है? मुझे ऐसा नहीं लगता। Redux क्रियाओं को रिकॉर्ड करता है, और उन्हें फिर से चलाता है। स्टोर को फिर से बनाने के लिए आप इन क्रियाओं को कभी भी फिर से चला सकते हैं। Redux स्टोर इवेंट लॉग के CQRS क्वेरी व्यू की तरह है। इसका मतलब यह नहीं है कि उस इवेंट लॉग का केवल एक प्रक्षेपण होना चाहिए। आप एक ही इवेंट लॉग को अलग-अलग क्वेरी व्यू में प्रोजेक्ट कर सकते हैं, और उनके लिए सागा में सुन सकते हैं जो जनरेटर, ग्लोबल म्यूटेबल ऑब्जेक्ट्स या रेड्यूसर के साथ अपने राज्य का प्रबंधन कर सकते हैं, जो भी तकनीक हो।

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

जहाँ तक मैं बता सकता हूँ, यह काफी हद तक समान है। एक अंतर यह होगा कि प्रतिक्रियाओं को प्रेषण नहीं मिलता है। इसलिए रिटर्न कॉलबैक का वर्णन करते समय जो कार्रवाई बनाते हैं और भेजते हैं, प्रतिक्रियाएं कार्रवाई निर्माता लौटाती हैं।

माना। सिद्धांत रूप में, प्रतिक्रिया एक ही इंटरफ़ेस का उपयोग कर सकती है, सभी ईवेंट हैंडलर एक एक्शन क्रिएटर लेंगे जो ईवेंट के निकाल दिए जाने पर भेज दिया जाएगा।

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

doReactions को एक गाथा से बदला जा सकता है और सागाओं के लिए घटना स्रोत प्रतिक्रियाएँ होनी चाहिए न कि क्रियाएँ।

मुझे आशा है कि मैं जो कुछ भी कह रहा हूं वह redux-saga पर हमले के रूप में सामने नहीं आया है

बिल्कुल नहीं। मैं चर्चा का अनुसरण कर रहा हूं, लेकिन आपके कोड को अधिक बारीकी से देखे बिना टिप्पणी नहीं करना चाहता।

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

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

इसका मतलब है कि आपको स्टोर में और भी अधिक नियंत्रण स्थिति स्टोर करनी होगी (जहां केवल ऐप स्थिति में परिवर्तन प्रासंगिक प्रतिक्रियाओं का अनुमान लगाने के लिए अपर्याप्त हैं)

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

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

मैं अभी नहीं देख रहा हूँ कि तुम क्या हो।

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

मैं सहमत हूँ। यदि आप एक जटिल स्टेट-मशीन को हाथ से लिख रहे हैं तो हमें एक समस्या है। (वास्तव में यह साफ-सुथरा होगा यदि हम एक जनरेटर को एक रेड्यूसर में बदल सकते हैं)।

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

मुझे यकीन नहीं है कि आप यहां क्या सोच रहे हैं। मैं अलग-अलग ड्राइवरों को अलग-अलग उपयोगी चीजें करते हुए देख सकता हूं, लेकिन नियंत्रण स्थिति को खत्म कर सकता हूं?

@winstonewert नहीं, मैं हमले के रूप में कुछ भी नहीं ले रहा हूँ। मेरे पास वास्तव में आपके कोड को देखने का समय भी नहीं था :)

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

नहीं, मैं नहीं हूं, रेडक्स स्टोर एक प्रक्षेपण है, लेकिन गाथा एक सादा पुराना सरल श्रोता है।

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

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

इसके माध्यम से एक अंतर यह है कि बैकएंड सिस्टम में, गाथा अक्सर वास्तव में इवेंट लॉग का एक प्रक्षेपण होता है: अपनी स्थिति को बदलने के लिए, इसे घटनाओं को छोड़ना होगा और उन्हें स्वयं सुनना होगा। Redux-saga में जैसा कि वर्तमान में इसे लागू किया गया है, गाथा स्थिति को पुनर्स्थापित करने के लिए ईवेंट लॉग को फिर से चलाना कठिन होगा।

मुझे यकीन नहीं है कि आप यहां क्या सोच रहे हैं। मैं अलग-अलग ड्राइवरों को अलग-अलग उपयोगी चीजें करते हुए देख सकता हूं, लेकिन नियंत्रण स्थिति को खत्म कर सकता हूं?

नहीं, इसे समाप्त नहीं कर रहा है, अधिकांश उद्देश्यों के लिए इसे केवल एक अंडर-द-हूड कार्यान्वयन चिंता बना रहा है।

मुझे ऐसा लगता है कि Redux समुदाय में वास्तव में मजबूत सहमति है कि स्टोर में डोमेन स्थिति को संग्रहीत करना एक बड़ी जीत है (अन्यथा, आप Redux का उपयोग क्यों करेंगे?) कुछ हद तक कम आम सहमति है कि यूआई राज्य को संग्रहित करना एक जीत है, क्योंकि इसे घटकों में समझाया गया है। फिर स्टोर में ब्राउज़र स्थिति को सिंक करने का विचार है, जैसे यूआरएल (रेडक्स-सिंपल-राउटर) या फॉर्म डेटा। लेकिन यह स्टोर में लंबे समय से चल रही प्रक्रिया की स्थिति/चरण को संग्रहीत करने की अंतिम सीमा प्रतीत होती है।

क्षमा करें यदि यह एक स्पर्शरेखा है, लेकिन मुझे लगता है कि अच्छी डेवलपर उपयोगिता के साथ एक अत्यधिक सामान्य दृष्टिकोण में निम्नलिखित विशेषताएं होनी चाहिए:

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

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

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

हो सकता है कि मैं अब बिल्कुल बंद हो गया हो, इसलिए मैं इसे उसी पर छोड़ने जा रहा हूँ :)

@acjay मुझे लगता है कि हम इन बिंदुओं पर आपसे सहमत हैं, समस्या इस कार्यान्वयन को खोजने की है जो उन सभी को सही ढंग से हल करती है :)

लेकिन ऐसा लगता है कि दोनों के पास जेनरेटर के साथ एक अभिव्यक्तिपूर्ण एपीआई है, और समय-यात्रा और स्नैपशॉट/पुनर्स्थापित राज्य की संभावना है ... शायद प्रभाव के निष्पादन को याद रखना संभव होगा ताकि हम आसानी से जेनरेटर राज्य को पुनर्स्थापित कर सकें ...

निश्चित नहीं है, लेकिन यह while(true) { ... } शैली की कहानियों को रोक सकता है। क्या लूपिंग सिर्फ राज्य की प्रगति का परिणाम होगा?

@acjay @slorber

जैसा कि मैंने (https://github.com/yelouafi/redux-saga/issues/22#issuecomment-168872101) में समझाया है, अकेले समय यात्रा करना (अर्थात बिना हॉट रीलोड के) सागाओं के लिए संभव है। आपको एक गाथा को एक विशिष्ट बिंदु तक ले जाने की आवश्यकता है, शुरुआत से उस बिंदु तक उत्पन्न प्रभावों का क्रम, साथ ही साथ उनके परिणाम (समाधान या अस्वीकार)। तब आप बस उस क्रम के साथ जनरेटर चलाएंगे

वास्तविक मास्टर शाखा में (अभी तक npm पर जारी नहीं किया गया है)। सागा निगरानी का समर्थन करते हैं, वे सभी उपज वाले प्रभावों को भेजते हैं, साथ ही साथ उनके परिणाम स्टोर को कार्रवाई के रूप में भेजते हैं; वे नियंत्रण प्रवाह ग्राफ का पता लगाने के लिए पदानुक्रम की जानकारी भी प्रदान करते हैं।

किसी दिए गए बिंदु तक एक सागा को फिर से चलाने के लिए उस प्रभाव लॉग का शोषण किया जा सकता है: वास्तविक एपीआई कॉल करने की कोई आवश्यकता नहीं है क्योंकि लॉग में पहले से ही पिछले प्रतिक्रियाएं हैं।

रेपो उदाहरणों में, एक गाथा मॉनिटर (एक Redux मिडलवेयर के रूप में कार्यान्वित) का एक {type: 'LOG_EFFECT'} भेजकर प्रवाह का एक ट्रेस प्रिंट कर सकते हैं

यहाँ async उदाहरण से एक प्रभाव लॉग का कब्जा है

संपादित करें: क्षमा करें निश्चित छवि लिंक

दिलचस्प! और वह देव उपकरण छवि _विस्मयकारी_ है।

यह अच्छा है :)

वास्तव में, वह गाथा मॉनिटर बहुत अच्छा है।

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

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

हाँ, लेकिन मुझे आश्चर्य है कि क्या दो विचारों को मिलाने का कोई तरीका है। redux-saga का call रैपर एक प्रभाव पर संकेत का एक बहुत ही सरल स्तर है, लेकिन मान लीजिए कि आप विभिन्न प्रकार के प्रभावों के लिए ड्राइवरों के साथ मिडलवेयर को प्रारंभ कर सकते हैं, तो आप उन्हें JSONable डेटा के रूप में उन प्रभावों का प्रतिनिधित्व कर सकते हैं, जो फ़ंक्शन से अलग हो जाते हैं वास्तव में कहा जा रहा है। ड्राइवर स्टोर में राज्य के अंतर्निहित परिवर्तनों को भेजने का विवरण संभालेगा।

थोड़े व्यावहारिक लाभ के लिए यह पूरी तरह से अतिरिक्त जटिलता हो सकती है। लेकिन बस इस सोच का अंत तक पालन करने की कोशिश कर रहा हूं।

ठीक है, मैंने एक और पुस्तकालय को एक साथ रखा है और इसका उपयोग करने के लिए वास्तविक दुनिया के उदाहरण को पोर्ट किया है:

सबसे पहले, हमारे पास प्रतिक्रियाओं का कार्यान्वयन है:
https://github.com/winstonewert/redux-reactions/blob/master/src/index.js
इंटरफ़ेस तीन कार्य है: startReactions स्टोर लेता है, एक प्रतिक्रिया फ़ंक्शन, और नामों से ड्राइवरों तक मैपिंग करता है। FromEmitter और FromPromiseFactory दोनों ड्राइवर बनाते हैं।

यहां उदाहरण सिस्टम को सक्षम करने के लिए startReactions को कॉल करता है:
https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/store/configureStore.dev.js#L28

प्रतिक्रियाओं का मूल विन्यास यहाँ है:
https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/reactions/index.js।
प्रतिक्रिया फ़ंक्शन वास्तव में केवल उन घटकों के माध्यम से पुनरावृत्त होता है जो उस पृष्ठ के लिए वास्तविक आवश्यक प्रतिक्रियाओं का पता लगाने के लिए प्रतिक्रिया () फ़ंक्शन वाले लोगों की तलाश में राउटर को तुरंत प्रतिक्रिया देते हैं।

जीथब एपीआई प्रतिक्रिया प्रकार का कार्यान्वयन यहां है: https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/reactions/api.js। यह ज्यादातर मूल उदाहरण में उपयोग किए गए मिडलवेयर से कॉपी/पेस्ट है। महत्वपूर्ण बिंदु यहां है: https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/reactions/api.js#L79 , जहां यह एक फ़ंक्शन से ड्राइवर बनाने के लिए FromPromiseFactory का उपयोग करता है वादे लौटाता है।

यहां एक घटक विशिष्ट प्रतिक्रिया फ़ंक्शन देखें: https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/containers/RepoPage.js#L80।

प्रतिक्रिया निर्माता और सामान्य तर्क https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/reactions/data.js में है

हाय दोस्तों! राइज़ ने अभी-अभी एक स्टोर एन्हांसर प्रकाशित किया है जो आपको एल्म-आर्किटेक्चर जैसी प्रभाव प्रणाली का भी उपयोग करने देता है! मुझे आशा है कि हम समुदाय की सभी जरूरतों को पूरा करने के लिए इन सभी दृष्टिकोणों को सीखने और सुधारने में सक्षम होंगे: मुस्कान:

https://github.com/raisemarketplace/redux-loop

चर्चा में रुचि रखने वाला कोई भी व्यक्ति यहां मेरे विचार पर और चर्चा देखना चाहेगा: https://github.com/winstonewert/redux-reactions/issues/7

आप यहां एक शाखा भी देख सकते हैं, जहां मैं अपने पैटर्न का उपयोग करके काउंटर ऐप को और अधिक सुंदर बनाने के लिए फिर से काम करता हूं:
https://github.com/winstonewert/redux-reactions/tree/elmish/examples/counter

मैंने यह भी पाया है कि मैं यहां इस्तेमाल किए गए दृष्टिकोण को फिर से खोज रहा हूं: https://github.com/ccorcos/elmish

अरे @yelouafi , क्या आप गाथा मॉनिटर आइडिया के लिंक को

https://github.com/yelouafi/redux-saga/blob/master/examples/sagaMonitor/index.js

प्रासंगिक नई चर्चा: https://github.com/reactjs/redux/issues/1528

(मेरा मानना ​​है कि यह संबंधित है। क्षमा करें यदि यह गलत जगह है)

क्या हम संभवतः सभी प्रभावों को डीओएम प्रतिपादन के समान ही मान सकते हैं?

1. jQuery अनिवार्य इंटरफ़ेस वाला एक DOM ड्राइवर है। रिएक्ट घोषणात्मक इंटरफ़ेस वाला एक डोम ड्राइवर है। इसलिए, आदेश देने के बजाय: "उस बटन को अक्षम करें", हम घोषणा करते हैं: "हमें उस बटन को अक्षम करने की आवश्यकता है" और ड्राइवर तय करता है कि DOM जोड़तोड़ क्या करना है। आदेश देने के बजाय: " GET \product\123 ", हम घोषणा करते हैं: "हमें उस डेटा की आवश्यकता है" और ड्राइवर तय करता है कि कौन से अनुरोध भेजने/रद्द करने हैं।
2. हम DOM ड्राइवर के लिए API के रूप में रिएक्ट घटकों का उपयोग करते हैं। आइए उनका उपयोग अन्य ड्राइवरों को भी इंटरफ़ेस करने के लिए करें।
   
   
   
   • <button ...> - हम अपने व्यू लेयर को "सामान्य" रिएक्ट घटकों से बनाते हैं
   
   
   • <Map ...> - हम कुछ पुस्तकालय के अनिवार्य इंटरफेस को घोषणात्मक में बदलने के लिए "रैपर" घटकों का उपयोग करते हैं। हम उन्हें "सामान्य" घटकों की तरह ही उपयोग करते हैं, लेकिन आंतरिक रूप से वास्तव में ड्राइवर होते हैं।
   
   
   • <Chart ...> - यह कार्यान्वयन के आधार पर उपरोक्त में से कोई भी हो सकता है। तो, "सामान्य" घटकों और ड्राइवरों के बीच की रेखा पहले से ही धुंधली है।
   
   
   • <Http url={'/product/'+props.selectedProductId} onSuccess={props.PRODUCT_LOADED} /> (या "स्मार्ट" <Service...> ) - हम अपने सर्विस लेयर ऑफ (यूआई-कम) ड्राइवर घटकों का निर्माण करते हैं
   
   

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

सुनिश्चित नहीं है कि new Date या Math.random यहां कैसे फिट होते हैं।

क्या अनिवार्य एपीआई को घोषणात्मक में बदलना हमेशा संभव है?
क्या आपको लगता है कि यह एक व्यवहार्य दृष्टिकोण है?

धन्यवाद

यह देखते हुए कि हमारे पास एसिंक्स क्रियाओं के लिए सागा और अन्य भयानक टूलिंग हैं, मुझे लगता है कि हम इसे अभी सुरक्षित रूप से बंद कर सकते हैं। कुछ दिलचस्प नई दिशाओं के लिए #1528 देखें (सिर्फ async से भी आगे)।