Redux: अपने सभी राज्य को एक अपरिवर्तनीय परमाणु में संग्रहीत करने के क्या नुकसान हैं?

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

आपका बहुत बहुत धन्यवाद! मैं वास्तव में इस बारे में सुनना चाहता था।

वैसे, मैं हर किसी को प्रोत्साहित करता हूं जो इस चर्चा में योगदान देना चाहते हैं कि वे Redux के साथ क्या निर्माण कर रहे हैं, इस बात का अंदाजा लगा सकते हैं ताकि परियोजनाओं के दायरे को समझना आसान हो।

ओम और रिडक्स और अन्य एकल राज्य परमाणु देयताओं जैसे कठिन प्रश्न बी / सी परियोजनाओं की अपनी तरह, सक्रिय रूप से डाउनसाइड को कम करता है। अपरिवर्तनीय बाधा के बिना, और gated, नियंत्रित एक एकल राज्य परमाणु का उपयोग आपके सभी डेटा को window (जिसमें डाउनसाइड अच्छी तरह से ज्ञात हैं) को संलग्न करने के विपरीत बिल्कुल भी नहीं है।

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

इन डाउनसाइड्स में से कोई भी हमारे लिए विशेष रूप से निषेधात्मक नहीं है :)

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

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

जिस चीज़ से मैंने संघर्ष किया है, एक नए उपयोगकर्ता के रूप में सबसे अधिक Redux में चरम (imho) कोडिंग शैली में बदलाव, और एक ही समय में वैचारिक परिवर्तन दोनों को दूर करने की कोशिश कर रहा है; यह अभी भी थोड़ा कठिन है, एक महीने में और इसमें गोता लगाने की कोशिश करने के बाद बदल जाता है; मैं कॉन्सेप्ट्स को प्राप्त करने के लिए https://github.com/ngrx/store में देख रहा हूं, लेकिन अधिक परिचित शैली / वाक्यविन्यास के साथ और बाकी ढांचा निहित / प्रदान किया गया है।

मैं समझता हूं कि कुछ के लिए, एक ढांचा एक बैसाखी है; लेकिन हममें से कुछ को इनकी आवश्यकता है; बहुत से लोग अपने खेल में सबसे ऊपर होंगे, जिनके पास मजबूत मजबूत राय होगी, इसलिए एक फ्रेमवर्क 'अंधेरे में लड़खड़ाने से बेहतर है, आप जानते हैं?' तो यह मेरे लिए एक बिंदु है, एक मध्य स्तर, मध्यम आयु वर्ग के प्रोग्रामर नई अवधारणाओं के लिए :)

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

आपकी गलती नहीं है, लेकिन फिर भी एक समस्या मुझे हल करने में मदद करना पसंद है :)

मुझे लगता है कि मेरे पास इस बिंदु पर सबसे बड़ा सवाल यह है कि कार्यों, उदाहरणों या वादों जैसे किसी भी गैर-धारावाहिक आइटम को कहां जाना चाहिए? दूसरी रात Reactiflux में इस बारे में सोच रहा था और कोई अच्छी प्रतिक्रिया नहीं मिली। इसके अलावा बस किसी को देखा http://stackoverflow.com/questions/35325195/should-i-store-function-references-in-redux-store ।

कई स्टोर के लिए केस का उपयोग करें (ध्यान रखें, यह सबसे अच्छा है जो मैं सोच सकता था):

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

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

@gaearon हम ट्रेडिंग प्लेटफॉर्म का निर्माण कर रहे हैं। मैंने पहले ही आपको एक बार समझाया है कि क्यों एक दुकान हमारे लिए फिट नहीं है (सेंट-पीटर्सबर्ग में React.js मीटअप के बाद)। मैं इसे फिर से विवरणों में समझाने की कोशिश करूँगा (मध्यम में ब्लॉग पोस्ट में?) लेकिन मुझे शायद अपने अंग्रेजी कौशल के कारण मदद की ज़रूरत है :) क्या यह ठीक है अगर मैं इसे आपको या किसी और को यहाँ भेज दूंगा संदेश जब यह किया जाएगा? मैं सटीक तारीख का नाम नहीं दे सकता, लेकिन मैं इस पोस्ट को जल्द-ईश (इस महीने के सबसे अधिक संभावित अंत) में लिखने की कोशिश करूंगा।

और हाँ हम अभी भी Dux से कुछ नियमों का उल्लंघन करते हुए कई दुकानों के साथ Redux का उपयोग कर रहे हैं जैसा कि react-redux उपयोग नहीं कर सकते क्योंकि मामलों में हमें विभिन्न दुकानों से डेटा की आवश्यकता है क्योंकि यह है एकल दुकान के मामले में)

Redux मूल रूप से इवेंट-सोर्सिंग है जहां उपभोग करने के लिए एकल प्रक्षेपण है।

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

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

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

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

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

मैं @jquense से भी सहमत

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

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

लेकिन यह भी संभव नहीं है कि सभी राज्य को नियंत्रित किया जाए। कभी-कभी हम मौजूदा पुस्तकालयों का उपयोग करते हैं, जिसके लिए एक घोषणात्मक इंटरफ़ेस का निर्माण करना कठिन होता है। कुछ राज्य भी एक कुशल तरीके से स्टोर को रिडक्स करने के लिए माउंट करना मुश्किल है, जिसमें शामिल हैं:

• पाठ इनपुट
• स्क्रॉल स्थिति
• व्यूपोर्ट का आकार
• माउस की स्थिति
• देखभाल की स्थिति / चयन
• कैनवस dataUrls
• अपरिहार्य अवस्था
• ...

यह सवाल मैंने अभी SO पर देखा था:

http://stackoverflow.com/questions/35328056/react-redux-should-all-component-states-be-kept-in-redux-store

Echos कुछ भ्रम मैंने UI स्थिति को प्रबंधित करने के बारे में देखा है, और क्या UI राज्य घटक से संबंधित होना चाहिए या स्टोर में जाना चाहिए। # 1287 इस सवाल का एक अच्छा जवाब देता है, लेकिन यह शुरू में स्पष्ट नहीं है और बहस के लिए तैयार हो सकता है।

इसके अतिरिक्त, यह एक बाधा हो सकती है यदि आप कुछ इस तरह से लागू करने की कोशिश कर रहे हैं https://github.com/ericelliott/react-pure-component-starter जिसमें हर घटक शुद्ध है और इसकी अपनी स्थिति में एक कहना नहीं है ।

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

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

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

उस ने कहा, निश्चित रूप से सबसे मुश्किल हिस्सा एनीमेशन राज्य में बांध रहा है। निम्नलिखित उदाहरण एनीमेशन राज्य को ध्यान में रखते हैं, लेकिन इसमें से अधिकांश को UI स्थिति के लिए सामान्यीकृत किया जा सकता है।

एनीमेशन के कुछ कारण Redux के लिए अजीब हैं:

• एनीमेशन डेटा अक्सर बदलता है
• एनिमेशन-विशिष्ट क्रियाएं आपके एप्लिकेशन में क्रियाओं के इतिहास को प्रदूषित करती हैं, जिससे सार्थक तरीके से क्रियाओं को रोल-बैक करना कठिन हो जाता है
• अगर कई घटक-विशिष्ट एनिमेशन हैं, तो Redux स्टेट ट्री, कंपोनेंट ट्री को मिरर करना शुरू करता है
• यहां तक ​​कि बुनियादी एनीमेशन राज्य जैसे animationStarted या animationStopped अपने UI पर युगल राज्य के लिए शुरू होता है।

दूसरी ओर, Redux राज्य के पेड़ के बाहर पूरी तरह से एनीमेशन राज्य के निर्माण के लिए निश्चित रूप से चुनौतियां हैं।

यदि आप DOM में हेरफेर करके खुद को एनिमेशन करने की कोशिश करते हैं, तो आपको इस तरह से सामान देखना होगा:

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

और अगर आप वर्चुअल-डोम को सभी DOM मैनिपुलेशन (जो आपको चाहिए!) का ख्याल रखने की कोशिश करते हैं, लेकिन Redux में एनीमेशन स्टेट को ध्यान में रखते हुए, आप इन जैसी कठिन समस्याओं को समाप्त करते हैं:

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

वर्तमान में प्रतिक्रिया-गति जैसी भयानक परियोजनाएं हैं जो इस समस्या को हल करने में बहुत आगे बढ़ाती हैं _for React_, लेकिन Redux प्रतिक्रिया के लिए अनन्य नहीं है। और न ही यह होना चाहिए, मुझे लगता है - बहुत से लोग अपनी खुद की दृश्य परत ला रहे हैं और Redux के साथ एकीकृत करने की कोशिश कर रहे हैं।

किसी के लिए जो उत्सुक है, मैंने Redux + वर्चुअल-डोम के लिए जो सबसे अच्छा समाधान पाया है, वह है दो राज्य परमाणुओं को रखना: Redux कोर एप्लीकेशन स्टेट को बनाए रखता है, क्रियाओं के जवाब में उस स्थिति में हेरफेर करने के लिए मुख्य तर्क रखता है, आदि। एक उत्परिवर्तनीय वस्तु है जो एनीमेशन स्थिति रखती है (मैं mobservable का उपयोग करता हूं)। फिर चाल Redux राज्य परिवर्तन _and_ एनीमेशन राज्य परिवर्तन दोनों की सदस्यता लेने के लिए है, और UI को दोनों के कार्य के रूप में प्रस्तुत करने के लिए है:

/* Patch h for jsx/vdom to convert <App /> to App() */
import h from './h'
import { diff, patch, create } from 'virtual-dom'
import { createStore } from 'redux'
import { observable, autorun } from 'mobservable'
import TWEEN from 'tween.js'
import rootReducer from './reducers'
import { addCard } from './actions'
import App from './containers/App'

// Redux state
const store = createStore()

// Create vdom tree
let tree = render(store.getState())
let rootNode = create(tree)
document.body.appendChild(rootNode)

// Animation observable
let animationState = observable({
  opacity: 0
})

// Update document when Redux state 
store.subscribe(function () {
  // ... anything you need to do in response to Redux state changes
  update()
})

// Update document when animation state changes
autorun(update)

// Perform document update with current state
function update () {
  const state = store.getState()
  let newTree = render(state, animationState)
  let patches = diff(tree, newTree)
  rootNode = patch(rootNode, patches)
  tree = newTree
}

// UI is a function of current state (and animation!)
function render (state, animation = {}) {
  return (
    <App {...state} animation={animationState} />
  )
}

// Do some animations
function animationLoop (time) {
  window.requestAnimationFrame(animationLoop)
  TWEEN.update(time)
}
animationLoop()

new TWEEN.Tween(animationState)
      .to({ opacity: 100 }, 300)
      .start()

// Or when you dispatch an action, also kick off some animation changes...
store.dispatch(addCard())
/* etc... */

महान प्रतिक्रियाओं के लिए आप सभी का धन्यवाद! उन्हें आने दो।

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

@taggartbg

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

क्या आप अपने उपयोग के मामले का अधिक विस्तार से वर्णन करने के लिए कोई समस्या पैदा करेंगे? यह हो सकता है कि राज्य के आकार को अलग ढंग से व्यवस्थित करने का एक सरल तरीका है कि आप गायब हैं। एक ही राज्य आकृति के साथ सामान्य कई शाखाओं में लेकिन विभिन्न रिड्यूसर द्वारा प्रबंधित एक विरोधी पैटर्न है।

@istarkov

Reducers के बीच राज्य कुंजी टकराव की संभावना बढ़ जाती है।

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

@gaearon @istarkov : शायद इसका मतलब यह है कि विभिन्न प्लगइन्स और संबंधित लाइब्रेरी समान स्तर के नामस्थानों के लिए हो सकता है? लाइब्रेरी ए को "myState" नाम की एक शीर्ष कुंजी चाहिए, लेकिन लाइब्रेरी बी आदि।

हाँ, यह एक अच्छा बिंदु है, भले ही यह @istarkov का मतलब न हो। (मुझे नहीं पता।) सामान्य पुस्तकालयों में पेड़ में कहीं भी reducer माउंट करने के लिए एक तरीका प्रदान करना चाहिए, लेकिन मुझे पता है कि कुछ पुस्तकालयों की अनुमति नहीं है।

@gaearon

क्या आप अपने उपयोग के मामले का अधिक विस्तार से वर्णन करने के लिए कोई समस्या पैदा करेंगे? यह हो सकता है कि राज्य के आकार को अलग ढंग से व्यवस्थित करने का एक सरल तरीका है कि आप गायब हैं। एक ही राज्य आकृति के साथ सामान्य कई शाखाओं में लेकिन विभिन्न रिड्यूसर द्वारा प्रबंधित एक विरोधी पैटर्न है।

मैं करने के लिए खुश हूँ! मैं ऐसा करूँगा जब मुझे एक पल मिलेगा।

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

मुझे इसके बारे में ऑफ-थ्रेड चैट करने में खुशी होगी, मैं बहुत अच्छी तरह से गलत हो सकता हूं।

@taggartbg : आपका कोड यहां कैसा दिखता है, यह जाने बिना पूरी तरह से बोलना। क्या आप इस तरह दिखने वाले राज्य से निपटने की कोशिश कर रहे हैं?

{ groupedData : { first : {a : 1, b : 2}, second : {a : 3, b : 4}, third : {a : 5, b, 6} }

ऐसा लगता है कि आप reducer की ओर से एक ही reducer समारोह है कि प्रत्येक कार्रवाई के हिस्से के रूप में प्रति समूह आईडी कुंजी लेता है के साथ सौदा कर सकता है। वास्तव में, क्या आपने https://github.com/erikras/multireducer , https://github.com/lapanoid/redux-delegator , https://github.com/reducks/redux-multiplex , या https://github.com/dexbol/redux-register?

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

@gaearon

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

डॉक्स और ट्यूटोरियल पढ़ने वाले एक रिएक्टर डेवलपर के पास पहले से ही उनके निपटान में यह अल्पकालिक स्थिति है, इसलिए यह संभव है कि जब Redux एक परियोजना के लिए समझ में आता है तो यह पहले से ही ध्यान में है।

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

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

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

@gaearon हमने एक एकल परमाणु राज्य बनाम पिपिंग के बीच वास्तु अंतर के बारे में Cycle.js पर एक दिलचस्प बातचीत की। यहाँ ।

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

चूँकि Cycle में सब कुछ एक ऑब्जर्वेबल है, मुझे एक मार्ग परिवर्तन से दूसरे में जाने के लिए राज्य प्राप्त करने में कठिनाई हो रही थी। यह राज्य एक ग्राहक नहीं होने एक बार एक मार्ग बदल दिया गया था नमूदार की वजह से था और, सोचा कि क्यों एक परमाणु राज्य को लागू नहीं तो किसी भी समय राज्य मेरे एप्लिकेशन में बदल यह शीर्ष स्तर की दुकान करने के लिए वापस रिपोर्ट करेंगे, किसी भी पाइपिंग दरकिनार ( भयानक देखने यहाँ चित्र )।

Cycle के साथ क्योंकि साइड इफेक्ट्स ड्राइवर्स में होते हैं, इसलिए आपको आमतौर पर उस लेवल को टॉप लेवल ड्राइवर से कंपोनेंट और बैक तक बनाना होता है, इसलिए मैं चाहता था कि उसे छोड़ें और सीधे ही अप और आउट टू द कंपोनेंट्स सुनें। Redux को प्रेरणा के स्रोत के रूप में ले रहा था।

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

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

अग्रिम में क्षमा करें यदि यह पूरी तरह से संदर्भ से बाहर है, तो प्रदर्शित करना चाहता था कि कैसे एक अलग प्रतिमान एक समान बातचीत थी: स्माइली:

@timdorr

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

मुझे लगता है कि यह बेहतर है जब विजेट का अपना राज्य होता है (हो सकता है कि यह भी अपना (redux?) स्टोर हो) तो यह किसी भी (मैशअप-) ऐप में स्टैंडअलोन काम कर सकता है और केवल कुछ गुणों को प्राप्त कर सकता है। मौसम विजेट के बारे में सोचो। यह अपने आप डेटा ला सकता है और दिखा सकता है और शहर, ऊंचाई और चौड़ाई जैसे गुण प्राप्त कर सकता है। एक और उदाहरण ट्विटर विजेट है।

@chicoxyzzy संबंधित: https://github.com/rackt/react-redux/issues/278

महान चर्चा!

मुख्य रूप से, मुझे कई ऐप्स / कंपोनेंट्स / प्लगइन्स को मिलाना असुविधाजनक लगता है।

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

उदाहरण के लिए:

मैं एक संदेशवाहक का निर्माण कर रहा हूं जो iMessage जैसा दिखता है। इसकी currentConversationId । मेरी Messenger घटक में @connect(state => ({ currentConversationId: state.messenger.currentConversationId })) ।

मैं इस Messenger को एक नए ऐप में शामिल करना चाहता हूं। मुझे import { rootReducer as messengerRootReducer } from 'my-messenger' देने होंगे और इसे काम करने के लिए combineReducers({ messenger: messengerRootReducer }) जोड़ना होगा।

अब, अगर मैं अलग-अलग डेटा वाले ऐप में दो <Messenger> इंस्टेंस रखना चाहता हूं, तो मैं नहीं कर सकता, क्योंकि मैं मैसेंजर घटक में state.messenger लिए बाध्य हूं। निर्माणस्टोर के एक विशिष्ट स्लाइस के खिलाफ काम करने से मुझे एक अनुकूलित @connect उपयोग करना पड़ेगा।

इसके अलावा, मान लें कि युक्त ऐप का एक निश्चित एक्शन नाम है जो my-messenger मॉड्यूल पर मौजूद है, एक टक्कर होने वाली है। यही कारण है कि ज्यादातर redux plugins में @@router/UPDATE_LOCATION जैसे उपसर्ग हैं।

कुछ यादृच्छिक / पागल विचार:

1

@connect स्टोर के एक विशिष्ट स्लाइस से जुड़ सकते हैं, इसलिए मैं अपने ऐप में कई <Messenger> s शामिल कर सकता हूं जो डेटा के अपने स्लाइस से कनेक्ट होते हैं, जैसे state.messenger[0] / state.messenger[1] । यह <Messenger> लिए पारदर्शी होना चाहिए जो अभी भी state.messenger से जुड़ता रहता है, हालांकि, युक्त ऐप कुछ इस तरह से स्लाइस प्रदान कर सकता है:

@connect(state => ({ messengers: state.messengers }))
class App extends Component {
  render() {
    return (
      <div>
        {this.props.messengers.map(messenger =>
          <ProvideSlice slice={{messenger: messenger}}><Messenger /></ProvideSlice>
        }
      </div>
    )
  }
}

वैश्विक सामान्यीकृत संस्थाओं का उपयोग करते समय एक समस्या है, state.entities को भी मौजूद रहने की आवश्यकता होगी, इसलिए कटा हुआ राज्य के साथ-साथ पूरे राज्य को किसी भी तरह उपस्थित होने की आवश्यकता है। ProvideSlice कुछ संदर्भ सेट कर सकते हैं कि Messenger @connect से पढ़ सकेंगे।

एक और मुद्दा यह है कि <Messenger> में घटकों द्वारा दागी जाने वाली कार्रवाइयों को @connect ProvideSlice mapDispatchToProps कार्रवाई हो।

2

store और reducer परिभाषाओं को मिलाएं, ताकि प्रत्येक reducer भी स्टैंडअलोन हो सके। स्टोर एक नियंत्रक की तरह लगता है जबकि एक reducer एक दृश्य है। यदि हम प्रतिक्रिया का दृष्टिकोण लेते हैं, तो "सब कुछ एक घटक है" (कोणीय 1.x के नियंत्रक / निर्देश के विपरीत), यह घटकों और उनके राज्य / कार्यों को वास्तव में स्टैंडअलोन होने की अनुमति दे सकता है। सामान्यीकृत संस्थाओं (यानी 'वैश्विक राज्य') जैसी चीज़ों के लिए रिएक्ट के संदर्भ जैसी किसी चीज़ का उपयोग किया जा सकता है, और यह सभी कार्यों (जैसे getState thunk ) / जुड़े घटकों के माध्यम से सुलभ हो सकता है।

@elado मैंने अब तक जो सबसे चतुर विचार देखा है, वह "प्रदाताओं" के साथ दिमाग में रखना है: https://medium.com/@timbur/react -automatic-redux-provider-and-replicators-c4e35a39f1

Thx @sompylasar। मैं सड़क पर यात्रा कर रहा हूं, लेकिन जब मुझे मौका मिलता है तो मैं एक और लेख लिखने की योजना बना रहा हूं, जो प्रदाताओं को पहले से ही प्रतिक्रिया और रिडक्स से परिचित होने के लिए अधिक उपयुक्त है। पहले से ही परिचित कोई भी इसे सरल / आसान पागल होना चाहिए। :)

_Comment https://github.com/loggur/react-redux-provide/issues/8_ पर चला गया

@gaearon अभी भी इस पर अपने विचार सुनना पसंद करेंगे।

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

@ इस तरह के सिस्टम को लागू करने की शुरुआत करने के

@gaearon

दूसरे शब्दों में, मैं रिएक्ट स्थानीय राज्य मॉडल की तरह कुछ देखना चाहूंगा लेकिन रिड्यूसर्स द्वारा समर्थित

मुझे लगता है कि मुश्किल हिस्सा यह है कि रिएक्ट स्थानीय राज्य एक घटक के जीवनचक्र से बंधा हुआ है, इसलिए यदि आप Redux में स्थानीय स्थिति को मॉडल करने की कोशिश करते हैं, तो आपके पास "बढ़ते" और "अनमाउंटिंग" के लिए खाता है। एल्म के पास यह समस्या नहीं है क्योंकि 1) घटकों में जीवनचक्र नहीं है, और 2) एक दृश्य का "माउंटिंग" मॉडल से लिया गया है, जबकि रिएक्ट में, स्थानीय स्थिति केवल _after_ मौजूद है

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

एक निश्चित बिंदु पर, मुझे ऐसा लग रहा है कि बस reducers + setState का उपयोग कर रहा हूं और इसे एक दिन कॉल कर रहा हूं: D Unless / जब तक React राज्य वृक्ष को

मुझे लगता है कि यह वही है जो @threepointone https://github.com/threepointone/redux-rean-cocal के साथ हल करने की कोशिश कर रहा है

@aclite का वैचारिक मॉडल स्थानीय राज्य के लिए बहुत अच्छा काम करता है, लेकिन यह वास्तव में वास्तविक दुनिया के अनुप्रयोगों में उपयोग करने के लिए एक दर्द की तरह दिखता है, जहां हमें पुस्तकालयों का उपयोग करना है, माउंट पर ध्यान देना है, लंबन प्रभाव को संभालना है या जो भी ... देखें https: // github.com/evancz/elm-architecture-tutorial/issues/49

@ दुकानदार हाँ मैं सहमत हूँ। क्या यह अनिवार्य रूप से नहीं है जो मैंने अभी कहा है? : डी

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

हाँ हम उसी पेज @acdlite पर हैं
प्रतिक्रिया के साथ एल्म वास्तुकला इस समस्या को हल करेगा।
यहां तक ​​कि भविष्य में एल्म भी हो सकता है क्योंकि यह vdom के हुक के उपयोग की अनुमति दे सकता है।

हालांकि एल्म आर्किटेक्चर को काफी कुछ बॉयलरप्लेट की आवश्यकता होती है। मुझे लगता है कि यह वास्तव में टिकाऊ नहीं है जब तक कि आप रैपिंग / एक्सट्रपिंग क्रियाओं के लिए फ्लो या टाइपस्क्रिप्ट का उपयोग नहीं करते हैं, और इस स्थानीय राज्य को संभालने के लिए अधिक सरल तरीका करना बेहतर होगा, जैसे @threepointone का समाधान

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

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

@gaearon क्या आप अपनी पिछली पोस्ट में react-redux-provide बात कर रहे हैं? मैं पूछ रहा हूं क्योंकि यदि आप हैं, तो आपकी प्रतिक्रिया के आधार पर, यह स्पष्ट है कि आपने इस पर पर्याप्त रूप से ध्यान नहीं दिया है।

इसके अलावा, @acdlite के राज्य के पेड़ को

provide डेकोरेटर द्वारा प्रदान की गई एपीआई निश्चित रूप से एक अमूर्त है और हाँ, यह वर्तमान में redux पर निर्भर है, लेकिन इसे redux पर निर्भर होने के रूप में सोचना गलत तरीका है इसके बारे में सोचें, क्योंकि यह वास्तव में घटकों और राज्य के पेड़ के बीच कुछ "गोंद" है, क्योंकि रिएक्ट के context अभी तक पूरी तरह से विकसित नहीं हुए हैं। के माध्यम से जोड़ तोड़ और राज्य वृक्ष (रों) का प्रतिनिधित्व करने का एक आदर्श विधि के रूप में समझें actions और reducers (यानी, दुकान के राज्य) के रूप में props , जहाँ आप कहीं भी हों अनिवार्य रूप से actions और reducers को propTypes (और / या contextTypes में) घोषित करें कि आप import कुछ और कैसे करें। आपके ऐप के भीतर। जब आप ऐसा करते हैं, तो हर चीज के बारे में तर्क करना आसान हो जाता है। रिएक्ट के context संभावित रूप से इन बुनियादी सुविधाओं को शामिल करने के लिए विकसित हो सकते हैं, और किस मामले में, यह grep करने के लिए पूरे 2 सेकंड लगेगा और @provide और import provide from 'react-redux-provide' इतना है कि आप कर रहे हैं फिर सरल घटकों के साथ छोड़ दिया जो अब उस पर निर्भर नहीं करते हैं। और अगर ऐसा कभी नहीं होता है, तो कोई बड़ी बात नहीं है क्योंकि सब कुछ पूरी तरह से और अनुमानित रूप से काम करना जारी रखेगा।

मुझे लगता है कि आप समस्या की देखरेख कर रहे हैं। आपको अभी भी बढ़ते और अनमाउंटिंग को हल करने की आवश्यकता है।

@acdlite एक उदाहरण है?

यदि आप जिन चीजों का जिक्र कर रहे हैं, उनमें से एक (उदाहरण के लिए) कुछ डेटाबेस से props प्राप्त करना है, जो कुछ id या जो भी हो, के आधार पर, यह (लगभग किसी भी अन्य व्यावहारिक अनुप्रयोग के बारे में आप सोच सकते हैं) प्रदाताओं के साथ आसानी से प्राप्त किया जा सकता है। जब मैं काम कर रहा होता हूं, तो कुछ अन्य चीजें पूरी करने के बाद, मुझे यह दिखाने में खुशी होगी कि यह कितना आसान है। :)

दिलचस्प हो सकता है: प्रतिक्रियाशील राज्य कार्यान्वयन की तुलना में ।
एल्म, रेडक्स, साइकिल ... (प्रगति में काम)

एकाधिक स्टोर के लिए एक और संभावित आवश्यकता तब होती है जब कई _time लाइन्स_, _टाइम ट्रेवल_, सेविंग लोकेशन और सेविंग फ़्रीक्वेंसी संभव और आवश्यक हो। उदाहरण के लिए, user data और user actions जो एक उपयोगकर्ता के लिए विशिष्ट हैं और common data और group actions उपयोगकर्ताओं के समूह के लिए विशिष्ट हैं (जैसे साझा किए गए बहु-उपयोगकर्ता प्रोजेक्ट या दस्तावेज़)। इससे यह तय करना आसान हो जाता है कि क्या तय किया जा सकता है (व्यक्तिगत डेटा में परिवर्तन) पूर्ववत किया जा सकता है (अन्य उपयोगकर्ताओं द्वारा पहले से ही संपादित किया गया) और अलग-अलग बचत और / या सिंक्रनाइज़ेशन चक्र होने की सुविधा भी देता है।

हम कोणीय 2.0 विकास मन सेट और redux का उपयोग करने के लिए सोच के साथ एक कोणीय 1.x आवेदन के डिजाइन / प्रारंभिक देव चरण में हैं। अतीत में, हम कुछ सामान्य प्रेषणों और कुछ समर्पित प्रेषणों का जवाब देने वाले कई स्टोरों के साथ प्रवाह का उपयोग करते रहे हैं।

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

भले ही reducers को विभाजित किया जा सकता है और इसका उपयोग करने वाले फीचर / विजेट के साथ रह सकते हैं, हमें स्टोर बनाने का समय आने पर उन सभी को क्लब करना होगा। हम अपने विजेट्स को रिड्यूसर्स के लिए किसी भी प्रत्यक्ष / अप्रत्यक्ष संदर्भ के बिना मौजूद देखना चाहेंगे जो इसकी परवाह नहीं करता है।

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

@VivekPMenon : आपकी विशिष्ट चिंताएँ क्या हैं? राज्य वृक्ष का आकार? नाम बदलने की क्रियाओं में सक्षम होना / Reducers को अलग रखना? Reducers को गतिशील रूप से जोड़ने या हटाने की क्षमता?

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

@markerikson। उत्तर के लिए बहुत बहुत धन्यवाद। मेरा भ्रम ज्यादातर 2 के बिंदु (अलगाव) के आसपास है। मान लें कि हमारी एक टीम विजेट ए बनाती है जो प्रवाह आधारित है और इसके राज्य के प्रबंधन के लिए स्टोर का उपयोग करने की आवश्यकता है। मान लें कि वे एक jspm / npm पैकेज बनाएंगे और यदि इसे वितरित करेंगे। वही दूसरी टीम के साथ मामला है जो विजेट बी बनाता है। ये स्वतंत्र विजेट / पैकेज हैं और एक-दूसरे पर प्रत्यक्ष / अप्रत्यक्ष निर्भरता रखने की आवश्यकता नहीं है।

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

@VivekPMenon यह एक वैध प्रश्न है जिसे हम में से कुछ हल करने की कोशिश कर रहे हैं।

आप यहां कुछ जानकारी प्राप्त कर सकते हैं: https://github.com/slorber/scalable-frontend-with-elm-or-redux

इसके अलावा, Redux-saga के बारे में मेरी awser पर एक नज़र डालें: http://stackoverflow.com/a/34623840/82609

@ Slorber मार्गदर्शन के लिए बहुत धन्यवाद। आगे आने वाले विचारों के लिए यहाँ देखें https://github.com/slorber/scalable-frontend-with-elm-or-redux

@taggartbg क्या आपने अंततः एक मुद्दा खोला? मुझे एक समान चीज़ में दिलचस्पी

@slorber

मुझे यह कहने से शुरू करें कि redux गाथा एक बहुत ही अद्भुत परियोजना है, हालांकि इसमें बहुत कुछ है और यह किसी भी तरह से कम करने की कोशिश नहीं करता है।

लेकिन मैं इसे वर्तमान स्थिति में अपनी किसी भी परियोजना में उपयोग नहीं करूंगा। यहाँ कुछ कारण हैं

सागा स्टेटलेस हैं

आप एक जनरेटर की स्थिति को क्रमबद्ध नहीं कर सकते हैं, वे समझ में आते हैं कि वे चल रहे हैं लेकिन वे पूरी तरह से गाथा की स्थिति से बंधे हैं। यह सीमाओं की एक श्रृंखला का कारण बनता है:

• आप समय पर जनरेटर नहीं ले सकते
• आप उस पथ को ट्रेस नहीं कर सकते हैं जिसके कारण यह वर्तमान स्थिति में है
• आप प्रारंभिक अवस्था को परिभाषित नहीं कर सकते
• आप अनुप्रयोग के राज्य से व्यावसायिक तर्क को अलग नहीं कर सकते [*]
• आप साग को स्टोर नहीं कर सकते

[*] इसे एप्लिकेशन के मॉडल की परिभाषा के भीतर व्यावसायिक तर्क को परिभाषित करने के रूप में व्याख्या किया जा सकता है, जिससे एमवी और सी को एमवीसी में एक ही चीज़ बना दिया जा सकता है, जिसे एक एंटीपैटर्न माना जा सकता है

कार्रवाई को भेजना गैर-नियतात्मक है

Redux का उपयोग करने के बड़े लाभों में से एक सरल समझ है कि राज्य किसी कार्रवाई पर कैसे प्रतिक्रिया करता है। लेकिन Redux-saga अप्रत्याशित परिणामों के लिए कार्य करता है क्योंकि आप यह नहीं बता सकते हैं कि आप उस गाथा के किस भाग से शुरू कर रहे हैं।

क्रमिक अवस्था

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

राज्य में लॉजिक लॉजिक खराब है, और मेरी राय में यह एक तरह से रेडक्स गाथा है।

यह पूरी तरह से ठीक है कि मान लें कि आपके एप्लिकेशन की स्थिति _your_ एप्लिकेशन के लिए विशिष्ट है। इसका मतलब है कि यह मानना ​​भी ठीक है कि जब तक यह _your_ एप्लिकेशन के शीर्ष पर काम करता है, तब तक एप्लिकेशन की स्थिति अनुमानित है। इसका मतलब यह है कि स्टोर की जानकारी रखना ठीक है जो यह निर्धारित करता है कि वास्तव में तर्क को बचाने के बिना आपका आवेदन कैसे व्यवहार करता है।

@eloytoro

मैं आपकी चिंताओं को समझता हूं। यदि आप redux-saga के मुद्दों को देखेंगे तो आप देखेंगे कि इन बातों पर चर्चा की गई है और इसके समाधान ढूंढे जाने हैं।

यह भी ध्यान दें कि redux-saga जनरेटर के साथ लागू करने के लिए चुनते हैं, लेकिन यह गाथा पैटर्न को लागू करने के लिए बिल्कुल भी आवश्यकता नहीं है, और पेशेवरों और विपक्ष हैं।

एक चुनिंदा प्रभाव है जो आपको अपने Redux-saga के अंदर redux राज्य का उपयोग करने की अनुमति देता है, इसलिए यदि आप जनरेटर के अंदर राज्य को छुपाना नहीं चाहते हैं, तो आप सीधे अपनी saga स्थिति को redux-store के अंदर रख सकते हैं, लेकिन इसमें अधिक कार्य शामिल है।

सागा देवता हैं जो साग के निष्पादन का पता लगाने की अनुमति देते हैं।

समय-यात्रा के संभावित समाधान हैं लेकिन अभी तक कोई ठोस क्रियान्वयन नहीं हुआ है

सही। काफी लंबा विषय और बहुत दिलचस्प। मैं विभिन्न राज्य-प्रबंधन दृष्टिकोणों की तुलना कर रहा हूं।

तुलना करते समय मैं कुछ बातों को ध्यान में रख रहा हूं:

1. सत्य का एकल स्रोत
2. सर्वर-साइड पर रेंडर करना और क्लाइंट-साइड पर शुरुआती डेटा फीड करना कितना आसान / कठिन है
3. रीलोड के बाद पूर्ववत / पुन: और लगातार इतिहास भंडारण की तरह devtools।
4. एनिमेशन, एनिमेशन, एनिमेशन। मैं हमेशा अपने आप से पूछता हूं _ "समाधान के साथ एनिमेशन कैसे काम करेगा a या b" _। यह मेरे लिए एक कुंजी है क्योंकि मैं जिन उत्पादों का विकास कर रहा हूं वे UX- केंद्रित हैं। मैं बहुत भ्रम साझा करता हूं @jsonnull के पास।
5. किसी अन्य ऐप के अंदर घटकों का पुन: उपयोग
6. अखंडता बनाए रखने के लिए संदर्भित डेटा (_major दर्द_) का जलयोजन (सर्वर-साइड या किसी अन्य डेटा-स्रोत से प्रारंभ करने के लिए संबंधित)
7. इस तरह की चर्चा के लिए अन्य देवों का समुदाय

इसलिए ये ऐसे बिंदु हैं जिनसे मैं राज्य-प्रबंधन के बारे में सोचता हूँ। अधिकांश बॉक्सों पर टिक करके Redux विजेता है। मैं Redux को अच्छी तरह से जानता हूं और यह पहली चीज थी जिसने मुझे क्लाइंट-साइड जेएस के दायरे में शांति से सांस लेने में मदद की।

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

दोनों सत्य के एकल स्रोत के विचार को साझा करते हैं और मुझे लगता है कि यह देखना दिलचस्प है कि वे इसे कैसे संभालते हैं।

Mobx के बारे में मेरा (निश्चित रूप से सीमित) शोध इसके परिणामस्वरूप है:

1. Mobx (बस Redux के रूप में) सत्य के एकल स्रोत की वकालत कर रहा है लेकिन एक वर्ग के रूप में अवलोकन योग्य गुणों के साथ। यह अवधारणा एक पूरे के रूप में रिडक्स और फ्लक्स के साथ अंतर पैदा करती है:
   
   
   
   1. Mobx उप-स्टोर (वैश्विक एकल one_ का हिस्सा / हिस्सा) की वकालत भी करता है। मेरे लिए यह क्लाइंट-साइड स्कीमा को निश्चित करने जैसा है। यह थोड़ा कष्टप्रद है क्योंकि आपके पास सर्वर पर भी स्कीमा है। मैं redux-orm साथ समानताएं देखता हूं। AFAIK उप-स्टोरों को प्रॉप्स के रूप में घटकों को पारित करने का इरादा है (इस तरह से प्रॉम्प्ट पर ग्लोबल मैपिंग करने के लिए राज्य मैपिंग पर निर्भर नहीं है या कुछ महत्वपूर्ण है)। हालाँकि किसी एकल संपत्ति को पारित करने से "गुणों" के बारे में मेरा विचार टूट जाता है - उन्हें इस बात का विवरण होना चाहिए कि घटक को क्या चाहिए। यह वास्तव में मुझे लगता है कि अगर यह एक समस्या होगी अगर रिएक्ट propTypes का उपयोग स्टोर के आकार को परिभाषित करने के लिए किया जा सकता है। इसके अलावा: कक्षाओं के रूप में स्टोर और उप-स्टोर होने से डेटा को सीधे सामान्यीकरण की आवश्यकता के बिना संदर्भित करना संभव हो जाता है, लेकिन अगर आप इंटिअल डेटा को फीड करना चाहते हैं तो यह इस तरह का व्यर्थ है:
   
   
   2. वर्ग के रूप में स्टोर के विचार का अर्थ है कि डेवलपर के पास बॉक्स से क्रमबद्धता नहीं है, जिसका अर्थ है कि यदि आप डेटा डिलीट करना चाहते हैं तो यह आपका काम है।
   
   
2. इतिहास और पूर्ववत करें / फिर से बदलने के बाद राज्य के स्नैपशॉट के माध्यम से प्राप्त किया जा सकता है। लेकिन आपको खुद को सीरियसलाइज़र, डिसेरिएलाइज़र लिखने की ज़रूरत है। उदाहरण यहाँ दिया गया है: https://github.com/mobxjs/mobx-reactive2015-demo/blob/master/src/stores/time.js
3. धारावाहिक लिखने के बारे में अच्छी बात यह है कि आप सामान बाहर छोड़ सकते हैं। यह गैर-लगातार एनीमेशन से संबंधित डेटा को संग्रहीत करने के लिए एक अच्छी जगह की तरह दिखता है। इसलिए यदि आप इसे क्रमबद्ध करते हैं, तो आप इसे अनदेखा कर देते हैं और आपके पास एनीमेशन चरणों से भरा कोई नया / पूर्ववत नहीं है।
4. Mobx स्टोर में डेटा की व्युत्पत्ति रखने की वकालत करता है (स्टोर के तरीकों के रूप में) reselect + connect डेकोरेटर का विरोध करता है। यह मुझे गलत लगता है।
5. अपने अवलोकनीय स्वभाव के कारण, mobx कुशल शुद्ध घटकों को परिभाषित करना आसान बनाता है। संपत्तियों की उथले तुलना कोई समस्या नहीं है क्योंकि सामग्री वैसे भी अवलोकनीय है।

सैम और रेडक्स की तुलना करना, मुझे यह सोचना पसंद है कि तर्क कैसे बहता है:

1. Redux:
   
   
   
   1. एक दुकान परिभाषित करें
   
   
   2. उन कार्यों को परिभाषित करें जो स्टोर परिवर्तन को संभालते हैं (रिड्यूसर)
   
   
   3. हर दुकान को बदलने और विशिष्ट रेड्यूसर को चलाने के लिए ईवेंट (रिडक्स एक्शन) आइडेंटिफ़ायर (रिडक्स एक्शन टाइप) को परिभाषित करें
   
   
   4. घटक कंटेनर गुणों के लिए मैप स्टोर, उपयोगकर्ता इंटरैक्शन (क्लिक, प्रकार, sscroll, आदि) के वैकल्पिक रूप से गुजरने वाले फ़ंक्शंस के रूप में जो केवल ईवेंट / ट्रिगर कार्रवाई को ट्रिगर करते हैं।
   
   
   5. घटक एक घटना (redux क्रिया) को ट्रिगर करता है जो सभी reducers के खिलाफ मेल खाता है
   
   
   6. नए राज्य के साथ रेंडरर।
   
   
2. सैम:
   
   
   
   1. एक दुकान परिभाषित करें।
   
   
   2. स्टोर के लिए एक एक्सेसर / सेटर फ़ंक्शन को परिभाषित करें। यह सेटर किसी भी डेटा को स्वीकार करता है और विशुद्ध रूप से डेटा के आधार पर यह पता लगाने की कोशिश करता है कि इसे स्टोर में कहां रखा जाए और क्या इसे सर्वर से डेटा का अनुरोध करने की जरूरत है या इसे वहीं बनाए रखना है। डेटा के साथ क्या करना है यह पता लगाना हमेशा केवल निरीक्षण करने से संभव नहीं होता है, इसलिए कभी-कभी पहचानकर्ता / झंडे का उपयोग किया जाता है (जैसे isForgottenPassword )। इस सेटर का उद्देश्य डेटा को मान्य करना और त्रुटियों को संग्रहीत करना भी है। सेटर समाप्त होने के बाद -> नए राज्य के साथ रेंडरर।
   
   
   3. फ़ंक्शंस को परिभाषित करें जो डेटा के टुकड़े को स्वीकार करते हैं, इसे रूपांतरित करते हैं (रिड्यूस रिड्यूसर का विकल्प) और ट्रांसफ़ॉर्म किए गए डेटा को पारित करने वाले सेटर को निष्पादित करें। उन कार्यों को अब स्टोर के आकार के बारे में पता है। वे केवल वे डेटा जानते हैं जो वे पारित कर चुके हैं।
   
   
   4. घटक कंटेनर गुणों के लिए डेटा स्टोर करें लेकिन उपयोगकर्ता इंटरैक्शन हैंडलर (क्लिक, टाइप, स्क्रॉल, आदि) को पास करने के लिए भी अनिवार्य है। ध्यान दें कि ये वास्तविक फ़ंक्शंस हैं (Redux में reducers के रूप में जाना जाता है) और फ़ंक्शंस को निष्पादित करने वाले फ़ंक्शंस नहीं।
   
   
   5. नोट: क्रियाओं का कोई प्रेषण नहीं है, सीधे reducers का गुजरना।
   
   

तो, सभी redux, SAM और Mobx राज्य को एक स्थान पर रखते हैं। जिस तरह से वे ऐसा करते हैं, अपने स्वयं के असफलता लाता है। Redux और उसके पारिस्थितिकी तंत्र को अब तक कोई नहीं हरा सकता है।

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

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

मुझे नहीं पता कि आप लोग एरिक मीजर का यह लेख पढ़ चुके हैं। बस एक सरल उद्धरण:

आम धारणा के विपरीत, राज्य चर को अपरिवर्तनीय बनाना अस्वीकार्य निहित प्रभाव को समाप्त करने के लिए कहीं नहीं आता है

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

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

मैं एरिक मीजेर के काम का प्रशंसक हूं और उत्सुकता से वह कुछ भी पढ़ने और सुनने के लिए कहूंगा, जबकि यह भी ध्यान में रखते हुए कि वह मेरे समान व्यवसाय, तकनीकी और बौद्धिक बाधाओं के तहत काम नहीं करता है।

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

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

इसके पीछे एक सिद्धांत है (एप्लीकेशन) स्टेट म्यूटेशन, इसे TLA + कहा जाता है, यह काफी अजीब है ... एरिक ने कभी भी टीएलए + का उल्लेख नहीं किया ...

JJ-

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

सवाल यह है कि आप इसे कैसे ठीक कर सकते हैं? क्या आप इस बात से सहमत नहीं होंगे कि यह एक ऐसी समस्या है जिसके लिए " प्रथम सिद्धांत " दृष्टिकोण की आवश्यकता है?

एक बहुत सिद्धांत है कि हम सभी कंप्यूटर विज्ञान में सहमत हो सकते हैं, डॉ। लैम्पपोर्ट ने कहा है: "कंप्यूटर विज्ञान के अधिकांश राज्य मशीनों के बारे में है।" और वह जारी रखता है: "फिर भी कंप्यूटर वैज्ञानिक अभिकलन का वर्णन करने के लिए उपयोग की जाने वाली भाषाओं पर इतने केंद्रित हैं कि वे बड़े पैमाने पर अनजान हैं कि वे सभी भाषाएं राज्य मशीनों का वर्णन कर रही हैं।"

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

आप एरिक के हाहा उदाहरण के बारे में जितना चाहें उतना हँस सकते हैं:
// prints Ha var ha = Ha(); var haha = ha+ha;

लेकिन वह कहता है कि आप किसी दिए गए राज्य में गलत कार्रवाई कर रहे हैं। न कुछ ज्यादा, न कुछ कम।

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

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

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

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

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

@markerikson मैं इस चर्चा को जारी रखना चाहूंगा, भले ही इसका शीर्षक कहीं भी हो, विषय मुझे काफी रुचिकर लगता है। बेहतर होगा कि वह अपनी जहरीली टिप्पणियों से बाहर निकलें और अच्छे ओपन सोर्स चर्चा को जारी रखें।
@Antitoxic के अलावा (कोई भी इरादा नहीं) ने यह स्पष्ट कर दिया कि दृष्टिकोण कहाँ तक उपयोगी है या नहीं, हमें पता है कि उनके हस्तक्षेप के कारण अन्य मुद्दे कितने खराब हो गए हैं इसलिए अब सुनने का कोई मतलब नहीं है

यह ठीक है मार्क आप मेरी टिप्पणियों को हटा सकते हैं, इतनी शानदार बातचीत क्यों बिगाड़ सकते हैं?

@jdubray केवल आप इसे शानदार के रूप में देखते हैं। मुझे लगता है कि हम सभी को लगता है कि आप "लामपोर्ट को ट्यूरिंग अवार्ड मिला है, की तुलना में अधिक तर्कों के बिना हमें कुछ बेचने की कोशिश करेंगे, तो मुझे सुनें, मैं सही हूँ!"।

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

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

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

आप TLA + को अनदेखा करने के लिए स्वतंत्र हैं, लेकिन यह थोड़ा सा है जैसे आप शिकायत कर रहे हैं कि आपने चंद्रमा को रॉकेट भेजने की कोशिश की थी, यह मानकर कि पृथ्वी सपाट थी और अंतरिक्ष यान को चलाना वास्तव में कठिन था।

यह निश्चित रूप से एक सादृश्य जैसा दिखता है और निश्चित रूप से पहला सिद्धांत नहीं है। गंभीरता से, क्या आपको लगता है कि इस कथन को "शानदार चर्चा" माना जाना है?

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

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

शायद @gaearon को पसंद करते हैं और

@Niondir मैं उन मामलों में
यह एक पैटर्न या नियमों का एक सेट का पालन करने के लिए अधिक है

• अपने सगाओं को अलग करें ताकि उनमें से प्रत्येक के पास एक put । यदि आपके पास put से अधिक के साथ sagas हैं, तो उन्हें विभाजित करें और उन्हें call प्रभाव के साथ श्रृंखला दें। उदाहरण के लिए

function* mySaga() {
  yield put(action1());
  yield put(action2());
}

// split into

function* mySaga() {
  yield put(action1());
  yield call(myNextSaga);
}

function* myNextSaga() {
  yield put(action2());
}

• take प्रभाव वाले सगाओं को उस तर्क में विभाजित किया जाना चाहिए जो take और गाथा के शुरुआती बिंदु का अनुसरण करता है। उदाहरण के लिए

function* mySaga() {
  yield take(ACTION);
  // logic
}

// split it into

function* rootSaga() {
  yield takeLatest(ACTION, mySaga);
}

function* mySaga() {
  // logic
}

• प्रत्येक गाथा के लिए एक "चेकपॉइंट" सुविधा का निर्माण करें, जिसका अर्थ है कि राज्य से पढ़ने के लिए और वहां से call गाथा जिसकी आपको आवश्यकता है

function* rootSaga() {
  // emit all forks and take effects that need to run in the background
  yield call(recoverCheckpoint);
}

function* recoverCheckpoint() {
  const state = yield select();
  if (state.isFetching) {
    // run the saga that left the state like this
  }
}

स्पष्टीकरण क्यों यह काम करेगा मान्यताओं के एक सेट पर आधारित है जो आम तौर पर सच है

• take प्रभावों को स्टोर में भेजे जाने के लिए क्रियाओं की आवश्यकता होती है, इसकी तिजोरी को हमेशा इन सागों को कॉल करना चाहिए, भले ही आप ठीक हो रहे हों क्योंकि वे तब तक निष्क्रिय रहते हैं जब तक उपयोगकर्ता पेज के साथ बातचीत नहीं करता है और / या सागा पहले से ही चल रहा है।
• प्रति गाथा एक put अनुमति न देने से राज्य में परमाणु परिवर्तन की अनुमति मिलती है, उसी तरह एक कार्रवाई केवल राज्य को एक ही तरीके से बदल सकती है एक गाथा उस क्षमता तक ही सीमित है, जो तरह तरह के बनाता है सागा और कार्रवाई प्रेषण के बीच एक संबंध।

इस तरह से बंटवारे करने से कुछ सकारात्मक प्रभाव पड़ते हैं।

• सगा अधिक पुन: प्रयोज्य हैं
• सगा अधिक आसानी से बदल जाते हैं
• सगा समझने में आसान हैं

लेकिन @ दुकानदार :

• (10 मिनट) इंट्रो वीडियो यहाँ है: https://www.youtube.com/watch?v=lMgSS_b98S8
• कोड नमूना जो मैं वीडियो में बात करता हूं वह यहां है: https://github.com/jdubray/sam-samples/tree/master/js-rectangle

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

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

मैं Meteor के साथ React / Redux का उपयोग कर रहा हूं। मैं कॉलबैक के लिए Redux क्रियाओं को Mongo.Collection.observeChanges भेजकर Immutable.js राज्य में mongo दस्तावेज़ संग्रहीत करता हूं। मैंने हाल ही में पाया कि जब कई हज़ार दस्तावेज़ों की सदस्यता ली गई थी, तो यूआई स्टार्टअप पर बेहद सुस्त था क्योंकि हजारों Redux कार्रवाइयाँ प्रेषित हो रही थीं क्योंकि उल्का ने एक-एक करके प्रारंभिक सदस्यता के परिणाम भेजे, जिससे हजारों Immutable.js के संचालन और हजारों रेंडर के रूप में तेज़ हो गए यथासंभव। मुझे लगता है कि RethinkDB भी इस तरह से काम करता है, हालांकि मुझे यकीन नहीं है।

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

@ jedwards1211 मुझे एक समान समस्या है (बहुत से छोटे संदेश जो प्रारंभिक डेटा की रचना करेंगे)।

बैच अपडेट करके उसी तरह हल किया गया। एक मिडलवेयर के बजाय मैंने उपयोगकर्ता को एक (छोटा) कस्टम कतार तंत्र बनाया है (एक सरणी में सभी अपडेट पुश करें, और नियमित अंतराल पर अगर एक ही समय में उन सभी को अपडेट करने के लिए कुछ भी हो।

@andreieftimie हाँ, यह मेरे ऐप में मुश्किल है क्योंकि कुछ यूआई इंटरैक्शन हैं जिन्हें तत्काल अपडेट की आवश्यकता होती है, जैसे कि

इसके लायक क्या है, मुझे "शाखाएं" बनाने का विचार था। यह एकल स्टोर सिद्धांत को पूरी तरह से परिभाषित करता है, लेकिन यह एक अच्छा समझौता था।

https://github.com/stephenbunch/redux-branch

@ jedwards1211 मुझे लगता है कि जैसे-जैसे एप्लिकेशन जटिलता में बढ़ते हैं, अंततः कुछ प्रकार के डेटा और कुछ प्रकार के अपडेट को बाहर करने की आवश्यकता होती है, ताकि कुछ स्टोर पूर्ण लोड को संभाल नहीं रहे हैं।

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

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

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

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

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

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

अगर मैं आज एक जटिल एप्लिकेशन बना रहा था, तो मैं कुछ अलग-अलग स्टोर द्वारा समर्थित Redux-like शीर्ष-स्तरीय स्टोर क्लास के साथ शुरू करूँगा। मोटे तौर पर:

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

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

@jsonnull मुझे कभी भी एनीमेशन राज्य को स्टोर करने की आवश्यकता नहीं थी - स्थानीय राज्य हमेशा मेरे एनीमेशन उपयोग के मामलों के लिए आदर्श रहा है। मुझे यह जानने के लिए उत्सुक होना चाहिए कि क्या कुछ उपयोग के मामले हैं जिनके लिए स्थानीय एनीमेशन राज्य पूरी तरह से अनुपयुक्त है। ऐसा लगता है कि उनके पास नई वास्तुकला के लिए महान विचार हैं।

@ jedwards1211 ऐसे कुछ मामले हैं

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

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

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

अब एक उदाहरण के लिए जहां आपके पास कुछ एनीमेशन स्थिति को स्थानीय रखने की क्षमता है - इसके ऊपर एक रिएक्ट-आधारित UI के साथ एक ब्राउज़र गेम का निर्माण।

• आमतौर पर आप गेम को टिक्स का उपयोग करके चलाएंगे ... गेम का समय 0 से शुरू होता है और यह हर फ्रेम में बढ़ा हुआ होता है। कोर गेम एनिमेशन कैनवास पर या वेबजीएल में किया जा सकता है, जहां कोई स्थानीय स्थिति नहीं है, इसलिए आप इन टिकों के आधार पर एनीमेशन शुरू समय और प्रगति को आधार बनाने जा रहे हैं।

Ex: एक स्प्राइट कैरेक्टर में 10 फ़्रेमों वाला एक एनीमेशन होता है, और आप ~ 400ms से अधिक के एनिमेशन को खेलना चाहते हैं, इसलिए आप स्प्राइट को प्रत्येक 2 टिक्स या उसके बाद से बदलने जा रहे हैं।

यदि आप उच्च रिज़ॉल्यूशन चाहते हैं, तो आपके टिक्स भी टाइमस्टैम्प हो सकते हैं।

• आपका गेम रुक भी सकता है, जिस स्थिति में आप प्रतिक्रिया यूआई पक्ष में किए गए कुछ एनिमेशन को रोक सकते हैं।

इस खेल के उदाहरण में, आप जो नहीं करना चाहते हैं वह tick एक्शन के भाग के रूप में आपके टिक्स को बढ़ाता है ... इसके बजाय आप टिक्सेस को अलग से बढ़ाना चाहते हैं, संभवत: एक अवलोकन योग्य संरचना में। और जब आप कीबोर्ड कैरेक्टर मूवमेंट या हमले जैसे Redux कार्यों को भेजते हैं, तो आप वर्तमान टिक या वर्तमान समय को उनके पास भेज देंगे, ताकि आप यह रिकॉर्ड कर सकें कि किस एक्शन पर टिक हुआ है और आपके UI घटक स्थानीय स्तर पर रिकॉर्ड कर सकते हैं कि एनीमेशन किस समय शुरू हुआ ।

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

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

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

@jsonnull शांत, यह एक महान उदाहरण है, जो साझा करने के लिए धन्यवाद।

मैं बस इतना कहूंगा - Redux में आप सिर्फ वस्तुओं को एक दूसरे से लिंक कर सकते हैं। उदाहरण के लिए - उपयोगकर्ता के पास कई पोस्ट हो सकते हैं और पोस्ट में कई टिप्पणियां हो सकती हैं और मैं उन वस्तुओं को एक तरह से संग्रहीत करना चाहता हूं:

var user = {id: 'user1', posts: [], comments: []}
var post = {id: 'post1', user: user, comments: []}
user.posts.push(post);
var comment = {id: 'comment1', post: post, user: user}
post.coments.push(comment)
user.comments.push(comment)
appState.user = user

Redux परिपत्र संदर्भ के साथ ऑब्जेक्ट पदानुक्रम के उपयोग की अनुमति नहीं देता है। Mobx (या सेलएक्स) में आप बस वस्तुओं के साथ एक-से-कई और कई-से-कई संदर्भ रख सकते हैं और यह कई बार व्यापार तर्क को सरल बनाता है

@bgnorlov मैं redux पैकेज में कुछ भी नहीं सोचता हूं जैसे आप के बारे में बात कर रहे हैं परिपत्र संदर्भों को प्रतिबंधित करते हैं - वे सिर्फ आपके reducer में आपके state को क्लोन करना अधिक कठिन बनाते हैं। इसके अलावा, यदि आप अपने राज्य का प्रतिनिधित्व करने के लिए Immutable.js का उपयोग करते हैं, तो परिपत्र संदर्भ के साथ राज्य में परिवर्तन करना आसान हो सकता है, हालांकि मुझे यकीन नहीं है।

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

var user = {id: 'user1', postIds: [], commentIds: []}
var post = {id: 'post1', userId: user.id, commentIds: []}
user.postIds.push(post.id);
var comment = {id: 'comment1', postId: post.id, userId: user.id}
post.commentIds.push(comment.id)
user.commentIds.push(comment.id)
appState.userId = user.id
appState.posts = {[post.id]: post}
appState.comments = {[comment.id]: comment}

// then join things like so:
var postsWithComments = _.map(appState.posts, post => ({
  ...post,
  comments: post.commentIds.map(id => appState.comments[id]),
})

@ jedwards1211 को क्लोन करने के लिए राज्य के साथ
सामान्यीकरण दृष्टिकोण के साथ जब किसी घटना हैंडलर को कुछ डेटा की आवश्यकता होती है, तो उसे वैश्विक राज्य से आईडी द्वारा ऑब्जेक्ट लेने के लिए हर बार आवश्यकता होती है। उदाहरण के लिए - मुझे इवेंट हैंडलर में कहीं काम के भाई-बहनों को फ़िल्टर करने की आवश्यकता है (कार्यों में पदानुक्रमित संरचना हो सकती है) redux के साथ मुझे ऐप स्टेट तक पहुंच प्राप्त करने के लिए थंक को भेजने की आवश्यकता है

var prevTask = dispatch((_, getState)=>getState().tables.tasks[task.parentId]).children.map(childId=>dispatch((_, getState)=>getState().tables.tasks[childId])).filter(task=>...) [0]

या चयनकर्ताओं के साथ

var prevTask = dispatch(getTaskById(task.parentId)).children.map(childId=>dispatch(getTaskById(childId)).filter(task=>...)[0]

और यह बॉयलरप्लेट कोड में गड़बड़ी की तुलना मोबेक्स संस्करण से करता है जब मैं बस लिख सकता हूं

var prevTask = task.parent.children.filter(task=>...)[0]

@ jedwards1211 , @bgnorlov : FWIW, यह एक कारण है कि मुझे Redux-ORM क्यों पसंद है। यह आपको अपने Redux स्टोर को सामान्य रखने की अनुमति देता है, लेकिन उन संबंधपरक अपडेट और लुकअप को सरल बनाता है। वास्तव में, वह अंतिम उदाहरण मूल रूप से Redux-ORM के समान है।

मैंने Redux-ORM मूल बातें , साथ ही साथ कोर अवधारणाओं और उन्नत उपयोग का वर्णन करते हुए एक दो ब्लॉग पोस्ट लिखे।

@markersonson शांत, टिप के लिए धन्यवाद!

@gaearon

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

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

एक कोणीय और निश्चित रूप से गैर-फ्लक्स / रिडक्स पृष्ठभूमि से आने पर उस विचार को अपने दम पर तैयार करना बहुत कठिन है। विशेष रूप से जब बहुत सारे उदाहरण अभी भी टेक्स्ट बॉक्स में हर की-अप के लिए क्रिया बनाते हैं। काश कोई न कोई उस बोली को हर Redux प्रलेखन पृष्ठ के शीर्ष पर 50px पाठ में लगा देता।

@leff सहमत। मैंने उस सटीक विचार को कुछ समय पहले संश्लेषित किया था, लेकिन यह पर्याप्त रूप से बाहर नहीं निकला। यहां तक ​​कि अगर आप इतिहास प्रबंधन के लिए Redux का उपयोग कर रहे हैं, तो अक्सर एक बहुत ही अल्पकालिक स्थिति होती है, जिसे आपके Redux शैली के राज्य प्रबंधन को बोझ करने की आवश्यकता नहीं होती है।

यह जरूरी नहीं है कि उन लोगों के लिए एक आश्चर्य हो, जिनके पास काम करने का अवसर था, उदाहरण के लिए एक परिपक्व डेस्कटॉप ऐप जो अमीर पूर्ववत / फिर से करता है। लेकिन Redux के माध्यम से इन विचारों के लिए आने वाले नए लोगों के महासागरों के लिए, यह एक रहस्योद्घाटन होगा।

@bgnorlov यह एक अच्छी बात है कि

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

मैं सबसे महत्वपूर्ण बात यह ध्यान रखना चाहूंगा कि सभी सामान्यीकृत स्थिति को Redux (यानी किसी भी चीज़ को देखने के लिए एक साथ मिलाने की आवश्यकता है) को डाल देना आसान होगा। राज्य जिसे किसी भी चीज़ के साथ जुड़ने की आवश्यकता नहीं है, वह शायद आपको कठिनाई पैदा किए बिना Redux के बाहर रह सकता है, लेकिन यह आमतौर पर Reddit में डालने के लिए चोट नहीं पहुंचाता है।

FWIW, डॉक्स बताते हैं कि हर चीज को Redux में नहीं जाना है, प्रति http://redux.js.org/docs/faq/OrganizingState.html#organizing -state-only-redux-state।

Redux "के लिए उपयुक्त" क्या है, इस बारे में हाल ही में ऑनलाइन काफी चटकारे लिए गए हैं। कुछ लोग Redux में शाब्दिक रूप से सब कुछ डालने से लाभ देखते हैं, दूसरों को यह पता चलता है कि बहुत अधिक परेशानी हो सकती है और केवल सर्वर से प्राप्त डेटा को संग्रहीत करना चाहते हैं। इसलिए, यहाँ निश्चित रूप से कोई नियम नहीं है।

हमेशा की तरह, अगर लोगों के पास डॉक्स को बेहतर बनाने के लिए विचार हैं, तो पीआर का पूरी तरह से स्वागत है :)

यदि आपको कभी भी reducers का पुन: उपयोग करने की आवश्यकता होती है और आपके redux राज्य में "सब-स्टेट्स" आवंटित करने में सक्षम हो, तो मैंने इसे आसानी से करने के लिए एक प्लगइन विकसित किया (प्रतिक्रिया एकीकरण के साथ)

https://github.com/eloytoro/react-redux-uuid

@eloytoro IMO अगर आपको रिड्यूसर से परेशानी है, तो आपको प्रोजेक्ट में एक मुद्दा खोलना चाहिए ... लंबे समय से पहले यह अस्वीकार्य डिजाइन अभ्यास बन जाएगा क्योंकि लोग पुन: प्रयोज्य reducer / एक्शन सीखते हैं निर्माता पैटर्न।

@eloytoro मैं ऐसा ही कुछ लिखने जा रहा था। संदर्भ के लिए बहुत बहुत धन्यवाद!

@ jedwards1211 मुझे लगता है कि आपको गलत विचार मिला। मैंने किसी भी तरह से उनके साथ तीसरे पक्ष के reducers या मुद्दों का उल्लेख नहीं किया है, बस यह दिखाने की कोशिश कर रहा हूं कि कैसे मेरे स्निपेट reducers को गतिशील आकारों के साथ संग्रह में पुन: प्रयोज्य बनाने के लिए समस्या को हल कर सकते हैं

@ वेवस को उम्मीद है कि यह आपके लिए काम करेगा

@eloytoro आह, कि अधिक समझ में आता है।

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

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

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

@ mib32 आप सही हो सकते हैं! उम्मीद है कि लोग आखिरकार रिएक्ट में अच्छे एनीमेशन को क्राफ्ट करने की आदत डाल लेंगे।