🌴 ⚽️ 👋🏼 हम Redux चयनकर्ताओं का बहुत अधिक उपयोग करते हैं 📊 🔰 🥀

जब मैं अपने साथ काम करने वाली बड़ी प्रतिक्रिया / Redux परियोजनाओं में {domain} /selectors.js फ़ाइल को देखता हूं, तो मैं अक्सर इस तरह के रिडक्स चयनकर्ताओं की एक विशाल सूची देखता हूं:

getUsers(state) getUser(id)(state) getUserId(id)(state) getUserFirstName(id)(state) getUserLastName(id)(state) getUserEmailSelector(id)(state) getUserFullName(id)(state) …

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

Redux और चयनकर्ताओं

चलो Redux को देखते हैं। वह क्या है, क्यों? Redux.js.org पढ़ने के बाद, हम समझते हैं कि Redux "जावास्क्रिप्ट अनुप्रयोग राज्य के भंडारण के लिए एक पूर्वानुमानित कंटेनर है"

Redux का उपयोग करते समय, हमें चयनकर्ताओं का उपयोग करने की सलाह दी जाती है, भले ही वे वैकल्पिक हों। पूरे राज्य से कुछ भागों को पाने के लिए चयनकर्ता सिर्फ गेटर्स हैं, अर्थात प्रपत्र के कार्य (State) => SubState । आमतौर पर हम चयनकर्ताओं को लिखते हैं ताकि हम सीधे राज्य तक न पहुँच सकें, और फिर हम इन चयनकर्ताओं के परिणामों को जोड़ या याद कर सकते हैं। उचित लगता है।

चयनकर्ताओं में गहराई से डूब गया

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

कल्पना करें कि हमारे पास एक उपयोगकर्ता मॉडल है और हम इसमें एक नया ईमेल क्षेत्र जोड़ना चाहते हैं। हमारे पास एक घटक है जो पहले firstName और अंतिम firstName इनपुट की उम्मीद कर रहा था, और अब यह एक और email प्रतीक्षा करेगा। चयनकर्ताओं के साथ कोड में तर्क के बाद, एक नया ईमेल फ़ील्ड शुरू करते हुए, लेखक को getUserEmailSelector चयनकर्ता को जोड़ना होगा और इस फ़ील्ड को घटक को पास करने के लिए उपयोग करना होगा। बिंगो!

लेकिन बिंगो है? और अगर हमें एक और चयनकर्ता मिलता है, जो अधिक जटिल होगा? हम इसे अन्य चयनकर्ताओं के साथ जोड़ देंगे, और शायद हम इस तस्वीर पर आएंगे:

 const getUsers = (state) => state.users; const getUser = (id) => (state) => getUsers(state)[id]; const getUserEmailSelector = (id) => (state) => getUser(id)(state).email;

पहला सवाल यह उठता है: getUserEmailSelector चयनकर्ता यदि getUser चयनकर्ता getUser रिटर्न देता है तो क्या मिलना चाहिए? और यह एक संभावित स्थिति है - बग, रीफैक्टरिंग, विरासत - सब कुछ इसके लिए नेतृत्व कर सकता है। आम तौर पर, त्रुटियों को संभालने या डिफ़ॉल्ट मान प्रदान करने के लिए चयनकर्ताओं का काम कभी नहीं होता है।

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

चलो मान लें कि हमने ऊपर वर्णित के रूप में getUserEmailSelector चयनकर्ता को लिखा और परीक्षण किया। हम इसका उपयोग करते हैं और घटक को राज्य से जोड़ते हैं:

 const mapStateToProps = (state, ownProps) => ({ firstName: getUserFirstName(ownProps.userId)(state), lastName: getUserLastName(ownProps.userId)(state), //   email: getUserEmailName(ownProps.userId)(state), })

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

या शायद आपको इकाई क्षेत्रों को सीधे एक्सेस करना चाहिए?

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

 const user = getUser(id)(state); const email = user.email;

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

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

डोमेन मॉडल का नेतृत्व किया जाता है। Redux - माध्यमिक

आप दो सवालों के जवाब देकर इस तस्वीर पर आ सकते हैं:

हम अपने डोमेन मॉडल को कैसे परिभाषित करते हैं?
हम डेटा को कैसे स्टोर करेंगे? (राज्य प्रबंधन, इसके लिए हम Redux * अनुवादक के नोट का उपयोग करते हैं * कि दृढ़ता परत को DDD कहा जाता है)

इस सवाल का जवाब "हम डोमेन मॉडल को कैसे परिभाषित करते हैं" (हमारे मामले में, उपयोगकर्ता), हमें redux से अमूर्त करते हैं और तय करते हैं कि "उपयोगकर्ता" क्या है और इसके साथ बातचीत करने के लिए API की क्या आवश्यकता है?

 // api.ts type User = { id: string, firstName: string, lastName: string, email: string, ... } const getFirstName = (user: User) => user.firstName; const getLastName = (user: User) => user.lastName; const getFullName = (user: User) => `${user.firstName} ${user.lastName}`; const getEmail = (user: User) => user.email; ... const createUser = (id: string, firstName: string, ...) => User;

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

अब हम Redux पर वापस जा सकते हैं और केवल राज्य से संबंधित मुद्दों को हल कर सकते हैं:

हमारे लेख में उपयोगकर्ताओं को किस स्थान पर कब्जा है?
हमें उपयोगकर्ताओं को कैसे संग्रहीत करना चाहिए? एक सूची? शब्दकोश (कुंजी-मूल्य)? और कैसे?
हमें राज्य से उपयोगकर्ता का उदाहरण कैसे मिलेगा? क्या संस्मरण का उपयोग किया जाना चाहिए? (GetUser चयनकर्ता के संदर्भ में)

बड़े लाभ के साथ छोटा एपीआई

विषय क्षेत्र और राज्य के बीच जिम्मेदारी साझा करने के सिद्धांत को लागू करने से हमें बहुत सारे बोनस मिलते हैं।

Api.ts फ़ाइल में एक अच्छी तरह से प्रलेखित डोमेन मॉडल (उपयोगकर्ता मॉडल और इसका एपीआई)। यह परीक्षण के रूप में अच्छी तरह से उधार देता है कोई निर्भरता नहीं है। हम अन्य अनुप्रयोगों में पुन: उपयोग के लिए पुस्तकालय में मॉडल और एपीआई को निकाल सकते हैं।

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

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

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

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

निष्कर्ष

अच्छे इरादों के साथ (यहां पढ़ें - चयनकर्ता) नरक की राह प्रशस्त है: हम सीधे इकाई के क्षेत्रों तक नहीं पहुंचना चाहते थे और इसके लिए अलग चयनकर्ताओं को बनाया था।

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

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

अनुवादक के नोट्स

मैंने राज्य शब्द का उपयोग किया, क्योंकि ऐसा लगता है कि यह रूसी-भाषी डेवलपर्स की शब्दावली में दृढ़ता से प्रवेश कर चुका है।
लेखक अपस्ट्रीम / डाउनस्ट्रीम शब्दों का उपयोग "उच्च-स्तरीय / निम्न-स्तरीय कोड" (यदि मार्टिन के अनुसार) करता है या "नीचे दिया गया कोड उपयोग करता है / कोड जो कि ऊपर लिखा गया है" का उपयोग करता है, लेकिन अनुवाद में इसका उपयोग कैसे करें यह पता लगाना सही नहीं है। इसलिए, मैं सामान्य ज्ञान को परेशान नहीं करने की कोशिश करके खुद को सांत्वना देता हूं।

मैं पीएम के सुधार के लिए टिप्पणियों और सुझावों को सहर्ष स्वीकार करूंगा और उन्हें सही करूंगा।

हम Redux चयनकर्ताओं का बहुत अधिक उपयोग करते हैं