जैसा कि मैं रेडक्स को लागू करने में आगे बढ़ता हूं + एक जटिल जटिल ऐप में प्रतिक्रिया करता हूं जो एक पृष्ठ को लोड करने के लिए कई एपीआई अनुरोधों पर निर्भर करता है, मुझे यह तय करने में परेशानी हो रही है कि क्या यह बेहतर है कि यह एक कंटेनर घटक है पृष्ठ जो सभी एसिंक सामग्री को संभालता है और गुंबद घटकों को बना देता है, बनाम कई कंटेनर घटकों के साथ जो खुद को केवल आवश्यक डेटा के साथ ही चिंता करते हैं, साथ ही डेटा की आवश्यकता होती है। मैं आगे और पीछे इन दो पैटर्न के बीच चला गया और पाया कि वे एक पेशेवरों/विपक्ष है कि है:प्रतिक्रिया रेडक्स: अधिक कंटेनर बनाम। कम कंटेनर
- समर्थक:
अगर मैं शीर्ष पर एक ही कंटेनर घटक डाल सभी
isFetchingरंगमंच की सामग्री औरfetchSomeDependency()कार्यों को एक ही स्थान पर संभाला जा सकता है। - con: जो नकारात्मक पक्ष वास्तव में परेशान है, वह है कि मुझे अपने आप को कई घटकों के माध्यम से प्रोप और कॉलबैक आगे बढ़ाना पड़ता है, और पेड़ के बीच में कुछ घटक इस तक बंधे होते हैं।
यहाँ समस्या का एक दृश्य उदाहरण है कि पता चलता है रिश्तों की आवश्यकता रंगमंच की सामग्री के लिहाज से:
<MyContainer
data={this.props.data}
isFetchingData={this.props.isFetchingData}
fetchData={this.props.fetchData}
>
{!isFetchingData &&
<MyModal
someData={props.data}
fetchData={props.fetchData}
>
<MyModalContent
someData={props.data}
fetchData={props.fetchData}
>
<SomethingThatDependsOnData someData={props.someData} />
<SomeButtonThatFetchesData onClick={props.fetchData} />
</MyModalContent>
</MyModal>
}
</MyContainer>
आप देख सकते हैं, <MyModal /> और <MyModalContent /> अब रंगमंच की सामग्री के साथ कुछ नहीं करना है कि के साथ संबंध होने की जरूरत है यह, एक मॉडल के रूप में देखकर फिर से उपयोग किया जा सकता है और केवल एक मॉडल के स्टाइलिस्ट गुणों से चिंतित होना चाहिए।
पहले उपरोक्त प्रतीत होता था लेकिन एक बार जब मैं 100+ घटकों तक पहुंच गया तो यह सब बहुत उलझन में महसूस हुआ, और मुझे इन शीर्ष-स्तरीय कंटेनर घटकों की जटिलता को मेरी पसंद के लिए बहुत अधिक पाया गया, क्योंकि उनमें से अधिकतर (ऐप में मैं काम कर रहा हूं) 3+ एपीआई अनुरोधों से प्रतिक्रियाओं पर निर्भर करता हूं।
- समर्थक: पूरी तरह से रंगमंच की सामग्री को अग्रेषित करने की जरूरत को हटा
तब मैं कई कंटेनर की कोशिश करने का फैसला किया। यह अभी भी कुछ मामलों में ऐसा करने के लिए समझ में आता है, लेकिन यह बहुत अधिक लचीला है।
- प्रो: रीफैक्टर करने के लिए रास्ता आसान है। मैं आश्चर्यचकित हूं कि मैं कुछ भी तोड़ने के बिना घटकों को कैसे बदल सकता हूं और घटकों को दोबारा बदल सकता हूं, जबकि अन्य पैटर्न में चीजें बहुत टूट गईं।
- प्रो: प्रत्येक कंटेनर घटक की जटिलता बहुत कम है। । किसी भी घटक है कि async सामान पर निर्भर करता है हमेशा अपने आप में
isFetchingराज्य को संभालने के लिए की आवश्यकता होगी: मेरेmapStateToPropsऔरmapDispatchToPropsघटक उस में - चोर है के प्रयोजन के लिए और अधिक विशिष्ट है। यह जटिलता को जोड़ता है जो उस पैटर्न में जरूरी नहीं है जहां इसे एक कंटेनर घटक में संभाला जाता है।
तो मुख्य दुविधा है कि अगर मैं एक कंटेनर उपयोग करते हैं, मैं जड़ कंटेनर और पत्ती घटकों के बीच घटकों में इस अन-आवश्यक जटिलता मिलता है। यदि मैं एकाधिक कंटेनर का उपयोग करता हूं, तो मुझे पत्ती के घटकों में अधिक जटिलता मिलती है, और बटनों के साथ समाप्त होता है जिन्हें isFetching के बारे में चिंता करने की आवश्यकता होती है, भले ही किसी बटन को इसके बारे में चिंतित न हो।
मैं अगर किसी को भी एक तरह से दोनों विपक्ष से बचने के लिए मिल गया है जानना चाहते हैं, और यदि ऐसा है तो, "अंगूठे का नियम" क्या है आप इस से बचने के लिए का पालन करें?
धन्यवाद!
एक पठनीय समाधान पोस्ट करें:
यह लेख देखें। – Sachith