घटक राज्य बनाम Redux स्टोर

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

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

शुरुआत करने के लिए, पहले रिएक्ट पर ध्यान दें।

प्रतिक्रिया के दो प्रकार के घटक होते हैं: -

  1. स्मार्ट घटक
  2. गूंगा अवयव - जिसे प्रस्तुतिक घटक भी कहा जाता है

जिस तरह से मैं उन दोनों के बीच अंतर करता हूं: -

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

उदाहरण के लिए: - मान लें कि हमारे पास एक ई-कॉमर्स एप्लिकेशन है जहां हमारे पास उत्पाद सूची पृष्ठ है जो उत्पादों की सूची प्रदर्शित करता है।

इस परिदृश्य में, एक कंकाल या एक नंगे लेआउट में निम्नलिखित उच्च स्तर के घटक होंगे: -


 <हैडर />
 <साइडमेनू />
 
 

यहां ProductContainer घटक उत्पादों की एक सूची प्राप्त करने पर ध्यान केंद्रित करेगा और फिर प्रत्येक उत्पादों के माध्यम से पुनरावृत्ति करेगा और प्रत्येक उत्पाद घटक को प्रस्तुत करेगा।

यहाँ पर हम ProductContainer को Smart Component कह सकते हैं क्योंकि यह घटक उस स्थिति को रखता है जो इस मामले में उत्पादों की एक सूची है।

उत्पाद घटक के लिए नमूना कोड जो हमारा प्रेजेंटेशनल घटक है वह कुछ इस तरह दिखाई देगा: -

उपरोक्त एक प्रस्तुतिकरण घटक है, क्योंकि यह केवल डेटा प्रदर्शित करने के लिए ज़िम्मेदार है और यह उस डेटा को मूल घटक से प्रॉप्स के रूप में प्राप्त करता है।

इसलिए निष्कर्ष में कि अगर कोई घटक राज्य को धारण करता है और उसमें हेरफेर करता है, तो यह एक स्मार्ट घटक है और यदि कोई घटक सिर्फ डेटा प्रदर्शित करता है, जो उसे प्रॉप्स के रूप में प्राप्त होता है, तो इसे एक प्रेजेंटेशनल घटक के रूप में वर्गीकृत किया जाता है।

दान अब्रामोव का एक सुनहरा उद्धरण जो इस पर प्रकाश डालता है:

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

यह कॉम्पोनेन्ट स्टेट के बारे में था, अगला सवाल जो हमारे दिमाग में आता है वह यह है कि कौन सा डेटा रिडक्स स्टोर के अंदर जाना चाहिए।

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

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

इस कार्ट जानकारी को बहुत सारे पृष्ठों पर और हेडर घटक जैसे घटकों पर बनाए रखने की आवश्यकता होती है, जहाँ हम कार्ट की गिनती, चेकआउट पृष्ठ और भुगतान पृष्ठ दिखाएंगे।

यह एक स्पष्ट संकेत है कि कार्ट में जोड़े गए उत्पादों को घटक स्थिति के बजाय रेडक्स स्टोर के अंदर जाना चाहिए।

यह हमें घटकों के बीच एक और अंतर लाता है: -

  1. कोई भी घटक जो Redux स्टोर के साथ जुड़ा हुआ है उसे कंटेनर घटक के रूप में वर्गीकृत किया गया है। यह कार्रवाई को प्रेषित कर सकता है और reducers के माध्यम से redux स्टोर को अपडेट कर सकता है।
  2. जो घटक Redux स्टोर से कनेक्ट नहीं हैं, वे घटक फ़ोल्डर के अंदर चले जाते हैं। अब इन घटकों को आगे स्मार्ट और डंबल के रूप में भी वर्गीकृत किया जा सकता है, क्योंकि भले ही वे रिडक्स स्टोर से कनेक्ट नहीं हैं, फिर भी वे कुछ API कॉल करके राज्य को पकड़ सकते हैं और उस डेटा को केवल उस घटक के जीवनकाल तक बनाए रखना।

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

ShoppingApp घटक एक कंटेनर घटक के रूप में वर्गीकृत कर सकता है और प्रारंभिक कार्ट काउंट और लॉगिन जानकारी प्राप्त करने के लिए जिम्मेदार है।

हम Redux की कार्यप्रणाली और MapStateToProps, एक्शन क्रिएटर्स, डिस्पैचर्स जैसे विभिन्न रिडक्स फ़ंक्शंस में गहराई से नहीं जा रहे हैं।

इन सभी चीजों को Redux डॉक्स से पढ़ा जा सकता है।

अंतिम एप्लिकेशन के लिए मॉकअप जो हम बना रहे हैं वह कुछ इस तरह होगा: -

रिड्यूसर, घटकों, कंटेनरों को जोड़ने के बाद, मेरी निर्देशिका संरचना कैसी होगी इसका एक उदाहरण है: -

यहाँ पर ShoppingApp Redux स्टोर से जुड़ा होगा और प्रारंभिक कार्ट डेटा प्राप्त करने के लिए एक एक्शन भेजेगा। यह ShoppingApp को कंटेनर घटक बनाता है।

ShoppingApp इस डेटा को हेडर कंपोनेंट में पास करेगा।

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

Redux शब्दों में ProductContainer एक कंटेनर घटक के रूप में योग्य नहीं है क्योंकि यह Redux स्टोर से जुड़ा नहीं है, लेकिन चूंकि इसमें अपना स्वयं का घटक राज्य है जो इसे एक स्मार्ट घटक के रूप में वर्गीकृत करता है।

उपरोक्त उदाहरण के लिए पूरा कोड निम्न कोडैंडबॉक्स यूआरएल पर पाया जा सकता है: -

कुछ स्टाइल के लिए मैंने रिएक्शन मैटेरियल-यूआई जोड़ा है।

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

आगे की पढाई

  • प्रस्तुति और कंटेनर घटक
  • Redux प्रलेखन
  • कंटेनर घटक