Redux: चर्चा के लिए अनुरोध: Redux "बॉयलरप्लेट", लर्निंग कर्व, एब्स्ट्रैक्शन और ओपिनेटेडनेस

कुछ विचार:

• आधिकारिक रेडक्स-प्रीसेट पैकेज जिसमें रेडक्स, रिएक्ट-रेडक्स, रेडक्स-थंक पहले से ही एक साथ वायर्ड है
• dispatch(actionType, payload) एक्शन क्रिएटर्स की आवश्यकता को कम कर सकता है
• बिल्ट-इन जंपस्टेट-स्टाइल रेड्यूसर निर्माता, उदाहरण के लिए createReducer({[actionType]: (state, payload) => state}, initState)

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

मैं इसमें अपील को समझ सकता हूं, खासकर जब रेडक्स के साथ शुरुआत कर रहा हूं - लेकिन मुझे यकीन नहीं है कि इसे 'सर्वश्रेष्ठ अभ्यास बॉयलरप्लेट पैकेज' के हिस्से के रूप में बंडल करना सबसे अच्छा विचार होगा।

तो, यह हिस्सा मेरे लिए अधिक महत्वपूर्ण है (यह समस्या को हल करने के लिए इतना अधिक विचार नहीं होगा, बल्कि बाधाएं जो कम से कम मेरे लिए महत्वपूर्ण हैं):

Redux का उद्देश्य "चीजों को करने का सबसे संक्षिप्त तरीका" नहीं है, बल्कि डेटा प्रवाह को स्पष्ट और पठनीय बनाना है

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

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

महत्व की एक और बात यह है कि नए लोगों के सामने बहुत सारी चुनौतियाँ होती हैं जब वे Redux से टकराते हैं, Redux ही नहीं, बल्कि जावास्क्रिप्ट है। अन्य बड़े ढांचे जैसे कोणीय अमूर्त जावास्क्रिप्ट को ही दूर करते हैं। Redux रिड्यूसर लिखना केवल वेनिला जावास्क्रिप्ट "डिज़ाइन पैटर्न" को लागू करना है, जो नए लोगों से परिचित नहीं हो सकता है, और लोगों को इसके बजाय एक ब्लैक बॉक्स का उपयोग करने के लिए प्रेरित करेगा।

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

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

"सभी बॉयलरप्लेट्स को कम किया जाना चाहिए, चाहे कोई भी कीमत क्यों न हो" इन दिनों सॉफ्टवेयर इंजीनियरिंग समुदाय के साथ एक समस्या है ... इससे निपटना कठिन है।

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

// meta code
dispatch(ACTION);

onAction = {
  ACTION: [
    // handler 1: hide spinner here,
    // handler 2: change status there,
    // handler 3: update entity
  ],
};

अंत में मैं redux-interactions + redux-tree और मैं अब तक बहुत खुश हूं।

हमारी वर्तमान परियोजना में दृष्टिकोण:

ध्यान दें, आवेदन आवश्यकताओं के आधार पर बहुत अलग होगा :) एक बार जब हम रीयलटाइम ऑब्जेक्ट अपडेट में जोड़ते हैं, तो शायद सागा या अवलोकन योग्य थंक/वादे पर लाभ प्रदान करेंगे

• रेडक्स-थंक
• वादा मिडलवेयर
• हमारा "एपीआई रैपर", जो क्लाइंट पंख ऐप के चारों ओर एक रैपर है, service(name, method, ...opts) जो पेलोड के साथ एक एक्शन निर्माता है जो हमारे एपीआई को कॉल करने का वादा करता है (यानी वादा मिडलवेयर इसे उठाता है और x_FULFILLED भेजता है , x_PENDING , और x_REJECTED )। इसके लिए कार्रवाई का नाम भी अधिलेखित कर सकता है।

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

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

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

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

जो भी प्रासंगिक है वह मेरा सारांश है जिसे मैं गॉथिंकस्टर/रिएक्शन-रेडक्स-रियलवर्ल्ड-उदाहरण-ऐप में उपयोग किए गए पैटर्न के लिए लेकर आया हूं

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

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

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

बस कुछ विचार।

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

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

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

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

ऐसा कहा जा रहा है, मुझे लगता है कि ढांचे को सभी के लिए और अधिक सुलभ बनाने के तरीकों के बारे में बात करना एक अच्छा विचार है (नया और अनुभवी)।

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

Redux सीखने की अवस्था खड़ी हो सकती है, लेकिन एक बार जब आप अवधारणाओं को समझ लेते हैं, तो इसकी आवश्यकता होती है
अमूर्त परतें अक्सर चली जाती हैं

मैं सोच रहा हूँ, अगर ऐसा है, तो हम Redux के किन हिस्सों में सुधार करने का सुझाव दे रहे हैं? आप किन हिस्सों को हटा देंगे या उस पर सारगर्भित करेंगे, जिसमें आपको तुरंत वापस जोड़ने की आवश्यकता नहीं होगी?

यह संपूर्ण प्रतिक्रिया/रिडक्स जीवनचक्र का एक आरेख है जिसे मैंने लगभग एक साल पहले काम पर बातचीत के लिए बनाया था:

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

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

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

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

अब तक कुछ अच्छी चर्चा। लेमे ने आम "बॉयलरप्लेट" से संबंधित शिकायतों के कुछ त्वरित उदाहरण टॉस किए जो मुझे दिखाई देते हैं:

• "मुझे किसी ऑब्जेक्ट को तुरंत वापस करने के लिए 'एक्शन क्रिएटर' फ़ंक्शन क्यों लिखना है?"
• "मुझे एक साधारण नई सुविधा जोड़ने के लिए SOOO कई फाइलों को छूना है! साथ ही, मैं स्थिरांक और फ़ंक्शन नामों के लिए समान नामों को बार-बार दोहराता रहता हूं और..."
• "मुझे केवल AJAX कॉल करने के लिए इन 'मिडलवेयर' चीज़ों की आवश्यकता क्यों है?"
• "मुझे हर चीज़ के लिए स्विच स्टेटमेंट का उपयोग क्यों करना पड़ता है?"
• "मुझे इस dispatch चीज़ की आवश्यकता क्यों है? मुझे इन सभी कार्यों को काम करने के लिए क्यों लपेटना है?"

और इस प्रकार की टिप्पणियों के कुछ विशिष्ट उदाहरण:

• Redux को लागू करना थकाऊ है।
• न्यूनतम Redux सेटअप
• जम्पस्टेट रीडमे और जम्पस्टेट + रेडक्स + सीआरए - कोई प्रेषण या एक्शन निर्माता की आवश्यकता नहीं है!

और उन "बॉयलरप्लेट" चिंताओं के लिए कुछ प्रतिक्रियाओं को तुरंत टॉस करने के लिए: सूचीबद्ध पांच श्रेणियों में से, केवल " dispatch " वास्तव में _required_ है। शेष के लिए:

• आपके पास एक्शन क्रिएटर्स का उपयोग करने के लिए _have_ नहीं है, लेकिन यह निरंतरता के लिए एक अच्छा अभ्यास है (मेरी पोस्ट के अनुसार Idiomatic Redux: एक्शन क्रिएटर्स का उपयोग क्यों करें? )
• आपके पास एक्शन क्रिएटर्स, एक्शन कॉन्स्टेंट और रेड्यूसर के लिए पूरी तरह से अलग फाइल रखने के लिए _have_ नहीं है। उन सभी को एक फ़ाइल में एक साथ रखने के लिए "बतख" पैटर्न एक लोकप्रिय तरीका है। इसमें कई रेड्यूसर एक क्रिया को सुनने की क्षमता को "छिपाने" का नकारात्मक पक्ष है। Redux अंततः परवाह नहीं करता कि आपकी फ़ाइल संरचना क्या है।
• आप _can_ Redux के बाहर async कार्य पूरी तरह से करते हैं, जैसे किसी घटक में। लेकिन, डैन के विवरण के अनुसार हमें Redux में async प्रवाह के लिए मिडलवेयर की आवश्यकता क्यों है? , उस तर्क को घटकों के बाहर निकालना आमतौर पर अच्छा होता है, और मिडलवेयर Redux स्टोर तक पहुंच रखते हुए async कार्य करने के लिए एक "खामियां" प्रदान करता है।
• आपको निश्चित रूप से _don't_ को रेड्यूसर में स्विच स्टेटमेंट का उपयोग करना होगा, वे किसी दिए गए चर के लिए एकाधिक मानों को संभालने का सबसे "स्पष्ट" तरीका हैं। लुकअप टेबल, अगर/अन्य कथन, और कुछ और जो आप चाहते हैं वह ठीक है (प्रति अक्सर पूछे जाने वाले प्रश्न: क्या मुझे स्विच स्टेटमेंट का उपयोग करना है? )
• कुछ भी उपयोगी होने के लिए आपको _do_ को वास्तव में store.dispatch() पर कॉल करने की आवश्यकता है - यह Redux का एक मूल डिज़ाइन निर्णय है। एक्शन क्रिएटर्स को बांधने से उन्हें असंबद्ध चाइल्ड कंपोनेंट्स के पास भेजना संभव हो जाता है और फिर भी जब भी फंक्शन को कॉल किया जाता है, तब भी उन्हें डिस्पैच किया जाता है।

तो कुल मिलाकर, इन "बॉयलरप्लेट" चिंताओं में से लगभग कुछ भी नहीं है जो _required_ है। यह डॉक्स और "अच्छे प्रोग्रामिंग प्रथाओं" जैसे डी-डुप्लिकेटिंग कोड और चिंताओं को अलग करने के उदाहरणों का संयोजन है।

मुझे लगता है कि @markerikson द्वारा

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

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

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

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

एक अन्य समुदाय में ऐसा होने का एक उदाहरण रस्ट प्रोग्रामिंग भाषा में है। "mio" नामक रस्ट प्रोग्रामिंग भाषा के लिए एक गैर-अवरुद्ध IO लाइब्रेरी है। यह Redux की तरह ही छोटे और निम्न-स्तरीय होने पर ध्यान केंद्रित करता है। बात यह है कि, कोई भी इसे सीधे उपयोग नहीं करता है क्योंकि यह वास्तव में कठिन और बॉयलरप्लेट से भरा होगा। अधिकांश लोग टोकियो नामक एक अन्य पुस्तकालय का उपयोग करते हैं जो कि एमआईओ पर निर्मित होता है और इसे अत्यंत उपयोगी और एर्गोनोमिक बनाता है। इस तरह, जिस किसी को भी mio से प्लंबिंग की आवश्यकता है, वह सीधे इसका उपयोग कर सकता है, लेकिन जो कोई भी जल्दी से कुछ बनाना चाहता है, वह टोक्यो का उपयोग कर सकता है।

हमें भी ऐसा ही मॉडल अपनाना चाहिए।

कुछ @sunjay की टिप्पणियों पर विस्तार करने के लिए:

#775 में हाल ही में एक टिप्पणी की गई थी जो मुझे लगता है कि चीजों को अच्छी तरह से पकड़ लेती है:

Redux एक सामान्य ढांचा है जो पर्याप्त संरचना और पर्याप्त लचीलेपन का संतुलन प्रदान करता है। जैसे, यह डेवलपर्स को उनके उपयोग के मामलों के लिए अनुकूलित राज्य प्रबंधन बनाने के लिए एक मंच प्रदान करता है, जबकि ग्राफिकल डीबगर या मिडलवेयर जैसी चीजों का पुन: उपयोग करने में सक्षम होता है।

तो हाँ, Redux कई मायनों में "सिर्फ एक पैटर्न" है। मुख्य पुस्तकालय वास्तव में सुविधा-पूर्ण है - केवल वास्तविक अर्ध-नियोजित परिवर्तन प्रस्तावित एन्हांसर पुनर्गठन ( #1702, #2214 ) जैसी चीजें हैं, और संभवतः combineReducers अधिक लचीला ( #1768 , #1792 , आदि) बनाते हैं। )

Redux को बनाए हुए लगभग दो साल बीत चुके हैं, और अब हमारे पास एक बहुत अच्छा विचार है कि लोग इसका उपयोग कैसे कर रहे हैं। एक उदाहरण के रूप में, @jimbolla ने #2214 में सभी ज्ञात स्टोर एन्हांसर्स की एक सूची एकत्र की, और वर्गीकृत किया कि वे कैसे काम करते हैं और उनका उपयोग किस लिए किया जाता है। मैं अभी भी Redux की सादगी और लचीलेपन का बहुत बड़ा प्रशंसक हूं, लेकिन मुझे Redux के शीर्ष पर कुछ अभी भी मुहावरेदार सार देखना अच्छा लगेगा जो सामान्य उपयोग को सरल करेगा और लोगों के लिए समस्याओं का समाधान करेगा।

अर्ध-संबंधित विषयों का एक अन्य सेट, और कुछ ऐसा जिसमें मेरी एक अलग व्यक्तिगत रुचि है, " एनकैप्सुलेटेड लॉजिक / कंपोनेंट्स" के विचार हैं (प्रति "एल्म / रेडक्स के साथ स्केलेबल फ्रंटएंड" खेल का मैदान ), और "प्लग -एंड-प्ले रेडक्स सेटअप" (जैसा कि https://github.com/brianneisler/duxtape/issues/1 , https://github.com/jcoreio/redux-features/issues/7 , आदि जैसे प्रयोगों में देखा गया है)। कुछ उपयोग के मामलों के लिए वैश्विक स्थिति और ऐप सेटअप बहुत अच्छा है, लेकिन दूसरों के लिए इतना नहीं।

एक दिलचस्प संबंधित बिंदु के रूप में, @toranb ने https://github.com/ember-redux/ember-redux पर Redux के लिए एम्बर रैपर बनाने के लिए कुछ बेहतरीन काम किया है। एम्बर दुनिया "कॉन्फ़िगरेशन पर सम्मेलन" में _really_ है, और इसलिए ember-redux एक उचित डिफ़ॉल्ट स्टोर कॉन्फ़िगरेशन सेट करता है, जिसमें redux-thunk और ऐसे शामिल हैं। इस तरह का कोई तरीका मददगार हो सकता है।

तो हाँ, मैं यहाँ विभिन्न विचारों का एक पूरा समूह फेंक रहा हूँ, लेकिन वे विभिन्न तरीकों से संबंधित हैं। कुल मिलाकर, मैं Redux सीखने और उपयोग करने के लिए बाधाओं को कम करना चाहता हूं, और पूरे बोर्ड में अधिक उन्नत उपयोग के मामलों को सक्षम करना चाहता हूं।

Redux एक सामान्य API है, विशिष्ट नहीं। यह अधिक मामलों को कवर करते हुए इसे और अधिक वर्बोज़ बनाता है। इसकी शक्ति जटिल सॉफ्टवेयर में है, जबकि कोई भी नया या सरल प्रोजेक्ट यह आवश्यकता के दायरे से बाहर है।

हालाँकि आप सामान्य API के शीर्ष पर विशेषज्ञताएँ बना सकते हैं। उदाहरण के लिए, मैं https://github.com/acdlite/redux-actions का उपयोग करता हूं जो सामान्य मामलों के लिए बॉयलरप्लेट को कम करता है। मैं अभी भी redux की पूरी शक्ति का उपयोग करता हूं और बस उस इंटरफ़ेस का होना मेरी आवश्यकताओं के लिए पर्याप्त नहीं होगा।

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

https://egghead.io/courses/getting-started-with-redux
https://egghead.io/series/build-react-applications-with-idiomatic-redux

संदर्भ: अमूर्तता का स्पेक्ट्रम: https://www.youtube.com/watch?v=mVVNJKv9esE

जैसा कि उल्लेख किया गया है - redux-actions कुछ बॉयलरप्लेट को हटाने में काफी अच्छा है, .toString संलग्न करके समीकरण से स्थिरांक को हटाना वास्तव में एक साफ विचार है जो मुझे पसंद है, हालांकि मैं redux-actions का उपयोग करने के बजाय इस तर्क को स्वयं लिखना पसंद करता हूं

इम्हो एक अंतर्निर्मित तंत्र होना चाहिए ( subscribe का कॉलबैक तर्क?) प्रेषण क्रियाओं को देखने के लिए स्ट्रीम (मुझे पता है कि यह एक मिडलवेयर में किया जा सकता है, लेकिन यह उपयोग के मामले को काफी सीमित कर रहा है, क्योंकि इसका उपयोग नहीं किया जा सकता है बाहर, यानी घटकों द्वारा या connect )

मैं अक्सर दूसरों को redux सिखाता हूँ और यह निम्नलिखित कारणों से काफी कठिन हो सकता है:

• कई मूविंग पार्ट्स: स्टोर, स्टेट, रिड्यूसर, एक्शन क्रिएटर्स, एक्शन, एसिंक एक्शन, मिडलवेयर, कनेक्टेड कंपोनेंट्स
• पुस्तकालय। एक साधारण ऐप के लिए जो आपको एक आरईएसटी एपीआई से बात करता है: रेडक्स, प्रतिक्रिया-रेडक्स, रेडक्स-थंक (या अन्य) + अतिरिक्त पुस्तकालय यदि आप चीजों का परीक्षण करना चाहते हैं
• आपको कितने स्थानों पर कोड डालना है (देखें _moving part_)

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

आम तौर पर मेरा मानना ​​​​है कि कई चलती भागों से बहुत निराशा होती है।

यहाँ कुछ विचार हैं जो मेरे पास थे। जिनमें से सभी को रेडक्स के शीर्ष पर बनाया जा सकता है ताकि यह वैसे ही रह सके।

• रिएक्ट रेडक्स जैसी लाइब्रेरी प्रदान करें जो अतिरिक्त रूप से निर्मित एसिंक्स क्रियाओं के लिए समर्थन के साथ आता है।
• बहुत सी async क्रियाएँ REST API से बात कर रही हैं, इसलिए उसके लिए एक मुहावरेदार मिडलवेयर प्रदान करें
• कनेक्ट का उपयोग करने के बजाय स्मार्ट घटकों को वास्तविक घटकों के रूप में लिखें। फिर वे अपनी render विधि में गूंगा घटकों को प्रस्तुत कर सकते हैं
• कंटेनर कंपोनेंट्स_, _स्मार्ट कंपोनेंट्स_, _डंब कंपोनेंट्स_, _एक्शन क्रिएटर्स_ और _रेड्यूसर_ के लिए एक स्केलेबल फ़ाइल लेआउट निर्धारित करें।
• कोड उत्पन्न करने के लिए एक _redux-cli_ प्रदान करें जैसे redux action loadUsers
• रेडक्स-सागा या रेडक्स-अवलोकन योग्य जैसे एसिंक परत पर मानकीकृत करें और इसे दस्तावेज़ों में शामिल करें (अधिकांश रेडक्स मामलों के लिए परामर्श करने के लिए _one_ जगह होना अच्छा होगा)
• विस्तारित भाषा सुविधाओं के लिए डिफ़ॉल्ट (जैसे डेकोरेटर (@connect)) या टाइपस्क्रिप्ट विशेष रूप से मैपस्टेटटॉपप्रॉप्स और मैपडिस्पैचटॉप्रॉप्स में चीजों को कम वर्बोज़ बनाने के लिए (mobx को डेकोरेटर की आवश्यकता होती है और सिंटैक्स सीधा होता है)

टी

सहमत, redux-actions कुछ सरल एब्स्ट्रैक्शन का एक अच्छा उदाहरण है जो बॉयलरप्लेट को हटा देता है।

मुझे यह पूछने दें: क्रिएट-रिएक्ट-ऐप में react-scripts पैकेज है, जिसमें बैबेल और वेबपैक कॉन्फ़िगरेशन पूर्व-निर्मित हैं, और अंतर्निहित समझदार डिफ़ॉल्ट के एक समूह के साथ आता है। संबंधित redux-scripts पैकेज कैसा दिख सकता है?

मैं redux-thunk बारे में कुछ अन्य (नकारात्मक) टिप्पणियों से सहमत हूं। मैं इसे शुरुआती लोगों को नहीं सुझाऊंगा (मैं शायद अब इसकी बिल्कुल भी सिफारिश नहीं करूंगा):

1. ऐसा लगता है कि जादू शुरू हो गया है।
2. यह वास्तव में इतना बॉयलर-प्लेट नहीं लेता है। एक अधिक जटिल एसिंक प्रक्रिया को देखते हुए, प्रॉप्स से dispatch प्राप्त करना और इसे कोड का केवल एक छोटा सा हिस्सा होना।
3. इसका परिणाम एक्शन क्रिएटर्स में होता है जिसे आप एक साथ बड़े वर्कफ़्लोज़ में नहीं बना सकते हैं।
4. एक आखिरी बात यह है कि मैं इसके बारे में बहुत अच्छी तरह से स्पष्ट नहीं कर सकता कि रेडक्स शैली को पुस्तकालय की तुलना में अधिक ढांचे में बनाया जा सकता है: आप पुस्तकालय में कॉल करने के बजाय अपने कोड को कॉल करने के लिए ढांचे पर भरोसा करते हैं।

हमने रिएक्ट-नेटिव एप्लिकेशन में इसका बहुत अधिक उपयोग किया, और यह ज्यादातर उपयोगी था, लेकिन हमें रेडक्स-थंक एक्शन क्रिएटर्स को प्रभावी ढंग से void लौटाने के कारण एक साथ क्रियाओं को लिखने में परेशानी हुई (सोचें "सफल लॉगिन के बाद प्रोफाइल लोड करें")

यह लोगों को यह सोचने के लिए प्रोत्साहित करता है कि "कुछ भी करने का एकमात्र तरीका dispatch तुरंत प्रतिक्रिया ईवेंट हैंडलर/कॉलबैक से है"। और चूंकि हम connect से react-redux का उपयोग कर रहे थे और mapDispatchToProps पर बहुत अधिक झुकाव कर रहे थे, हम भूल गए कि हमारे ईवेंट हैंडलर केवल सादे कार्य हो सकते हैं ।

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

@ बोधी : redux-thunk 11 लाइन लंबी है, और वहां कुछ अच्छी व्याख्याएं हैं जैसे "थंक क्या है?" . थंक्स _are_ कंपोज़ेबल टू _some_ हद तक, और मुझे लगता है कि किसी को यह बताना आम तौर पर आसान होता है "फ़ंक्शन घोषणाओं की इन दो पंक्तियों को लिखें, फिर अपनी AJAX कॉल करें और इस तरह यहां"। मेरे पास एक पोस्ट है जो Idiomatic Redux: Thinks on Thunks, Sagas, Abstraction, और Reusability पर थंक्स (और कुछ हद तक साग) के कुछ विभिन्न ट्रेडऑफ़

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

मुझे लगता है कि redux-thunk का उपयोग करना केवल अतुल्यकालिक रूप से कुछ करने के बारे में नहीं है, बल्कि कुछ ऐसा करना भी है जो वर्तमान स्थिति पर निर्भर करता है। बहुत साफ, सरल इंटरफ़ेस, और एक्शन क्रिएटर्स के उपयोग को प्रोत्साहित करता है।

बोधि: शायद थोड़ा सा विषय, लेकिन सोचा कि शायद यह ध्यान देने योग्य है कि प्रेषण शून्य नहीं लौटाता है, यह आपके आंतरिक कार्य का परिणाम देता है। इसलिए यदि आप उदाहरण के लिए एक वादा वापस करते हैं, तो आप आसानी से एक साथ क्रियाओं को श्रृंखलाबद्ध कर सकते हैं। रीडमी में रचना पर अनुभाग देखें:
https://github.com/gaearon/redux-thunk/blob/master/README.md

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

19 मार्च 2017 को 23:48 बजे बोधि नोटिफिकेशन @github.com ने लिखा:

मैं redux-thunk के बारे में कुछ अन्य (नकारात्मक) टिप्पणियों से सहमत हूं। मैं इसे शुरुआती लोगों को नहीं सुझाऊंगा (मैं शायद अब इसकी बिल्कुल भी सिफारिश नहीं करूंगा):

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

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

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

(स्पर्शरेखा जारी रखने के लिए खेद है, लेकिन...)

यह उल्लेखनीय है कि प्रेषण शून्य नहीं लौटाता है, यह आपके आंतरिक कार्य का परिणाम देता है।

हुह, बढ़िया! मान लीजिए मैंने अपनी समस्याओं को हल करने का दूसरा तरीका खोजने की कोशिश करने से पहले कभी भी दस्तावेज़ीकरण को बहुत करीब से नहीं देखा।

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

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

रेड्यूसर घटकों के लिए बाध्य नहीं हैं, वे एप्लिकेशन स्थिति का प्रतिनिधित्व करते हैं, न कि घटक राज्य , और वे एकमात्र पार्टी हैं जो वास्तव में जानते हैं कि राज्य "राज्य के साथ क्या करना है" कथन नहीं है।

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

एक से अधिक स्थानों से एकल कार्रवाई भेजने का कोई मामला भी दूर हो जाता है। आप एक्शन क्रिएटर्स को कंपोनेंट के पास रख सकते हैं जिससे एक्शन भेजने वाले कंपोनेंट को ट्रैक करना आसान हो जाता है।

DevTools में एक्शन लॉग को देखकर आप अपने ऐप के अंदर क्या हुआ ,

इस पुल-आधारित दृष्टिकोण डेटा स्वाभाविक रूप से प्रवाह की तरह पक्ष प्रभाव प्रबंधन पुस्तकालयों के साथ सही मायने में एक तरह से और ढेर बनाता है redux-saga या redux-observable ।

@aikoven हालांकि मैं इससे पूरी तरह सहमत हूं (अतीत में FETCH_USER जैसी चीजों के साथ क्या करते हैं, जो देखने में बहुत आम है (और कुछ ऐसा जो करना ज़रूरी है)। यह अधिक "कमांड-लाइक" और फिर "इवेंट-लाइक" लगता है।

@blocka हमेशा कोई न कोई घटना होती है जिसके परिणामस्वरूप नेटवर्क अनुरोध होता है। अनुरोध को FETCH_USER_STARTED और FETCH_USER_DONE / FETCH_USER_FAILED क्रियाओं में लपेटा जा सकता है, इस प्रकार राज्य में अनुरोध परिणाम समाप्त होता है।

redux-actions

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

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

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

Redux के साथ भी यही बात है। यदि आप ठीक हैं कि आपको FETCH_X_STARTED कार्रवाई की आवश्यकता है, और एक fetchX() एक्शन निर्माता, और इसे संभालने के लिए रेड्यूसर, आदि, अपना खुद का अमूर्त बनाने के लिए स्वतंत्र महसूस करें!

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

मुझे लगता है कि redux-thunk का उपयोग करना केवल अतुल्यकालिक रूप से कुछ करने के बारे में नहीं है, बल्कि कुछ ऐसा करना भी है जो वर्तमान स्थिति पर निर्भर करता है। बहुत साफ, सरल इंटरफ़ेस, और एक्शन क्रिएटर्स के उपयोग को प्रोत्साहित करता है।

सिंक्रोनस कोड के लिए redux-thunk का उपयोग करना एक अच्छा विचार नहीं है और दस्तावेज़ों में इसका उल्लेख किया जाना चाहिए।
यदि आप कई कार्यों को एक साथ लिखते हैं तो आप निश्चित नहीं हैं कि प्रेषण प्रवाह आदेश पर निर्भर नहीं है, इसलिए तर्क और परीक्षण करना कठिन है।

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

मैं इस ब्लॉग पोस्ट को बेहतर ढंग से समझने के लिए अनुशंसा करता हूं: http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thinks-on-thunks-sagas-abstraction-and-reusability/

@Machiaweliczny लेख के लिए धन्यवाद। मुझे लगता है कि मेरे लिए सवाल इस बारे में अधिक है कि आप अपना व्यावसायिक तर्क कहां रखते हैं (जैसा कि https://medium.com/@jeffbski/where -do-i-put-my-business-logic-in-a- में चर्चा की गई है- प्रतिक्रिया-रेडक्स-आवेदन-9253ef91ce1#.3ce3hk7y0)। आप यह नहीं कह रहे हैं कि आपके प्रेषण प्रवाह (थंक, महाकाव्य, गाथा, जो भी हो), को वर्तमान एप्लिकेशन स्थिति तक कभी भी पहुंच नहीं होनी चाहिए, है ना?

@dfbaskin

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

रेड्यूसर, होने के नाते (state, action) => state वह जगह है जहां "तर्क जो राज्य पर निर्भर करता है" आम तौर पर होना चाहिए। और निश्चित रूप से, एल्म आर्किटेक्चर जैसी चीजों में, ऐसे सभी तर्क "अपडेट" फ़ंक्शन (हमारे रेड्यूसर के बराबर) में हैं।

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

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

@Machiaweliczny : उस "थॉट्स ऑन थंक्स" पोस्ट के लेखक के रूप में, मैं आपको आश्वस्त कर सकता हूं कि "सिंक्रोनस काम के लिए थंक्स का उपयोग करने से बचें" जो मैं कहने की कोशिश कर रहा था उसका _opposite_ है :)

अधिक अच्छी चर्चा, लेकिन हम विषय से थोड़ा दूर जाने लगे हैं। (क्या वह बाइकशेड है जिसे मैं वहां देखता हूं? :))

मुझे मूल प्रश्नों पर वापस जाने दें:

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

इनसे निपटने के लिए हम कौन से ठोस कदम उठा सकते हैं?

गैर-विवादास्पद, कार्रवाई योग्य, अल्पकालिक कदमों के दायरे में, मैं कहूंगा:

1) स्टोर को कॉन्फ़िगर करना आसान बनाएं (शायद डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ? मुझे नहीं पता कि क्या यह अभी भी मामला है, लेकिन एल्म में "स्टार्टर ऐप" प्रकार और एक नियमित ऐप प्रकार हुआ करता था। स्टार्टर ऐप का इस्तेमाल किया गया था साधारण ऐप्स के लिए और प्रशिक्षण सामग्री में 90% मामले को कवर करने के लिए जब लोग अभी सीख रहे हैं। आज तक, मैं मानता हूँ कि मैं हस्ताक्षर के लिए डॉक्टर को देखे बिना Redux स्टोर को बुनियादी मिडलवेयर (devtools, thunks) के साथ कॉन्फ़िगर नहीं कर सकता। मुझे नहीं लगता कि बहुत से लोग यह तर्क देंगे कि नए लोगों को यह जानने की जरूरत है कि Redux कोर अवधारणाओं को सीखने के लिए स्टोर के मिडलवेयर को कैसे कॉन्फ़िगर किया जाए।

2) यह पहले से ही मामला हो सकता है, सुनिश्चित करें कि उपरोक्त "स्टार्टर स्टोर" के साथ Redux को create-react-app में जोड़ना जितना संभव हो उतना आसान है, इसलिए एक नवागंतुक के पास 2 मिनट में एक अप और रनिंग Redux ऐप हो सकता है।

मुझे लगता है कि यह हमें बहुत, बहुत दूर ले जाएगा।

संपादित करें: स्टार्टर ऐप से, मेरा मतलब ऐप बॉयलरप्लेट नहीं है, बल्कि एक "क्रिएटस्टोर" है जिसे कॉन्फ़िगर नहीं किया जा सकता है, लेकिन इसमें उचित डिफ़ॉल्ट हैं कि लोग बस आयात कर सकते हैं और इसके साथ किया जा सकता है। तब वे "वास्तविक" createStore पर आगे बढ़ सकते हैं जब वे इसे बढ़ा देते हैं।

यह वहां एक बहुत ही शानदार अवधारणा की तरह लगता है।

सोम, 20 मार्च, 2017 को सुबह 10:02 बजे फ्रेंकोइस वार्ड सूचनाएं @github.com
लिखा था:

गैर-विवादास्पद, कार्रवाई योग्य, अल्पकालिक कदमों के दायरे में, मैं कहूंगा:

1.

स्टोर को कॉन्फ़िगर करना आसान बनाएं (शायद डिफ़ॉल्ट के साथ
विन्यास? मुझे नहीं पता कि यह अभी भी मामला है, लेकिन एल्म हुआ करता था
एक "स्टार्टर ऐप" प्रकार, और एक नियमित ऐप प्रकार। स्टार्टर ऐप का इस्तेमाल के लिए किया गया था
जब लोग हों तो 90% मामले को कवर करने के लिए सरल ऐप्स और प्रशिक्षण सामग्री में
बस सीख रहा हूँ। आज तक, मैं मानता हूँ कि मैं Redux स्टोर को कॉन्फ़िगर नहीं कर सकता
के लिए डॉक्टर को देखे बिना बुनियादी मिडलवेयर (devtools, thunks) के साथ
हस्ताक्षर। मुझे नहीं लगता कि बहुत से लोग तर्क देंगे कि नवागंतुकों की जरूरत है
Redux कोर सीखने के लिए स्टोर के मिडलवेयर को कॉन्फ़िगर करने का तरीका जानने के लिए
अवधारणाएं।
2.

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

मुझे लगता है कि यह हमें बहुत, बहुत दूर ले जाएगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/reactjs/redux/issues/2295#issuecomment-287806663 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFUmCQYkUwjkCugevDBWC8TOu0HhWJTnks5rnqMWgaJpZM4MhnVF
.

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

const { makeIndicator, makePayloadAssignor } from '../shared/reducers';

const searchModule = combineReducers({
  searching: makeIndicator(c.SEARCH),
  results: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

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

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

Redux सिर्फ जावास्क्रिप्ट है। इसमें जादुई कुछ भी नहीं है।

सोम, 20 मार्च, 2017 दोपहर 12:44 बजे, मार्कस कोएत्ज़ी नोटिफिकेशन @github.com
लिखा था:

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

const { makeIndicator, makePayloadAssignor } '../shared/reducers' से;
कॉन्स्ट सर्च मॉड्यूल = कॉम्बिनेशन रेड्यूसर ({
खोज: मेकइंडिकेटर (सी.सर्च),
परिणाम: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/reactjs/redux/issues/2295#issuecomment-287820595 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AACourLpL5--NJiRzrWmKFJ31cl5DXJrks5rnqzxgaJpZM4MhnVF
.

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

यह Redux पर एक पुस्तकालय के रूप में एक बहुत ही मूल्यवान विषय है।

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

बिल्कुल सही, @blocka! मुझे लगता है कि इस संदेश को फैलाने की जरूरत है।

Redux अपने न्यूनतम दृष्टिकोण के कारण लोगों को असामान्य और बॉयलरप्लेट-ईश महसूस कर रहा है। सामान्य रूप से "ढांचे" के लिए न्यूनतम अजीब लगता है (न्यूनतम कोड, न्यूनतम सिद्धांत)।

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

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

मैंने कल इसके बारे में एक छोटा लेख लिखा था: इसे रिएक्ट या रेडक्स पर दोष न दें । बेशक मैं इस सब में गलत हो सकता हूं।

एक उन्नत पुस्तकालय के शीर्ष पर अमूर्त परतें होने की मिसाल है। अभी हाल ही में, Tensorflow ने Keras को कोर API के शीर्ष पर एक अमूर्त के रूप में लाया: http://www.fast.ai/2017/01/03/keras/।

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

मुझे लगता है कि Redux में आने वाले अधिकांश प्रथम टाइमर के लिए यह एक समान अनुभव है। Tensorflow को Redux और Keras को Jumpstate बदलें। Redux बहुत शक्तिशाली है, लेकिन अधिकांश उपयोगकर्ताओं को संभवतः उपलब्ध सभी नियंत्रणों की आवश्यकता नहीं है। सबसे अधिक संभावना है, वे एंगुलर से आ रहे हैं या एक बूटकैंप में रिएक्ट + रेडक्स सिखाया जा रहा है या विभिन्न ट्यूटोरियल देखने से। जबकि Redux को नए उपयोगकर्ताओं के लिए कम करने की आवश्यकता नहीं है, यह एक आसान अमूर्तता प्रदान करने के लिए एक विरोधी पैटर्न भी नहीं है जो संभवतः 80% संभावित उपयोग मामलों को कवर कर सकता है।

हाँ, अगर redux ठीक उसी तरह से होता, तो हम यह बातचीत नहीं कर रहे होते। भले ही redux उपयोगी हो या संरचनात्मक रूप से ध्वनि, लोग तब भी "बुरा" महसूस करते हैं जब वे इसे पहली बार सीख रहे होते हैं। ये भावनाएँ मान्य हैं।

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

उदाहरण के लिए: यहां एक शिकायत है जिसे मैं अक्सर रेडक्स के बारे में सुनता हूं (जो मुझे नहीं लगता कि अपथ्रेड का उल्लेख किया गया है): यह केवल रेडक्स का उपयोग करने के लिए पर्याप्त नहीं है, आपको प्रतिक्रिया-रेडक्स, रेडक्स-थंक, रेडक्स-एक्शन इत्यादि का उपयोग करने की भी "आवश्यकता" है। .

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

क्या package.json में पैकेजों की संख्या मायने रखती है? नहीं वाकई में नहीं।
क्या package.json में पैकेजों की संख्या लोगों के महसूस करने के तरीके को प्रभावित करती है? बिल्कुल।

अब, मुझे लगता है कि यह विश्वास करना उचित है कि रेडक्स स्वयं को वही रहना चाहिए, और एक और पैकेज ( create-redux-app या जो कुछ भी) उन्हें एक साथ इकट्ठा करना चाहिए। लेकिन हमारे हाथ में एक वास्तविक जटिलता समस्या है और यह उपयोगकर्ताओं को RTFM को बताने के लिए पर्याप्त नहीं है।

भले ही redux उपयोगी हो या संरचनात्मक रूप से ध्वनि, लोग तब भी "बुरा" महसूस करते हैं जब वे इसे पहली बार सीख रहे होते हैं। ये भावनाएँ मान्य हैं

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

Redux बिना किसी कारण के लोकप्रिय नहीं हुआ। बहुत सारे लोगों ने सोचा कि यह अच्छा लगा और दूसरों को इसकी सिफारिश की :)

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

मुझे यह विचार अच्छा लगा। यह तर्क देना संभव होगा कि मौजूदा बॉयलरप्लेट पहले से ही इसे हल कर चुके हैं, लेकिन उस समय रिएक्ट में बहुत सारे बॉयलरप्लेट भी थे, जब लोग रिएक्ट में आने की कोशिश करते समय उपकरणों से अभिभूत होने की शिकायत कर रहे थे। create-react-app इस सब का एक अच्छा जवाब था, क्योंकि इसने शुरुआती लोगों के लिए रिएक्ट _खुद_ में आने के लिए बहुत सारे चरणों को समाप्त कर दिया है।

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

मुझे विश्वास नहीं है कि Redux कोर में redux-thunk जैसे पैकेजों को शामिल करना यहां जाने का तरीका है।

केवल स्पष्टता के लिए, मैं जिस तरह के विचार फेंक रहा हूं, वे वास्तव में चीजों को सीधे मूल में शामिल करने के बारे में नहीं हैं। वे काल्पनिक रूप से किसी प्रकार का "पूर्व-निर्मित कॉन्फ़िगरेशन" या "आसानी से उपयोग की जाने वाली अमूर्त परत" बनाने के बारे में हैं जो एक अलग पैकेज या सीएलआई उपकरण या कुछ और होगा, साथ ही create-react-app ।

मुझे लगता है कि मैं जंपस्टेट/जंपसूट के लेखक के रूप में बेहतर झंकार करूंगा।

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

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

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

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

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

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

इसने शानदार ढंग से काम किया। इतना अच्छा, वास्तव में, इसने मेरे बाकी साथियों और अन्य देवों के लिए रेडक्स सीखने की प्रक्रिया को तेज कर दिया, जो इसी तरह सीखने की अवस्था से जूझ रहे थे।

हमने इसे इस तरह से डिज़ाइन किया है कि उन्नत या "मुहावरेदार" रेडक्स का उपयोग तब भी किया जा सकता है जब हमें इसकी आवश्यकता होती है, लेकिन वास्तव में इसे हमारे 90% उपयोग के मामले के लिए डिज़ाइन किया गया है।

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

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

इस चर्चा के लिए कुछ और विचार जो दिमाग में आते हैं:

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

इसमें से किसी तरह से बेहतर डॉक्स के साथ कितना हल किया जा सकता है?

ढेर सारा। जब Redux प्रलेखन की बात आती है, तो मुझे लगता है कि यह कई डिग्री के लिए AngularJS 1 के डॉक्स से भी बदतर है क्योंकि AngularJS की तरह, यह अनावश्यक रूप से क्रियात्मक है लेकिन AngularJS के विपरीत, यह "शो, डोंट नॉट" सिद्धांत को विफल करता है।

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

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

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

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

यह अपने आप खड़ा हो सकता है, चलो ❤️

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

@HenrikJoreteg , डरो मत! मैं लगभग निश्चित हूं कि हम यहां जिस चीज की चर्चा कर रहे हैं, वह कभी भी मूल को बदलने वाली नहीं है। कोर फीचर पूर्ण है और अपने आप खड़ा है। :)

ढेर सारा। जब Redux प्रलेखन की बात आती है, तो मुझे लगता है कि यह कई डिग्री के लिए AngularJS 1 के डॉक्स से भी बदतर है क्योंकि AngularJS की तरह, यह अनावश्यक रूप से क्रियात्मक है लेकिन AngularJS के विपरीत, यह "शो, डोंट नॉट" सिद्धांत को विफल करता है।

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

"कम अधिक है" के बारे में कुछ कहा जाना है

@Phoenixmatrix , @Sylphony : तो, एक संभावित डॉक्स सुधार कैसा दिखेगा?

व्यक्तिगत रूप से, इसे "स्टार्टर-स्टोर" रखने के ऊपर मेरे सुझावों के साथ संयोजित करने के लिए, मैं इसे दो में विभाजित कर दूंगा (2 अलग-अलग साइट/दस्तावेज़ नहीं, बल्कि 2 अलग-अलग अनुभाग)।

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

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

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

@derekperkins हम "धन्य" पुस्तकालय के बारे में आम सहमति कैसे प्राप्त करते हैं? हम कैसे तय करते हैं कि इसमें क्या चल रहा है और कौन इस पर काम करने वाला है?

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

प्रासंगिक xkcd: https://xkcd.com/927/

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

Redux में बॉयलरप्लेट को कम करना "मुझे जरूरत नहीं है" का मामला हैतो मैं इसे दूर कर दूंगा। लेकिन नवागंतुक के लिए भी, "वह हिस्सा" नाटकीय रूप से भिन्न होता है।

हेक, हमारे पास काम पर बहुत सारे (कई दर्जनों) रेडक्स ऐप्स हैं और स्टैक को कम करने के लिए एक सामान्य बॉयलरप्लेट बनाना मुश्किल है क्योंकि विभिन्न ऐप्स की अलग-अलग आवश्यकताएं होती हैं। यह तब आसान होता है जब आपके पास एक ही ऐप हो, या कुछ समान आवश्यकताओं वाले हों। यहां तक ​​​​कि छोटे भी काफी भिन्न होते हैं।

यहां विचार एक टूलकिट को एक साथ रखने का नहीं है जो सभी लोगों के लिए सभी समस्याओं का समाधान करता है। एक उदाहरण के रूप में CRA का उपयोग करना: Babel और Webpack और ESLint को कॉन्फ़िगर करने के कई तरीके हैं। सीआरए जो करता है वह उन सभी को उपयोगकर्ता की ओर से बिना किसी परेशानी के काम करने के लिए एक एकल, सुविचारित तरीका प्रदान करता है, और यह जानबूझकर कई सेटिंग्स चुनता है जो शिक्षार्थियों के लिए चीजों को बेहतर बनाती है। यह तब उपयोगकर्ता को कॉन्फ़िगरेशन का नियंत्रण लेने की अनुमति देता है _if वे चाहते हैं_।

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

इसे लगाने का यह एक अच्छा तरीका है। उठने और तेज दौड़ने के लिए कुछ
केवल redux और इस काल्पनिक विन्यास परत को स्थापित करना शामिल है? उस
बहुत ही अच्छा होगा।

एक और विचार जो मेरे पास था वह एक झंडा होगा जिसे आप देव मोड में सेट कर सकते हैं जो कर सकता है
उपयोगकर्ता के लिए वृद्धिशील सीखने के अवसरों को देखें और उजागर करें। में
इस तरह अमूर्त परत एक इंटरैक्टिव शिक्षण उपकरण के रूप में काम कर सकती है।
सोम, 20 मार्च, 2017 को शाम 4:14 बजे मार्क एरिकसन नोटिफिकेशन @github.com
लिखा था:

यहां विचार सभी समस्याओं को हल करने वाले टूलकिट को एक साथ रखने का नहीं है
सभी लोगों के लिए। एक उदाहरण के रूप में CRA का उपयोग करना: कॉन्फ़िगर करने के कई तरीके हैं
बेबेल और वेबपैक और ESLint। सीआरए जो करता है वह एकल, रायशुदा ऑफर करता है
उपयोगकर्ता के हिस्से पर बिना किसी परेशानी के उन सभी को काम करने का तरीका, और यह
जानबूझकर ऐसी कई सेटिंग्स चुनता है जो चीजों को बेहतर बनाती हैं
शिक्षार्थी यह तब उपयोगकर्ता को कॉन्फ़िगरेशन का नियंत्रण लेने की अनुमति देता है यदिवे चाहते हैं ।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/reactjs/redux/issues/2295#issuecomment-287914805 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFUmCactFzsw7etmGGP8MFK6kfNaOzTJks5rnvorgaJpZM4MhnVF
.

@sunjay मुझे पता था कि कौन सा xkcd लिंक था जो बिना क्लिक किए भी था। :)

मैं @markerikson से सहमत हूं। यह हर व्यक्ति के लिए हर किनारे के मामले को संभालने का प्रयास नहीं है। यह कोर रेडक्स देवों का एक राय वाला बयान है, "यह चीजों को काम करने का एक अच्छा तरीका है"। ऐसे समझदार डिफॉल्ट हैं जिन्हें जरूरत पड़ने पर ओवरराइड किया जा सकता है, लेकिन मैं दांव लगाऊंगा कि डिफॉल्ट्स 80% देवों के लिए काम करने वाले हैं।

यह कोर Redux पर लिखा हो भी सकता है और नहीं भी। मुझे अब भी लगता है कि जम्पस्टेट जैसी किसी चीज़ के लिए जगह है जो सीखने की अवस्था में तेजी लाने से कहीं अधिक है।

Redux सीखने की अवस्था खड़ी हो सकती है, लेकिन एक बार जब आप अवधारणाओं को समझ लेते हैं, तो अमूर्त परतों की आवश्यकता अक्सर दूर हो जाती है

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

अगर यह मेरे ऊपर होता तो मैं इसे देखना चाहता:

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

मूल रूप से, निश्चित रूप से, हालांकि इसे आधिकारिक Redux चीज़ के रूप में ब्रांड करना ठीक है।
साथ ही, मैं यह नहीं लिखूंगा। पर तुम कर सकते हो।

मेरे लिए, कुछ महीने पहले जब मैं redux सीखता हूं, तो मैं दस्तावेज़ पढ़ता हूं लेकिन बहुत अच्छी तरह समझ नहीं पाता हूं, इसलिए मैं src कोड पढ़ने के लिए 2 दिन बिताता हूं, फिर api के बारे में हर विवरण डॉक्टर स्पष्ट हो जाते हैं।

और फिर, "राज्य डिजाइन", "रेड्यूसर डिवीजन", "मिडलवेयर डिजाइन", "एसिंक सॉल्यूशन" के बारे में विचार ... अध्याय भी स्पष्ट हो जाते हैं जब मैं अगले महीने परियोजना विकसित करता हूं।

इसलिए, मुझे लगता है कि redux सीखने के लिए src कोड पढ़ना सबसे उपयुक्त कदम है, और उसके बाद ही, आप redux के वातावरण को और अधिक सुचारू रूप से समझ और खोज सकते हैं।

डिफ़ॉल्ट रूप से async समर्थन।

मेरा मतलब है कि किसी अन्य प्लगइन का उपयोग करने की आवश्यकता नहीं है जैसे कि redux-thunk, redux-saga ।

डिफ़ॉल्ट रूप से async समर्थन

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

@gaearon की टिप्पणी एकदम सही है, जिसमें यह इस बात पर प्रकाश डालता है कि स्वीप कितना व्यापक है। मैं उनके द्वारा प्रस्तावित Redux 2.0 की सटीकता और भव्यता और शक्ति को पूरी तरह से प्यार और सराहना करता हूं, और फिर भी उनमें से लगभग कोई भी सुधार मेरे लिए प्रासंगिक नहीं है!

मुझे वास्तव में वह आकर्षक लगता है।

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

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

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

हम किन समस्याओं को हल करने की कोशिश कर रहे हैं?

ऐप की वैश्विक स्थिति । आर एलियबल ए ई स्टेटिक्स डी एलीवेड यू निफाइड ई एक्स टेन्सिबल: हार्ट:

कोई भी ग्लोबल्स नहीं चाहता है। लेकिन सभी को एक चाहिए: tm:

कृपया, अभी के रूप में redux को सरल रखें। यह पैटर्न है। कुकबुक हमेशा लगभग :100 के आसपास उठेगी:

@markerikson इन विचारों को व्यवस्थित करने के लिए दस्तावेज़/स्प्रेडशीट शुरू करना एक अच्छा विचार होगा? पहले से ही कुछ अद्भुत विचार आए हैं और केवल 48 घंटे हुए हैं

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

एक बार जब मैं इसे एक सादे डेटाबेस के रूप में मानता हूं तो Redux आसान हो जाता है:

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

मेरे लिए वह सब Redux मेरे लिए है (मैं एक डेटाबेस से HTTP कॉल करने की उम्मीद नहीं करूंगा)। I/O और एसिंक्रोनस सामान के लिए, मैं इसे Redux के बाहर निष्पादित करता हूं। यह मेरे Redux स्टोर को पूर्वानुमेय रखता है। टाइप सिग्नेचर हमेशा store.dispatch(actionObject) । कोई प्रेषण कार्य नहीं है और कार्रवाई के अंदर कोई छिपा हुआ अर्थ नहीं है (उदाहरण के लिए कोई कार्रवाई भेजने से एपीआई कॉल नहीं होगी)।

@tannerlinsley : हाँ, इसके लिए जाओ।

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

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

एक बार जब मैं इसे एक सादे डेटाबेस के रूप में मानता हूं तो Redux आसान हो जाता है

मैं यही अनुशंसा करता हूं!

• अपने स्टोर को सामान्य रखें
• आप डेटा तैयार कर सकते हैं — जैसे दृश्य। इसे समर्पित रेड्यूसर द्वारा करें - फिर आपको reselect आवश्यकता नहीं है। विचार करना।
• क्रियाएँ अन्य क्रियाओं को ट्रिगर नहीं करनी चाहिए - यह आसान लग सकती है। लेकिन यह मुश्किल है अगर आपके पास componentDidMount हुक हैं। मुझे नहीं पता कि इसे कैसे हल किया जाए। इसे पदानुक्रम में ऊपर ले जाना हमेशा आसान नहीं होता है

FWIW, मैं D3.js (बिना प्रतिक्रिया के) के साथ Redux का उपयोग कर रहा हूं और यह काफी अच्छा चल रहा है। इसके कुछ उदाहरण d3-घटक में सूचीबद्ध हैं।

रिएक्ट रेडक्स बाइंडिंग के बारे में मुझे सबसे ज्यादा याद आती है connect । @gaearon की उपरोक्त रूपरेखा/दृष्टिकोण से मुझे जिस बिंदु में सबसे अधिक दिलचस्पी होगी, mapStateToProps कार्यान्वयन प्रदान करना"।

आप डेटा तैयार कर सकते हैं — जैसे दृश्य। इसे समर्पित रेड्यूसर द्वारा करें - फिर आपको फिर से चयन करने की आवश्यकता नहीं है। विचार करना।

हाँ, ट्विटर अपने स्टोर में यही करता है, कम से कम मुझे ऐसा लगता है - उनके पास entities शाखा है जिसमें डेटा मैप्स के लिए नियमित आईडी शामिल हैं और यानी timeline देखें जो मूल रूप से मुख्य फ़ीड है देखें कि कौन सी संस्थाओं की शाखा के लिए आईडी संदर्भ रखता है, लेकिन यह पहले से ही पूर्व-गणना है।

और आने वाले रिफैक्टरों में मैं यही कर रहा हूं, क्योंकि अत्यधिक गतिशील सूचियों का चयन करना है ... लंबे समय में काफी बोझिल हो क्योंकि आपको लगभग 2 स्थानों (या अधिक) को अक्सर याद रखने की आवश्यकता होती है।

@stefensuhat जब मैंने अपने दम पर Redux को लागू करने का प्रयास किया तो मैंने async क्रियाओं को संभव बनाने के लिए एक प्रॉमिस लूप का उपयोग किया। आप इसे https://github.com/iddan/delux पर देख सकते हैं

@gaearon आपकी सूची से पूरी तरह सहमत हैं! हम जिस संगठन में काम कर रहे हैं, उसमें 90% सूची के बाद हम एक रेडक्स बॉयलरप्लेट पर काम कर रहे हैं (यह भी, बतख सिद्धांतों का पालन करते हुए)। यह इस समय एक प्रारंभिक रिलीज़ है, प्रकाशित करने योग्य नहीं-तैयार।

मैं निश्चित रूप से इस अच्छे विचार में योगदान देना चाहूंगा!

@markerikson @tannerlinsley

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

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

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

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

इसके साथ ही, जब कोई पूरी सूची पर हमला करने का प्रयास करता है, तो यह भी ध्यान रखें कि रेडक्स के बाहर और यहां तक ​​​​कि रिएक्ट के बाहर भी अन्य टूल्स और ढांचे मौजूद हैं। रिएक्ट/रेडक्स के पास वैनिला फ्लक्स पर, MobX पर, VueJS पर और इसके पारिस्थितिकी तंत्र पर, कोणीय पर लाभों का एक दिलचस्प सेट है। समुदाय जो कुछ भी करता है, वह शायद इनमें से कुछ लाभों पर ध्यान केंद्रित करना चाहता है (जिनमें से कुछ @gaearon की सूची का हिस्सा हैं), और सुनिश्चित करें कि शीर्ष पर जो भी परत बनाई गई है वह पूरी तरह से बेमानी न हो। टाइम ट्रैवल डिबगिंग, मिडलवेयर इकोसिस्टम आदि जैसी बहुत सी चीजें कहीं और उपलब्ध हैं।

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

@Phoenixmatrix हाँ मेरा मतलब है कि redux में डिफ़ॉल्ट मिडलवेयर है, इसलिए हमें बाहरी उपयोग करने की आवश्यकता नहीं है। मैं

मैं वास्तव में Redux के वर्तमान कार्यान्वयन में कुछ भी गलत नहीं देखता। बॉयलरप्लेट मौजूद है लेकिन यदि आपके पास एक प्रकार की प्रणाली है तो यह वास्तव में कोई बड़ी बात नहीं है।

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

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

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

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

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

जब हम फ्रंटएंड एप्लिकेशन बनाते हैं तो हम वास्तव में क्या बना रहे होते हैं?

• हम एक वितरित प्रणाली के सदस्य का निर्माण करते हैं
• वह सदस्य केवल अधिक सामान्य प्रणाली के डेटा का एक सबसेट रखता है
• उस सदस्य के पास काफी सीमित क्षमताएं हैं (भंडारण, बैंडविड्थ, नेटवर्क स्थिरता...)

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

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

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

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

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

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

चारों ओर बहुत अधिक अच्छी टिप्पणियाँ। यहां बहुत सारे विचार हैं जिन्हें हम आगे खोज सकते हैं और उन्हें तलाशना चाहिए।

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

एक नया पैकेज बनाएं, जिसका नाम है, मुझे पता नहीं, redux-starter या कुछ और। वह पैकेज redux-actions , redux-thunk , और redux-logger और शायद एक वादा-आधारित मिडलवेयर पर निर्भर हो सकता है। यह हस्ताक्षर function createReduxStore({reducers, middleware}) {} साथ एक फ़ंक्शन प्रदान करेगा ( पहले @Phoenixmatrix की टिप्पणी के आधार पर)। मिडलवेयर को स्वीकार करने की जहमत भी नहीं उठानी चाहिए?

createReduxStore() फ़ंक्शन applyMiddleware को संभालने और रूट रिड्यूसर के लिए हॉट रीलोडिंग सेट करने के साथ-साथ Redux DevTools एक्सटेंशन को कॉन्फ़िगर करने का ध्यान रखेगा। यदि कोई मिडलवेयर प्रदान नहीं किया जाता है, तो यह डिफ़ॉल्ट रूप से शामिल लोगों को कॉन्फ़िगर करेगा। यह मेरे "प्रोजेक्ट मिनी-मेक" नमूना ऐप में ember-redux या configureStore फ़ंक्शन में स्टोर सेवा सेटअप कोड के समान लग सकता है।

यह कम से कम आरंभ करने के लिए आवश्यक सेटअप की मात्रा को कम करेगा, और उपयोगी कार्यक्षमता का एक मामूली सेट प्रदान करेगा।

हाँ, मुझे यह पसंद है (ठीक है, नए उपयोगकर्ताओं के लिए रेडक्स-एक्शन और वादा आधारित मिडलवेयर पसंद नहीं है, लेकिन मैं आपको उस पर बाइकशेडिंग के साथ मजा करने दूंगा)। मिडलवेयर को स्वीकार करने से परेशान नहीं होंगे, बस createStarterStore(reducer)।

शायद CombReducer को भी बदलें, ताकि आप बस यह कर सकें:

const store = createStarterStore({
   foo,
   bar,
   baz
});

जहां फू बार बाज रेड्यूसर हैं।

ड्रेट। बस एहसास हुआ कि "एक लाइब्रेरी फ़ंक्शन जो रूट रेड्यूसर के लिए एचएमआर सेट करता है" शायद काम नहीं करेगा, क्योंकि भले ही हमने उपयोगकर्ता को अपनी रूट रेड्यूसर फ़ाइल के पथ में जाने की इजाजत दी हो, एक या दोनों module.hot.accept() API और require(path) पुन: आयात चरण ऐसे पथ चाहते हैं जो निर्माण समय पर स्थिर रूप से विश्लेषण योग्य हों और चर नहीं। (मुझे लगता है... मैं गलत हो सकता हूं।) ओह, ठीक है।

लेकिन हाँ, createStarterStore() रूट रिड्यूसर या स्लाइस ऑब्जेक्ट को स्वीकार कर सकता है।

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

@slorber मैं उस हिस्से पर आपसे सहमत हूं।

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

लेकिन वास्तव में इस पर नहीं। कुछ लोग Redux में शामिल पैटर्न के बारे में जानते हैं, और यही कारण है कि उन्होंने इसका उपयोग करना चुना। कुछ सरल (या कम से कम सरल) का उपयोग करने का मतलब यह नहीं है कि उपयोगकर्ता अधिक कठिन कार्यान्वयन का उपयोग करने में सक्षम नहीं है। यह सिर्फ समय और प्रयास बचाता है।

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

बहुत ही रोचक चर्चा। मेरे दो सेंट एक redux उपयोगकर्ता के रूप में शुरुआती दिनों से:

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

मुझे लगता है कि यह स्पष्ट है कि "निम्न स्तर" लाइब्रेरी रेडक्स एक बड़ी सफलता रही है, और ऐप्स बनाने के लिए फीचर समृद्ध ढांचे के रूप में यह अभी तक काफी नहीं है। सावधान रहने की एक बात यह है कि जैसे-जैसे रेडक्स विकसित होता है, यह अपोलो जैसी परियोजनाओं के लिए उद्योग मानक "प्रोटोकॉल" के रूप में अपनी भूमिका को नहीं तोड़ता है।

यह अंत करने के लिए, शायद वर्तमान रेडक्स redux-core जैसा पैकेज बन सकता है, और redux खुद ही एब्सट्रैक्शन के स्तर को बढ़ाता है ताकि ऐप्स बनाने का एक अनुशंसित तरीका दिया जा सके। बेशक, रेडक्स-कोर का उपयोग करके इस redux (जैसे अपोलो, या सागा का उपयोग करने वाला कुछ?) के लिए उच्च स्तर के विकल्प हो सकते हैं ...

स्पष्टीकरण और जोर देने के लिए चीजों को बहाल करना:

इस थ्रेड के किसी भी कार्य में मौजूदा Redux लाइब्रेरी में बड़े बदलाव शामिल नहीं होंगे :) एक दस्तावेज़ सुधार पूरी तरह से संभव है, और कुछ छोटे बदलाव हो सकते हैं, लेकिन मौजूदा redux पैकेज यथावत रहेगा।

redux-starter पैकेज जैसा मैंने अभी-अभी वर्णित किया है, या "ढांचा"-वाई दृष्टिकोण डैन की रूपरेखा जैसा कुछ भी, एक नया पैकेज होगा जो redux पर निर्भर करता है।

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

आप Delux को स्टार्टर (jk) के रूप में उपयोग कर सकते हैं

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

कहने का लंबा घुमावदार तरीका: बहुत बढ़िया लगता है, मैं अंदर हूं, मुझे यकीन नहीं है कि मैं कितना योगदान दे सकता हूं (मैं कोशिश करूंगा) लेकिन आपके पास निश्चित रूप से एक जयजयकार है।

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

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

पुन: सीखने की अवस्था, राय और अमूर्तता:

अजाक्स एक ऐसा क्षेत्र प्रतीत होता है जहां नए शिक्षार्थी फंस जाते हैं, चाहे वे थंक्स, सागा या महाकाव्यों का उपयोग करना सीख रहे हों। एक ऐसा क्षेत्र जहां उन्हें अधिक कठिनाई नहीं होती है, वह है क्रियाएँ बनाना - क्योंकि वे सिर्फ सादे पुराने जावास्क्रिप्ट ऑब्जेक्ट हैं, और हमारे पास फ्लक्स स्टैंडर्ड एक्शन स्पेक द्वारा प्रदान की गई अतिरिक्त स्पष्टता है। इस सोच ने मुझे इस प्रश्न की ओर ले जाया - फ्लक्स स्टैंडर्ड अजाक्स एक्शन क्यों नहीं विकसित किया?

उदाहरण के लिए

function fetchPosts(page) {
  return {
    type: 'FETCH_POSTS_REQUEST',
    // Ajax request setup
    ajax: {
      url: `/api/posts`,
      method: 'GET',
      data: { page },

      // Optional ajax meta attributes
      meta: {
        // Amount of time to debounce the execution of the request
        debounce: 400,
        // Amount of times to retry the request on failure
        retry: 2,
        // Amount of time before timing out
        timeout: 10000,  
        // The action type that cancels the request
        cancelType: 'CANCEL_FETCH_POSTS',
        // Strategy when multiple FETCH_POSTS_REQUESTs are in flight
        resolve: 'LATEST'
      }
    }
  };  
}

अजाक्स क्रिया को मिडलवेयर द्वारा नियंत्रित किया जाएगा (जो कार्रवाई में ajax कुंजी पर प्रतिक्रिया करेगा)।

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

• आपके औसत एप्लिकेशन में आवश्यक एसिंक क्रियाओं की मात्रा में नाटकीय कमी (जैसा कि अजाक्स से संबंधित एसिंक क्रियाएं गिर जाएंगी)
• समझना आसान है क्योंकि हम केवल सादे पुराने जावास्क्रिप्ट ऑब्जेक्ट्स के साथ काम कर रहे हैं
• यह घोषणात्मक है, कार्यान्वयन विवरण महत्वपूर्ण नहीं हैं
• विभिन्न कार्यान्वयनों को बिना टूट-फूट के अंदर/बाहर किया जा सकता है
• यह मुहावरेदार Redux है (एक्शन लॉग अभी भी समझ में आता है, क्रमबद्ध आदि)

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

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

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

पूर्व कला: redux-axios-middleware

इस धागे में बहुत सी चीजें चल रही हैं।

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

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

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

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

वैसे भी, यह वह विषय नहीं है जिसके बारे में यह धागा है।

@markerikson मैं व्यक्तिगत रूप से इस redux-starter को विकसित करने में मदद करने के लिए तैयार हूं।

_हालांकि मुझे एक कूलर नाम पसंद आएगा_ :stuck_out_tongue:

कई क्रियाओं के उत्पादन में आवश्यक बॉयलरप्लेट बहुत ही एकमात्र नकारात्मक पहलू है जिसे मैं रेडक्स के साथ देखता हूं।

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

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

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

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

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

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

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

अगर मेरे पास एल्म कोड जैसा कुछ हो सकता था जिसका अनुवाद मुहावरेदार Redux में किया गया था ... अभी भी मेरा दिल धड़क रहा है।

यहाँ मेरे कुछ विचार हैं, आशा है कि मैं पिछली टिप्पणियों को नहीं दोहराऊँगा:

एक्शन क्रिएटर्स को एक्शन टाइप के रूप में इस्तेमाल किया जा सकता है

क्रियाएँ.जेएस

export function increase() {}

reducer.js

import { increase } from './actions.js';
export default handleActions({
    [increase]: (state) => state + 1
}, 0);

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

क्रियाओं को अतुल्यकालिक रूप से भेजा जा सकता है

async function a() {

}
async function b() {
}
store.dispatch(a());
store.dispatch(b()); // b() will be dispatched after a() resolves

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

रेडक्स === बॉयलरप्लेट

https://github.com/Emilios1995/redux-create-module

लेकिन मुझे लगता है कि यह फ़ंक्शन आपके जीवन को पूरी तरह से बचा सकता है।

इस धागे में चल रहे विचारों के दो अलग-अलग सेटों के बीच अंतर करना इसके लायक है:

• एक "पूर्ण-सेवा" रेडक्स-आधारित ढांचा
• रेडक्स कोर में अतिरिक्त सुविधाएं

मैं @markerikson से सहमत रेडक्स कोर अपने आप में एक ढांचा नहीं बनना चाहिए, और मैं समझता हूं कि कोई अलग पैकेज में रेडक्स-थंक और प्रतिक्रिया-रेडक्स क्यों रखना चाहता है। हालांकि, मेरा मानना ​​​​है कि रेडक्स कोर में नए "सहायक कार्यों" के लिए जगह और मिसाल दोनों हैं।

Redux का एपीआई सतह क्षेत्र काफी छोटा है: createStore , applyMiddleware , combineReducers , bindActionCreators , और compose । लेकिन इनमें से अधिकतर सुविधा कार्य हैं। Redux के काम करने के लिए केवल createStore सख्ती से आवश्यक है। इनमें से कोई भी कोर में क्यों है?

• applyMiddleware एन्हांसर्स को स्टोर करने के लिए एक सरलीकृत इंटरफ़ेस बनाता है। लेकिन इससे भी महत्वपूर्ण बात यह है कि applyMiddleware रेडक्स स्टोर में प्रभाव जोड़ने के मानक तरीके के रूप में मिडलवेयर _इंटरफेस_ का समर्थन करता है। मिडलवेयर पारिस्थितिकी तंत्र संभव है क्योंकि applyMiddleware में तुलनात्मक रूप से सरल इंटरफ़ेस है और उपयोगकर्ताओं को एक साथ कई मिडलवेयर चलाने की अनुमति देता है।

• combineReducers रेड्यूसर रचना का एक सुविधाजनक रूप प्रदान करता है। यह रेड्यूसर लिखने का एकमात्र तरीका नहीं है, लेकिन यह निश्चित रूप से अधिक उपयोगी पैटर्न में से एक है। लेकिन redux core में इसकी मौजूदगी का मतलब है कि यह सिर्फ आम नहीं बल्कि _ubiquitous_ है। मेरे द्वारा सामना किया गया प्रत्येक नॉनट्रिविअल रेडक्स ऐप रूट रेड्यूसर बनाने के लिए combineReducers का उपयोग करता है। इसका दूसरा पहलू यह है कि क्योंकि combineReducers Redux के साथ आने वाली रेड्यूसर रचना का एकमात्र रूप है, कई उपयोगकर्ता इसे रेड्यूसर रचना का एकमात्र रूप मानते हैं जो मौजूद है।

• bindActionCreators प्रेषण क्रियाओं के आसपास कुछ बॉयलरप्लेट को कम करता है। लेकिन विपरीत रूप से, bindActionCreators भी अप्रत्यक्ष रूप से बॉयलरप्लेट के लिए Redux की कुछ प्रतिष्ठा के लिए जिम्मेदार है। ऐसा इसलिए है क्योंकि bindActionCreators का मात्र अस्तित्व ही एक्शन क्रिएटर्स के उपयोग को प्रोत्साहित करता है। यह विशेष रूप से तब दिखाई देता है जब कोई एक्शन क्रिएटर्स (जो bindActionCreators द्वारा "अनुमोदित" हैं) बनाम चयनकर्ताओं (जो प्रलेखित हैं लेकिन कोई समकक्ष कोर फ़ंक्शन नहीं है) की व्यापकता की तुलना करता है। मैंने react-redux का उपयोग करते हुए कई कोडबेस देखे हैं जहां mapStateToProps हमेशा "bespoke" चयनकर्ता होता है लेकिन mapDispatchToProps हमेशा पूर्व-लिखित एक्शन क्रिएटर्स का ऑब्जेक्ट मैप होता है।

इनमें से कोई भी Redux की कार्यक्षमता के लिए आवश्यक नहीं है, फिर भी ये सभी इसकी उपयोगिता के लिए आवश्यक हैं। इन कार्यों में से कोई भी Redux के अंतर्निहित लचीलेपन को सीमित नहीं करता है, लेकिन सामान्य पैटर्न को कॉल करने योग्य कार्यों में सुधारकर वे विकल्प कम कठिन बनाते हैं। और इनमें से प्रत्येक सहायक कार्य आगे प्रश्न उठाता है:

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

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

@ आधुनिकसेरफ : सबसे पहले, आपकी टिप्पणियों के साथ-साथ

• मुख्य पोस्ट: Redux के बारे में इतना बढ़िया क्या है?
• ट्विटर थ्रेड का एक संग्रहीत संस्करण जिसके कारण पोस्ट हुई: https://storify.com/acemarke/redux-pros-cons-and-limitations
• कुछ अतिरिक्त विचार बाद में: https://twitter.com/ आधुनिकसर्फ़/status/

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

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

तो हाँ, कोई भी उन्हें "लिख सकता था", लेकिन उन्हें बनाकर, हमने लोगों को विशिष्ट तरीकों से उन विशिष्ट उपकरणों का उपयोग करने के लिए प्रेरित किया है। उस पर निश्चित रूप से सहमत हैं।

आपके पिछले तीन प्रश्नों के अनुसार:

• मैं _अनुमान_ आप कह सकते हैं कि मिडलवेयर "स्टोर एन्हांसर्स का सरलीकरण" है, हालांकि मुझे नहीं लगता कि इससे उन्हें न्याय मिलता है। बल्कि, यह एक बहुत ही विशिष्ट उद्देश्य के लिए एक स्टोर बढ़ाने वाला है। जहाँ तक अन्य स्टोर एन्हांसर-संबंधित कार्य: डैन ने कहा है कि Redux कोर का एक प्रमुख हिस्सा वह अभी भी संशोधित करना चाहता है कि कैसे एन्हांसर्स को इनिशियलाइज़ किया जाता है। स्टोर बढ़ाने वाले कार्यान्वयन को बदलने के लिए वास्तव में दो "प्रतिस्पर्धी" पीआर हैं जो बहुत लंबे समय से खुले बैठे हैं: #1706 में @jimbolla का संस्करण। यह भी ध्यान रखना दिलचस्प है कि जिम ने सभी ज्ञात स्टोर एन्हांसर्स की एक सूची को एक साथ रखा ताकि यह विश्लेषण किया जा सके कि समुदाय वास्तव में उनका उपयोग कैसे कर रहा है। मुझे पता है कि जिम के प्रस्ताव का उद्देश्य लेखकों को सामान्य रूप से देखे जाने वाले व्यवहारों को सरल बनाने में मदद करना था। तो, यह एक दिशा है जिसे आगे खोजा जा सकता है।
• रेड्यूसर संरचना और संरचना के लिए निश्चित रूप से कई अन्य पैटर्न हैं। मुझे यकीन नहीं है कि हम "आश्रित" रेड्यूसर के रूप में क्या कर सकते हैं, क्योंकि यह बहुत अधिक विशिष्ट उपयोग का मामला है और यह बहुत ऐप-विशिष्ट प्रतीत होता है। संबंधित नोट पर, लंबे समय तक, डैन ने किसी भी पीआर को बंद कर दिया था जो किसी प्रकार के तीसरे तर्क को combineReducers जोड़ने का प्रस्ताव करता था (और उनमें से एक _lot_ रहा है), लेकिन अंत में # 1768 को आगे बढ़ने की इजाजत दी गई जबकि। वह पीआर भी ठप हो गया है।
• चयनकर्ताओं के लिए सबसे आम उपयोग का मामला सीधे राज्य के बिट्स को निकालना और उन्हें नामित प्रॉप्स के रूप में पास करना प्रतीत होता है। हमें mapState लिए ऑब्जेक्ट शॉर्टहैंड सिंटैक्स जोड़ने के लिए रिएक्ट-रेडक्स के लिए एक खुला पीआर भी मिला है, और इसके लिए कई अनुरोध किए गए हैं, भले ही आप रिसेलेक्ट के createStructuredSelector साथ भी ऐसा ही कर सकते हैं।

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

जैसा कि गेरॉन ने एक बार कहा था, (मुझे याद नहीं है कि कहां ... शायद स्लैक) हम फ्लक्स पुस्तकालयों के कोआ की तरह बनने का लक्ष्य बना रहे हैं। आखिरकार, एक बार जब समुदाय अधिक परिपक्व हो जाता है, तो योजना "धन्य" प्लगइन्स और एक्सटेंशन के संग्रह को बनाए रखने की है, संभवतः एक reduxjs GitHub संगठन के तहत।

पहले अप-थ्रेड, मैंने किसी प्रकार का "आसान रेडक्स सेटअप" अमूर्त lib, या ऐसा कुछ प्रस्तावित किया था। क्या ऐसा कुछ, या कम से कम "धन्य" ऐडऑन की सूची, उन पंक्तियों के साथ पर्याप्त होगी जो आप सोच रहे हैं? (और, वास्तव में, आपने भी इस सूत्र की पहली टिप्पणी में किया था।) यदि नहीं, तो कोई अतिरिक्त प्रस्ताव या विचार?

आखिरकार, एक बार जब समुदाय अधिक परिपक्व हो जाता है, तो योजना "धन्य" प्लगइन्स और एक्सटेंशन के संग्रह को बनाए रखने की है, संभवतः एक reduxjs GitHub संगठन के तहत।

यह वही है जो मैं भी करूंगा, हालांकि मैं शायद इसे एक कदम आगे ले जाऊंगा: मैं परियोजना को एक मोनोरेपो में पुनर्गठित करूंगा, जहां वर्तमान redux पैकेज कुछ इस तरह बन जाता है @redux/core , धन्य रीसेलेक्ट और रेडक्स-एक्शन जैसे पुस्तकालयों को रेपो और नेमस्पेस में लाया जाता है, और redux पैकेज स्वयं इन सभी पैकेजों को एक ही नामस्थान में पुनः निर्यात करता है।

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

मैपस्टेट के लिए ऑब्जेक्ट शॉर्टहैंड सिंटैक्स जोड़ने के लिए हमारे पास रिएक्ट-रेडक्स के लिए एक खुला पीआर भी है, और इसके लिए कई अनुरोध हैं, भले ही आप रिसेलेक्ट के createStructuredSelector साथ एक ही काम कर सकते हैं।

मुझे लगता है कि यह आपको कुछ बताना चाहिए।

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

और हर लॉश फंक्शन अपनी _a la carte_ लाइब्रेरी में भी उपलब्ध है। import { groupBy } from "lodash" से अधिक import groupBy from "group-by" import { groupBy } from "lodash" का कोई _functional_ लाभ नहीं है। मुझे ट्री-हिलिंग से क्यों निपटना चाहिए, जब मैं बस अपनी जरूरत की चीजें स्थापित कर सकता हूं?

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

मुझे आशा है कि आप मुझे एक अलग दृष्टिकोण से अपने 2 सेंट जोड़ने में कोई आपत्ति नहीं करेंगे।

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

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

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

मुझे लगता है कि इस चर्चा को पहले ही पीट-पीट कर मार डाला गया था: https://github.com/reactjs/redux/issues/351

ओह, मुझे इसकी जानकारी नहीं थी, धन्यवाद! :+1:

ऐसा लगता है कि #351 बंद कर दिया गया था क्योंकि उस समय कोई कार्रवाई नहीं की जा सकती थी। यदि हम एक ऐसे मोड़ पर हैं जहाँ हम एपीआई निर्णयों और हमारे द्वारा उपयोग की जाने वाली भाषा पर पुनर्विचार कर रहे हैं, तो यह मेरे लिए विचार को फिर से सामने लाने का एक उपयुक्त समय है।

मैं और अधिक ठोस हो सकता हूं।

यहां मेरा विचार है कि इवेंट सोर्सिंग मुहावरों से प्रेरित एपीआई कैसा दिख सकता है:

अवधारणाओं

• देखने योग्य घटना स्ट्रीम
• Event Stream में समर्थित Events का एक अच्छी तरह से टाइप किया गया सेट है
• इवेंट स्ट्रीम को कमांड भेजता है
• एक या अधिक ग्राहक इवेंट स्ट्रीम का उपभोग करते हैं

एपीआई

import { createEventStream, createProjection } from 'redux';

// Initialize the event stream separately from the store.  This becomes the one
// true source of truth for your application.
const eventStream = createEventStream({
  // Commands are the only thing that we want to couple to the eventStream.  The 
  // set of events which may end up in an eventStream should be easy to predict.
  //
  // A definition like this supports static analysis inference well for 
  // consumers that can leverage it.
  increment: () => ({ type: 'INCREMENT' }),
  decrement: () => ({ type: 'DECREMENT' }),
});

// Multiple stores with disjoint or overlapping data can be used to consume the 
// same event stream.
const store = createProjection(eventStream, reducer, init);
const adminStore = createProjection(eventStream, adminReducer, init);

// We don't need a jargon term ("Middleware"), or a dedicated hook to handle 
// async anymore.  We just register more subscribers to the eventStream.
eventStream.subscribe(myCustomMiddleWare);
eventStream.subscribe(sendEventsToAnalytics);
eventStream.subscribe(logEventsForPlayback);

// Calls to commands can be wrapped with React Providers or container components 
// in the same way that Redux currently does.  They can also be called directly.
eventStream.increment();

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

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

मुझे निश्चित रूप से यह आभास होता है कि यह बातचीत पहले भी हो चुकी है, और इसे फिर से न खोलने की प्रबल इच्छा है। मैं यहां ज्यादा जोर से प्रेस नहीं करूंगा। (यदि कोई बेहतर संपर्क सूत्र है, तो मुझे इस वार्तालाप को कहीं और पढ़ने या जारी रखने में दिलचस्पी होगी।)

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

मैं अब भी तर्क दूंगा कि इवेंट सोर्सिंग और Redux समुदायों के लिए एक दूसरे से सीखने का अवसर है।

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

यहां तक ​​कि शब्दावली उधार लिए या एपीआई को बदले बिना, मुझे लगता है कि ऐसी जीत हैं जो हम पा सकते हैं। उदाहरण के लिए, मुझे एक स्टोर को "एक राज्य कंटेनर जिसमें करंटस्टेट" का एक "शुद्ध कार्य" है (यह से लिया गया है, या इससे घटाया गया है) एक परिशिष्ट-सूची (या एक धारा) के रूप में एक स्टोर का वर्णन करके लोगों को Redux से परिचित कराने में सफलता मिली है। क्रियाओं का"।

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

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

मुझे लगता है कि मैं इनमें से कुछ विचारों के बारे में थोड़ा उत्साहित हो रहा हूं! मुझे आशा है कि आप मुझे डंप शब्द के लिए क्षमा करेंगे।

साइड नोट: रेडक्स के लिए इवेंट-स्ट्रीम-जैसी रैपर एपीआई बनाना संभव प्रतीत होता है जो ऊपर सुझाई गई सतह को लागू करता है!

https://github.com/ajhyndman/redux-event-stream

@ajhyndman मुझे लगता है कि रैपर आपके विचार के साथ जाने का सही तरीका है

आपके द्वारा बताए गए समज़ा और लिंक्डइन इंजीनियरिंग कार्य से संबंधित, यदि अन्य लोगों ने अपाचे समज़ा के साथ डेटाबेस को अंदर-बाहर करने के लिए अद्भुत बात नहीं पढ़ी/देखी है तो कृपया ऐसा करने के लिए एक घंटे का समय

वह वीडियो कमाल है! यह वास्तव में redux रेपो के रीडमे पर धन्यवाद की सूची में दूसरा आइटम भी है।

ज़रा सुनिए सभी!

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

पुस्तकालय को केआ कहा जाता है:

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

केआ ऑपरेशन के कई अलग-अलग तरीकों का समर्थन करता है: आप इसे स्टैंडअलोन का उपयोग कर सकते हैं, रिएक्ट घटकों से जुड़ा हुआ है, रिएक्ट घटकों के ऊपर इनलाइन किया गया है या यहां तक ​​​​कि रिएक्ट घटकों से गतिशील रूप से जुड़ा हुआ है जहां चयनकर्ताओं को इनपुट रिएक्ट घटक के प्रॉप्स पर निर्भर करता है।

मैं व्यक्तिगत रूप से दो बड़े अनुप्रयोगों के साथ इसका उपयोग करता हूं: निजी पाठों के लिए एक प्रलेखन लिखने में काफी समय बिताया।

मेरे लिए इस पुस्तकालय ने हमेशा बॉयलरप्लेट को बहुत कम कर दिया है, जबकि रेडक्स के मूल में ही सही रहता है।

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

import React, { Component } from 'react'
import PropTypes from 'prop-types'
import { kea } from 'kea'

@kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

यदि आपका ऐप बढ़ता है और अधिक स्थानों को increment और decrement क्रियाओं या counter प्रोप तक

// counter-logic.js
import PropTypes from 'prop-types'
import { kea } from 'kea'

export default kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})

// index.js
import React, { Component } from 'react'
import { connect } from 'kea'

import counterLogic from './counter-logic'

@connect({
  actions: [
    counterLogic, [
      'increment',
      'decrement'
    ]
  ],
  props: [
    counterLogic, [
      'counter',
      'doubleCounter'
    ]
  ]
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

कृपया इसे आज़माएं और redux-saga और आपके द्वारा उपयोग की जा सकने वाली अन्य सुविधाओं के माध्यम से दुष्प्रभावों के बारे में अधिक देखने के लिए दस्तावेज़ पढ़ें।

केए के लिए प्रतिक्रिया अब तक अत्यधिक सकारात्मक रही है, एक मुद्दे से उद्धृत करते हुए: "अधिक लोगों को केएजेएस का उपयोग इसके रेडक्स दुनिया को एक बेहतर जगह बनाने के रूप में करना चाहिए! 👍" :)

आपके समय के लिए और यहाँ तक पढ़ने के लिए धन्यवाद! :)

अच्छा लगता है! 'increment' हालांकि वास्तव में जादू के तार पसंद नहीं हैं

क्या यह चर्चा कहीं और आगे बढ़ी? क्या Kea सबसे सही परिणाम है जिसे आम तौर पर स्वीकार किया जाता है?

@lucfranken : नहीं, चर्चा

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

मेरी टोपी यहाँ रिंग में फेंक रहे हैं। इस तरह से मैं इस मुद्दे को संबोधित करता हूं: https://github.com/HenrikJoreteg/redux-bundler

मुझे व्यक्तिगत रूप से लगता है कि यह बॉयलरप्लेट का एक बड़ा सरलीकरण और कमी है।

इस तरह मैं हाल ही में अपने द्वारा बनाई गई हर चीज का निर्माण कर रहा हूं।

मान लीजिए इससे मदद मिलेगी:
https://github.com/anish000kumar/redux-box

अरे, मेरी कंपनी में हम सिर्फ एक पुस्तकालय खोलते हैं जो नेटवर्क परत का प्रबंधन करता है और Redux से बहुत सारे बॉयलरप्लेट को हटा देता है। यह हमारे लिए सफल साबित हुआ है, लेकिन इसे स्वयं आज़माएं :

रेडक्स बॉयलरप्लेट को कम करने के लिए मेरा दृष्टिकोण यहां है

https://github.com/zhDmitry/restate

धागे के अत्यधिक विलंबित नेक्रोइंग के रूप में, कुछ समय पहले मैंने ट्विटर पर लोगों के लिए "बॉयलरप्लेट" का क्या अर्थ है, इस बारे में प्रतिक्रिया मांगी:

https://twitter.com/acemarke/status/969040835508604929

नेक्रो-थ्रेड की वापसी!

इस सूत्र में पहली टिप्पणी के मेरे संपादन के अनुसार, यहां चर्चा किए गए विचारों को हमारे Redux-Starter-Kit पैकेज में बदल दिया गया है। कृपया इसे आज़माएं और देखें कि यह आपके Redux उपयोग को सरल बनाने में कितनी मदद कर सकता है!