5 कारण क्यों आपको रिएक्ट एप्लिकेशन में Redux के बारे में भूलना चाहिए

मैं लगभग 3 वर्षों से रिएक्ट के साथ काम कर रहा हूं, Redux और MobX दोनों का उपयोग किया है, और मेरे पास अब तक एक प्रश्न है। फ्रंट-एंड डेवलपर्स के विशाल बहुमत क्यों दृढ़ता से मानते हैं कि Redux + Redux Saga + Reselect + 100500 अन्य पुस्तकालय जो जीवन को आसान बनाते हैं, आज तक का सबसे अच्छा समाधान है? मैं अगली परियोजना में Redux के बजाय MobX का उपयोग करने के पक्ष में 4 तर्क दूंगा।

MobX आपको क्लीनर और क्लीनर कोड लिखने देता है

चलो कोड के 2 टुकड़े बचाते हैं जो एक ही काम करते हैं। यहाँ Redux में एक Reducer जैसा दिखता है:



स्थिति बदलने के लिए, आपको संपादकों की शब्दावली में एक फ़ंक्शन को कॉल करने की आवश्यकता है:



और ज्यादातर मामलों में (हमेशा नहीं, लेकिन ये "सर्वोत्तम अभ्यास" हैं जो कई परियोजनाओं पर उपयोग किए जाते हैं) आपको इस बायलर को लिखना होगा:



फिर स्टोर को इनिशियलाइज़ करना आवश्यक होगा (इसे एक बार करने की आवश्यकता होगी, लेकिन फिर भी):



और प्रदाता के माध्यम से आवेदन में आगे हमारे प्रारंभिक स्टॉर को फेंक दें (एक बार का ऑपरेशन भी):



अब आप अपने घटकों में डेटा के साथ कुछ ऑपरेशन कर सकते हैं:



यह पता चला है कि Redux के मामले में, आपके स्टोरेज में डेटा को बदलने के लिए, आपको कुछ फ़ंक्शंस को कॉल करना होगा जो एक नया स्टेट ऑब्जेक्ट बनाएगा ... व्यक्तिगत रूप से, मेरे लिए, यह पूरी तरह बकवास लगता है। चलो MobX द्वारा की गई समान कार्यक्षमता पर एक नज़र डालें। हमारा पक्ष:



और फिर आप इसे घटक में उपयोग कर सकते हैं:



हाँ, यह सही है, कुछ कार्यों के बजाय जो वस्तुओं को संशोधित करते हैं, आप कक्षाओं, उनके गुणों और विधियों के साथ क्लासिक ओओपी दृष्टिकोण का उपयोग कर सकते हैं। अंदर सज्जाकार (@) से डरो मत, वे सिर्फ डेटा परिवर्तनों को ट्रैक करने के लिए आवश्यक कार्यक्षमता जोड़ते हैं। वैसे, डेटा भंडारण के लिए कक्षाओं के साथ एक समान दृष्टिकोण, का उपयोग Angularjs में किया जाता है (स्क्रीन यहाँ से ली गई angular.io/start/data ):

MobX आपको कम कोड लिखने देता है

इसे देखने के लिए, बस ऊपर दिए गए उदाहरण देखें। और अब, एक अंतहीन बॉयलरप्लेट लिखने के बजाय, आप अंततः आवेदन के व्यापार तर्क को लिखने पर ध्यान केंद्रित कर सकते हैं, जो अच्छी खबर है।

तीसरा, प्रदर्शन अनुकूलन

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

चौथा - कम निर्भरता

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

युपीडी। धन्यवाद MaZaAa

पांचवां कारण - सेटस्टेट को त्यागने की क्षमता

setState में कई कमियां हैं (लेख का संक्षिप्त अनुवाद जो यहां मूल में पढ़ा जा सकता है ):

1. यह अतुल्यकालिक है।

इससे अप्रत्याशित व्यवहार हो सकता है:



ऊपर स्क्रीन पर, चेतावनी 2 होनी चाहिए थी, लेकिन चूंकि सेटस्ट्रेट अतुल्यकालिक है, इसलिए यह बाद में आता है।

2. सेटस्टैट अनावश्यक घटक रेंडरर्स की ओर जाता है:

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



में। कभी-कभी अपडेट सेट करने वाले डेटा DOM रेंडरिंग में एक भूमिका नहीं निभाते हैं (उदाहरण के लिए, टाइमर)। और सभी समान, घटक प्रदान किया जा रहा है।

3. setState सभी मामलों के लिए उपयुक्त नहीं है।

ऐसे घटक हैं जो घटक जीवन चक्र के हुक / विधियों का उपयोग करते हैं और इस मामले में, न केवल एक अतिरिक्त रेंडरर घटित होगा, बल्कि इन घटनाओं (हुक) को एक ही समय में हर बार बुलाया जाएगा, जिससे अजीब व्यवहार हो सकता है।

MobX का उपयोग आपको इन कमियों से बचाएगा, क्योंकि आप पूरी तरह से सेटस्टैट को छोड़ सकते हैं:



यदि आप किसी बात से सहमत नहीं हैं या मैं कुछ समझ नहीं पा रहा हूं, तो कृपया टिप्पणियों में प्रतिवाद दें। सैंडबॉक्स से लिंक जिससे मोबक्स से स्क्रीनशॉट लिए गए हैं: codeandbox.io/s/mobxreact-s7db5 , Redux के साथ: codeandbox.io/s/oj7px08qy9