Redux: जब एक कार्रवाई कई reducers से संबंधित है, तो CombReducer पर एक चिंता

क्या आप विस्तृत कर सकते हैं कि आपको क्यों लगता है कि combineReducers इस मामले में मददगार नहीं है? दरअसल, डेटाबेस जैसी स्थिति के लिए, आप अक्सर एक ही reducer चाहते हैं (और फिर UI स्थिति के लिए अन्य reducers, उदाहरण के लिए, चयनित आइटम, आदि)।

यह सभी देखें:

https://github.com/rackt/redux/tree/master/examples/real-world/reducers
https://github.com/rackt/redux/blob/master/examples/async/reducers

प्रेरणा के लिए।

आपके द्वारा बताया गया पहला छूट मेरे मामले के समान है, requestType दोनों reducers में संभाला जाता है।
https://github.com/rackt/redux/blob/master/examples/real-world/reducers/paginate.js#L28

बंटवारे वाले reducers को बनाए रखना आसान हो जाता है जब दो reducers को earch दूसरों से अलग किया जाता है। लेकिन जब वे एक ही कार्रवाई के लिए सौंप रहे हैं, यह करने के लिए होता है:

• इस तरह की कार्रवाई के लिए, मुझे इसे कई रीड्यूसर (या मेरे ऐप के बढ़ने के बाद फाइलें) में बनाए रखना होगा। हमारे वर्तमान कोडबेस में हमने पहले से ही 5 स्टोरों को एक ही कार्रवाई को संभालते हुए देखा था, इसे बनाए रखना थोड़ा कठिन है।
• कुछ मामलों में, एक कम करने से एक संदेश चलती की तरह दूसरे से डेटा पर निर्भर हो सकता ( unread करने के लिए message , या यहाँ तक से एक नया धागा के रूप में संदेश को बढ़ावा देने के message करने के लिए thread )। इसलिए मुझे अब किसी अन्य reducer से डेटा प्राप्त करने की आवश्यकता हो सकती है।

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

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

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

लेकिन आप सही हैं ऐसे मामले हैं जहां यह बहुत अच्छी तरह से काम नहीं करता है। मैं कहता हूँ कि वे अक्सर एक उप-राज्यीय मॉडल के लक्षण हैं। उदाहरण के लिए,

कुछ मामलों में, एक रिड्यूसर दूसरे से डेटा पर निर्भर हो सकता है (जैसे किसी संदेश को अपठित से संदेश में ले जाना या संदेश से धागे तक एक नए सूत्र के रूप में प्रचार करना)

एक समस्या का एक लक्षण है। यदि आपको अपने राज्य के अंदर सामान को स्थानांतरित करना है, तो शायद राज्य के आकार को अधिक सामान्य बनाने की आवश्यकता है। { readMessages, unreadMessages } बजाय आपके पास { messagesById, threadsById, messageIdsByThreadIds } । संदेश पढ़ा? ठीक है, टॉगल state.messagesById[id].isRead । एक सूत्र के लिए संदेश पढ़ना चाहते हैं? state.threadsById[threadId].messageIds पकड़ो, फिर messageIds.map(id => state.messagesById[id]) ।

जब डेटा सामान्यीकृत होता है, तो आपको वास्तव में आइटम को एक सरणी से दूसरे सरणी में कॉपी करने की आवश्यकता नहीं होती है। अधिकांश बार आप झंडे फहरा रहे होंगे या आईडी जोड़ / हटा / जोड़ / हटा रहे होंगे।

मुझे लगता है कि कोशिश करना चाहते हैं।

मैंने सिर्फ redux को आज़माने के लिए एक डेमो पेज लिखा था। मुझे लगता है कि combineReducer मेरे लिए काफी जटिलता लेकर आए। और रेपो में सभी उदाहरण combineReducer का उपयोग कर रहे हैं, क्या अब भी मौका है कि मैं एक एकल अपरिवर्तनीय डेटा ऑब्जेक्ट को एक जावास्क्रिप्ट ऑब्जेक्ट के बजाय मॉडल के रूप में उपयोग कर सकता हूं जिसमें मेरा डेटा शामिल है?

@jiyinyiyong मुझे वास्तव में यकीन नहीं है कि आप किस जटिलता के बारे में बात कर रहे हैं, लेकिन combineReducers उपयोग न करने के लिए स्वतंत्र महसूस करें। यह सिर्फ एक सहायक है। एक समान सहायक की जाँच करें

मैंने अपने combineReducers() सहायक को ज्यादातर Immutable.js का समर्थन करने के लिए लिखा था, लेकिन यह अतिरिक्त reducers ले सकता है जो रूट reducers की तरह व्यवहार करते हैं:
https://github.com/jokeyrhyme/wow-healer-bootcamp/blob/master/utils/combineReducers.js

पहला तर्क आपके राज्य के आकार से मेल खाता है और आपके द्वारा प्रदान किए जाने वाले मिलान वाले उप-रेड्यूसर के शीर्ष-स्तरीय उप-राज्यों को पास करता है। यह आधिकारिक संस्करण के समान ही है।

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

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

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

function a (state, action) { /* only sees within a */ return state; }
function b (state, action) { /* only sees within b */ return state; }
function c (state, action) { /* only sees within c */ return state; }

function ab (state, action) { /* partial state containing a and b */ return state; }
function bc (state, action) { /* partial state containing b and c */ return state; }

let rootReducer = combineReducers(
  { a, b, c },
  [ 'a', 'b', ab ],
  [ 'b', 'c', bc ]
);

क्या यह आंशिक reducers और अतिरिक्त रूट reducers के लिए PR सबमिट करने के लायक है? क्या यह एक भयानक विचार है, या यह कुछ ऐसा है जो पर्याप्त अन्य लोगों के लिए उपयोगी हो सकता है?

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

मैंने इसे मेरे लिए भी भ्रम की स्थिति पाया है। बस मेरा उपयोग मामला / समाधान यहाँ पोस्ट कर रहा हूँ।

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

मुझे निम्नलिखित मिडलवेयर के साथ इस मुद्दे के आसपास मिला:

export default store => next => action => {
  next({ ...action, getState: store.getState });
}

ताकि हर कार्रवाई action.getState() माध्यम से रूट स्टोर तक पहुंच सके।

@ rhys-vdw उस के लिए धन्यवाद! एक बहुत ही उपयोगी मिडलवेयर :)

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

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

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

हालाँकि मुझे भी लगता है कि यह इक्का होगा अगर Redux को दोनों के लिए समर्थन था - सामान्यीकृत और एम्बेडेड इकाइयां। और कोई ऐसी रणनीति चुन सकता है जो उद्देश्य के लिए उपयुक्त हो। लेकिन मुझे लगता है कि एंबेडेड एंटिटीज़ के लिए nested reducers उपयोग करना चाहिए जो Redux डॉक्स के अनुसार एक एंटी-पैटर्न है।

मुझे एक reducer में स्टोर राज्य के बाकी हिस्सों तक पहुंचना मुश्किल लगा। यह कुछ मामलों में उपयोग करने के लिए वास्तव में मुश्किल है नेस्टेड Combedededers बनाता है। अच्छा होगा यदि बाकी राज्य में .parent() या .root() या इसके बराबर एक्सेस करने की विधियाँ हों।

एक reducer में अन्य reducers के राज्य तक पहुँचने सबसे अक्सर एक विरोधी पैटर्न है।
यह आमतौर पर द्वारा हल किया जा सकता है:

• उस तर्क को Reducer से हटाकर चयनकर्ता के पास ले जाना;
• कार्रवाई में अतिरिक्त जानकारी पास करना;
• व्यू कोड को दो क्रिया करते हैं।

धन्यवाद! मैं इस से सहमत हूँ। मैं बस यह पाया कि यह अधिक जटिल हो गया है मूल स्थिति reducers में पारित करने की कोशिश के बाद :-)

हाँ, मूल राज्य को पारित करने के साथ समस्या यह है कि reducers एक दूसरे के राज्य के आकार के लिए युग्मित हो जाते हैं जो राज्य संरचना में किसी भी रिफैक्टिंग या परिवर्तन को जटिल करता है।

ठीक है, मैं स्पष्ट रूप से एक सामान्यीकृत राज्य होने के लाभों को देखता हूं और मेरे राज्य के लाल हिस्से को डीबी की तरह मानता हूं।

मैं अभी भी सोच रहा हूँ कि अगर @gaearon (हटाने के लिए संस्थाओं को फ़्लैग कर रहा है) या @ rhys-vdw का दृष्टिकोण बेहतर है (संदर्भों को हल करने और संबंधित संदर्भों को हटाने के लिए) ।

कोई विचार / वास्तविक दुनिया के अनुभव?

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

Reducers पहले से ही transitively अनुप्रयोग के लिए युग्मित हैं क्योंकि reducers क्रियाओं पर निर्भर करते हैं। आप किसी अन्य Redux एप्लिकेशन में रिड्यूसर का तुच्छ पुन: उपयोग नहीं कर सकते।

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

राज्य को क्रियाओं के मद्देनजर पास करना शायद राज्य के आकार में बदलाव को बेहतर बनाता है, लेकिन अगर अतिरिक्त राज्य की आवश्यकता है, तो सुविधाओं को जोड़ा जाता है, क्योंकि कई कार्यों को अद्यतन करने की आवश्यकता होती है।

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

@kurtharriger : ध्यान दें कि जबकि सामान्य अनुशंसित पैटर्न डोमेन द्वारा Redux राज्य की संरचना करना है, और प्रत्येक डोमेन को अलग से प्रबंधित करने के लिए combineReducers करना है, जो कि _just_ एक अनुशंसा है। अपने स्वयं के शीर्ष-स्तरीय रेड्यूसर को लिखना पूरी तरह से संभव है जो पूरे राज्य को विशिष्ट उप-रेड्यूसर कार्यों को पारित करने सहित विभिन्न चीजों का प्रबंधन करता है। अंततः, आपके पास वास्तव में केवल _one _ reducer फ़ंक्शन है, और आप इसे आंतरिक रूप से कैसे तोड़ते हैं, यह पूरी तरह से आप पर निर्भर है। combineReducers आम उपयोग के मामले के लिए सिर्फ एक उपयोगी उपयोगिता है।

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

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

हम चाहते हैं कि यह कपलिंग स्पष्ट हो। यह स्पष्ट है कि जब आप इसे मैन्युअल रूप से करते हैं और यह शाब्दिक रूप से कोड की एन लाइनें है जहां एन आपके पास कितने रीड्यूसर हैं। बस CombReducers का उपयोग न करें और उस मूल reducer को हाथ से लिखें।

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

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

जैसा कि मैं Redux सीखता हूं, मैं अपने ऐप के साथ एक दीर्घकालिक समस्या होने की कल्पना कर रहा हूं, जो कि ऐप में राज्य के आकार की तंग युग्मन है - रेड्यूसर द्वारा नहीं बल्कि mapStateToProps द्वारा - जैसे कि एक टिप्पणी पट्टी के रूप में जिसे जानना है सामान्य उपयोगकर्ता का नाम (प्रत्येक उदाहरण के लिए एक टिप्पणी reducer बनाम सामान्य reducer द्वारा कम किया जाता है।) मैं accessor तरीकों में सभी राज्य अभिगम को लपेटने के साथ प्रयोग कर रहा हूं जो इस तरह के एनकैप्सुलेशन करते हैं, यहां तक ​​कि mapStateToProps में भी, लेकिन मुझे लगता है कि मैं गलत तरीके से भौंक सकता हूं। पेड़।

@jwhiting : यह "चयनकर्ता फ़ंक्शंस" का उपयोग करने के कई उद्देश्यों में से एक है जो आपको राज्य से, विशेषकर mapStateToProps में आवश्यक डेटा निकालने के लिए है। आप अपने आकार की स्थिति को छिपा सकते हैं ताकि कम से कम स्थानों की आवश्यकता हो, जहां वास्तव में यह जानना आवश्यक है कि state.some.nested.field कहां है। यदि आपने इसे अभी तक नहीं देखा है, तो Reselect उपयोगिता पुस्तकालय, और Redux डॉक्स के कम्प्यूटिंग व्युत्पन्न डेटा अनुभाग देखें।

हाँ। यदि आपका डेटा वॉल्यूम छोटा है, लेकिन फिर भी चयन (हाथ से लिखे हुए) चयनकर्ताओं का उपयोग करने के लिए आपको Reselect का उपयोग करने की आवश्यकता नहीं है। इस दृष्टिकोण के लिए shopping-cart उदाहरण देखें।

@markerikson @gaearon जो समझ में आता है और मैं इसका पता

एक ही reducer में सभी कोड रखने वास्तव में अच्छा जुदाई नहीं है
चिंताओं। यदि आपका reducer रूट द्वारा बुलाया जाता है, तो आप इसे मैन्युअल रूप से कॉल कर सकते हैं
और स्पष्ट रूप से मूल स्थिति को पास करें जैसा कि मुझे लगता है कि आपका सुझाव है लेकिन अगर आपका
मूल reducer पदानुक्रम में CombReducers शामिल हैं आपको इसे चीरना होगा
बाहर। तो इसे और अधिक असंभव क्यों न बनाएं ताकि आपको इसे चीरने की जरूरत न पड़े
बाद में या थ्रो का सहारा लेना चाहिए जैसा कि ज्यादातर लोग करते हैं?
शनिवार, 16 अप्रैल, 2016 को 8:27 बजे जोश व्हाट्सएप नोटिफिकेशन @github.com
लिखा था:

@markerikson https://github.com/markerikson @gaearon
https://github.com/gaearon जो समझ में आता है और मैं उसका पता लगाऊंगा,
धन्यवाद। कुछ भी बाहर के लिए mapStateToProps में चयनकर्ताओं का उपयोग करना
घटक की प्राथमिक चिंता (या शायद सभी राज्य पहुंच के लिए) ढाल होगी
विदेशी राज्य आकार में परिवर्तन से घटक। मैं एक रास्ता खोजना चाहूंगा
मेरी परियोजना में राज्य कड़ाई से लागू करने के लिए, हालांकि,
ताकि कोड अनुशासन केवल इसके लिए रक्षक और स्वागत योग्य न हो
वहाँ सुझाव।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/reactjs/redux/issues/601#issuecomment -210940305

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

चूँकि हम पैटर्न और चिंताओं के पृथक्करण पर बोल रहे हैं, मैं वास्तव में संबंधित चीज़ों में चल रहा हूं, लेकिन इसके बजाय कार्यों के साथ।

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

@shadowii एक एक्शन क्रिएटर आयात करने के बाद चयनकर्ता मुझे ठीक लगता है। मैं चयनकर्ताओं के साथ कोलॉकेट करना चाहता हूं ताकि राज्य आकार के बारे में ज्ञान उन फ़ाइलों में स्थानीय हो।

अलग-अलग रिड्यूसर होने के साथ समस्या क्या है जो एक ही एक्शन टाइप को हैंडल करती है?
उदाहरण के लिए, अगर मेरे पास account और auth reducers हैं, तो वे दोनों LOGIN_SUCCESS एक्शन टाइप (पेलोड में ऑउट टोकन और अकाउंट डेटा के साथ) को संभालते हैं, प्रत्येक वे केवल राज्य के स्लाइस को ही अपडेट करते हैं। जब कोई क्रिया राज्य के विभिन्न हिस्सों को प्रभावित करती है, तो मैंने इस दृष्टिकोण का उपयोग कई बार किया।

अलग-अलग रिड्यूसर होने के साथ समस्या क्या है जो एक ही एक्शन टाइप को हैंडल करती है?

कोई समस्या नहीं है, यह एक बहुत ही सामान्य और उपयोगी पैटर्न है। वास्तव में यह _reason_ क्रियाएं मौजूद हैं: यदि क्रियाओं को 1: 1 पर पुन: व्यवस्थित करने के लिए मैप किया जाता है, तो उन सभी पर कार्रवाई करने के लिए बहुत कम बिंदु होंगे।

@ rhys-vdw मैंने आपके द्वारा पोस्ट किए गए मिडलवेयर का उपयोग करने की कोशिश की।

customMiddleare.js

const customMiddleware =  store => next => action => {
  next({ ...action, getState: store.getState });
};

और मेरे स्टोर निर्माण में मेरे पास है

import customMiddleware from './customMiddleware';

var store = createStore(
        rootReducer,
        initialState,
        applyMiddleware(
            reduxPromise,
            thunkMiddleware,
            loggerMiddleware,
            customMiddleware
        )
    );
return store;

मुझे निम्नलिखित त्रुटि प्राप्त हो रही है:

applyMiddleware.js? ee15: 49 बिना पढ़ा हुआ टाइप करें: मिडलवेयर एक फ़ंक्शन (…) नहीं है
(अनाम फ़ंक्शन) @ applyMiddleware.js? ee15: 49
(अनाम फ़ंक्शन) @ applyMiddleware.js? ee15: 48
createStore @ createStore.js? fe4c: 65
configStore @ configStore.js? ffde: 45
(अनाम फ़ंक्शन) @ index.jsx? fdd7: 25
(बेनामी फंक्शन) @ bundle.js: 1639
webpack_require @ bundle.js: 556
fn @ bundle.js: 87 (बेनामी फंक्शन) @ bundle.js: 588
webpack_require @ bundle.js: 556
(बेनामी फंक्शन) @ bundle.js: 579
(बेनामी फंक्शन) @ bundle.js: 582

@ mars76 : सबसे अधिक संभावना है कि आप कुछ सही ढंग से आयात नहीं कर रहे हैं। यदि वह वास्तव में customMiddleware.js की संपूर्ण सामग्री है, तो आप _anything_ का निर्यात नहीं कर रहे हैं। सामान्य तौर पर, आप चार बिचौलियों को applyMiddleware पास कर रहे हैं, और संभवतः उनमें से एक वैध संदर्भ नहीं है। वापस कदम, उन सभी को हटा दें, एक समय में एक को फिर से जोड़ें, देखें कि कौन सा वैध नहीं है, और यह पता लगाएं कि क्यों। आयात और निर्यात स्टेटमेंट की जांच करें, चीजों को इनिशियलाइज़ करने के लिए आप कैसे हैं, आदि की जाँच करें।

नमस्ते,

साभार @markerikson

मैंने सिंटैक्स को नीचे के रूप में परिवर्तित किया और यह अब ठीक है:

customMiddleware.js

export function customMiddleware(store) { return function (next) { return function (action) { next(Object.assign({}, action, { getState: store.getState })); }; }; } console.log(customMiddleware);

मैं कभी भी एक्शन क्रिएटर में स्टोर तक पहुंचने की कोशिश कर रहा हूं (न कि Reducer में)। मुझे एक Async कॉल करने की आवश्यकता है और स्टोर के विभिन्न हिस्सों को विभिन्न रेड्यूसर द्वारा प्रबंधित करने की आवश्यकता है।

यह मैं क्या कर रहा हूं। यकीन नहीं होता कि क्या यह सही तरीका है।

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

मेरी सबसे बड़ी चिंता यह है कि Reducers अब एक्शन क्रिएटर तरीके बुला रहे हैं।

किसी भी टिप्पणी की सराहना करें।

धन्यवाद

@ mars76 : फिर से, आपको _ _ कभी भी Reducer के भीतर से प्रेषण करने की कोशिश

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

बहुत बहुत धन्यवाद @markerikson।

मेरा बुरा।मैं redux-thunk में getState () के बारे में महसूस नहीं किया। यह मेरा काम बहुत आसान कर देता है और मेरे रिड्यूसर को शुद्ध कर देता है।

@gaearon जब आपने एक एक्शन क्रिएटर का चयन करने वाले का चयन करने का उल्लेख किया, तो क्या यह आपके दिमाग में था कि पूरे राज्य को एक्शन क्रिएटर को चयनकर्ता को सौंप दिया जाएगा, या मैं कुछ याद कर रहा हूं?

@tacomanator : FYI करें, Dan आमतौर पर इन दिनों Redux के मुद्दों में यादृच्छिक पिंग्स का जवाब नहीं देता है। बहुत सी अन्य प्राथमिकताएं।

अधिकांश समय, यदि आप एक एक्शन क्रिएटर में चयनकर्ता का उपयोग कर रहे हैं, तो आप इसे एक थंक के अंदर कर रहे हैं। थ्रो getState तक पहुंच है, इसलिए पूरे राज्य का पेड़ सुलभ है:

import {someSelector} from "./selectors";

function someThunk(someParameter) {
    return (dispatch, getState) => {
        const specificData = someSelector(getState(), someParameter);

        dispatch({type : "SOME_ACTION", payload : specificData});    
    }
}

@markersonson धन्यवाद, जो समझ में आता है। FYI कारण मैं पूछ रहा हूँ ज्यादातर सत्यापन व्यवसाय तर्क के लिए चयनकर्ताओं द्वारा प्राप्त डेटा का उपयोग करने के बारे में है क्योंकि यह एक reducer को भेजने के लिए विरोध किया है, लेकिन यह भी मुझे विचार के लिए भोजन देता है।

एक त्वरित हैक मैं एक एकल में reducers गठबंधन किया था

const reducers = [ reducerA, reducerB, ..., reducerZ ];

let reducer = ( state = initialState, action ) => {
    return reducers.reduce( ( state, reducerFn ) => (
        reducerFn( state, action )
    ), state );
};

जहां reducerA reducerZ माध्यम से व्यक्तिगत रिड्यूसर फ़ंक्शन हैं।

@brianpkelley : हाँ, यह मूल रूप से https://github.com/acdlite/reduce-reducers है ।

@markerikson आह अच्छा, पहली बार प्रतिक्रिया / redux / etc का उपयोग कर और इस समस्या को देखते हुए इस धागे को पाया। लोल के माध्यम से लगभग 1/2 रास्ते के अंत तक छोड़ दिया

हेह, निश्चित।

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

Redux- तर्क का उपयोग करते समय मेरे दो सेंट transform फ़ंक्शन में मूल स्थिति से कार्रवाई को बढ़ाने के लिए है।

उदाहरण:

const formInitLogic = createLogic({
  type: 'FORM_INIT',
  transform({ getState, action }, next) {
    const state = getState();
    next({
      ...action,
      payload: {
        ...action.payload,
        property1: state.branch1.someProperty > 5,
        property2: state.branch1.anotherProperty + state.branch2.yetAnotherProperty,
      },
    });
  },
});

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

• लाल जड़
  
  
  
  • reducers.js निर्यात हर राज्य से reducers गठबंधन करता है
  
  
  • मिडलवेयर। जे एस एक्सपोर्ट एप्लाइड मिडलवेयर सभी मिडलवेयर के लिए
  
  
  • configureStore.js CreateStore का उपयोग कर (reducers.js, middleware.js)
  
  
  • क्रियाओं .js निर्यात क्रिया जो राज्यों के फ़ोल्डर से क्रियाओं को भेजती है <== THIS
  
  
  • state1
  
  
  • initial.js इस फ़ाइल में प्रारंभिक स्थिति है (मैं एक रिकॉर्ड बनाने के लिए अपरिवर्तनीय उपयोग करता हूं)
  
  
  • क्रिया-type.js इस फ़ाइल में क्रिया प्रकार हैं (मैं कुंजी दर्पण के रूप में डैको का उपयोग करता हूं)
  
  
  • क्रिया। js इस फ़ाइल में राज्य क्रियाएँ हैं
  
  
  • reducer.js इस फ़ाइल में राज्य reducer शामिल है
  
  
  • state2
  
  
  • initial.js
  
  
  • कार्रवाई types.js
    
    ....
  
  

क्यों ?
1- हर एप्लिकेशन में 2 तरह की क्रियाएं होती हैं:

• राज्य क्रियाएँ (redux / state1 /
  
  
  
  • ऐप एक्शन (redux / actions.js) ये एक्शन कुछ ऐप लॉजिक करने की जिम्मेदारी देते हैं और स्टेट एक्शन को फायर कर सकते हैं
  
  

2- अतिरिक्त रूप से इस संरचना का उपयोग करके आप एक फ़ोल्डर पेस्ट करके और उसका नाम बदलकर एक नया राज्य बना सकते हैं;)

जब 2 रिड्यूसर को एक ही संपत्ति को बदलने की आवश्यकता होती है, तो क्या होगा?

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

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

फिर क्या?

@ Wassap124 एक ही राज्य को प्रबंधित करने के लिए दो कार्यों की आवश्यकता है?

अधिक विवरण के बिना आप "सेट त्रुटि" कार्रवाई को भेजने के लिए एक थंक का उपयोग करना पसंद कर सकते हैं।

@ rhys-vdw मैं बस थोड़ा सा फंस गया हूं, जो काफी लंबे रेड्यूसर को विभाजित करने की कोशिश कर रहा है।
और आपके सुझाव के बारे में, क्या कोई साइड इफेक्ट के नियम का खंडन नहीं करता है?

@ Wassap124 , @ rhys- combineReducers _ का उपयोग कर रहे हैं। हालाँकि, आप निश्चित रूप से अपने स्वयं के उपयोग के मामले को फिट करने के लिए अन्य reducer तर्क लिख सकते हैं - https://redux.js.org/recipes/structuringreducers/beyondcombinereducers देखें ।

यदि आप कुछ त्वरित स्रोत स्पेलुनकिंग करते हैं ...

combineReducers एक फ़ंक्शन हस्ताक्षर की तरह लौटाता है

return function combination(state = {}, action) {

https://github.com/reduxjs/redux/blob/master/src/combineReducers.js#L145 देखें

वास्तविक reducers ऑब्जेक्ट के संदर्भ में एक क्लोजर बनाने के बाद।

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

const globalReducerHandler = () => {
  return (state = {}, action) => {
    if (action.type === 'DO_GLOBAL_THING') {
      return globallyModifyState(state)
    }
    return reducers(state, action)
  }
}

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

एक अन्य reducer से एक reducer को कॉल करने के बजाय (जो कि एक एंटीपैटर्न है, क्योंकि GlobalReducerHandler का उस reducer से कोई लेना-देना नहीं है), reduceReducers , जो अनिवार्य रूप से compose reducers के लिए है (ठीक है, यह है) वस्तुतः (Action ->) मोनाड में रचना)।