🍻 🚴🏻 🤞🏾 रिएक्ट एप्लिकेशन विकसित करते समय Redux का उपयोग करने के लिए 11 सुझाव 👩‍⚕️ 🎶 🕖

जब रिएक्शन एप्लिकेशन विकसित करने की बात आती है, तो कोड आर्किटेक्चर के संदर्भ में, छोटे प्रोजेक्ट अक्सर बड़े लोगों की तुलना में अधिक लचीले होते हैं। बड़े अनुप्रयोगों के उद्देश्य से व्यावहारिक दिशानिर्देशों का उपयोग करके ऐसी परियोजनाओं को बनाने में कुछ भी गलत नहीं है। लेकिन यह सब, छोटी परियोजनाओं के मामले में, बस अनावश्यक हो सकता है। छोटा अनुप्रयोग, जितना अधिक "कृपालु" यह इसमें सरल समाधानों के उपयोग को संदर्भित करता है, संभवतः गैर-इष्टतम, लेकिन उनके कार्यान्वयन के लिए बहुत समय की आवश्यकता नहीं है।

इसके बावजूद, मैं यह नोट करना चाहूंगा कि इस सामग्री में दी जाने वाली कुछ सिफारिशें किसी भी पैमाने के रिएक्ट अनुप्रयोगों के उद्देश्य से हैं।

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

इस सामग्री के लेखक पाठक से इसके लिए अपना शब्द लेने के लिए कहते हैं। वह ऐसी ही स्थितियों में रहा है। इसलिए, उन्हें कई कार्य मिले जिन्हें एक निश्चित समय में हल करने की आवश्यकता थी। सबसे पहले, उसने सोचा कि उसने जो कुछ भी किया वह उत्कृष्ट था। इस तरह के विचारों का स्रोत यह था कि उनके वेब एप्लिकेशन, परिवर्तन करने के बाद भी काम करना जारी रखते थे, और साथ ही साथ जल्दी से काम करना जारी रखते थे। वह जानता था कि Redux का उपयोग कैसे करना है, उपयोगकर्ता इंटरफ़ेस घटकों के बीच सामान्य बातचीत कैसे स्थापित करें। उसे लग रहा था कि वह reducers और कार्यों की अवधारणाओं को गहराई से समझता है। वह अजेय लगा।

लेकिन यहां पर भविष्य चरमरा गया।

आवेदन पर काम करने के कुछ महीनों के बाद, इसमें 15 से अधिक नई सुविधाएँ जोड़ी गईं। उसके बाद, परियोजना नियंत्रण से बाहर हो गई। Redux लाइब्रेरी का उपयोग करने वाले कोड को बनाए रखना बहुत मुश्किल हो गया है। ऐसा क्यों हुआ? पहली बार में, ऐसा नहीं लगता कि इस परियोजना के लंबे और बादल रहित जीवन की उम्मीद थी?

लेख के लेखक का कहना है कि, इसी तरह के सवाल पूछकर, उन्होंने महसूस किया कि उन्होंने अपने हाथों से परियोजना में एक समय बम लगाया था।

Redux पुस्तकालय, यदि बड़ी परियोजनाओं में सही ढंग से उपयोग किया जाता है, तो मदद करता है, जैसे कि परियोजनाएं बढ़ती हैं, एक समर्थित राज्य में अपना कोड रखने के लिए।

यहां उन लोगों के लिए 11 सुझाव दिए गए हैं जो Redux का उपयोग करके स्केलेबल रिएक्ट एप्लिकेशन विकसित करना चाहते हैं।

1. एक्शन कोड और स्थिरांक को एक जगह पर न रखें

आप कुछ Redux ट्यूटोरियल्स में आ सकते हैं जिनमें स्थिरांक और सभी क्रियाओं को एक ही स्थान पर रखा गया है। हालांकि, यह दृष्टिकोण, जैसे-जैसे आवेदन बढ़ता है, जल्दी से समस्याओं का कारण बन सकता है। लगातार अलग-अलग संग्रहीत करने की आवश्यकता होती है, उदाहरण के लिए, ./src/constants । परिणामस्वरूप, स्थिरांक की खोज करने के लिए, आपको केवल एक फ़ोल्डर देखना होगा, और कई नहीं।

इसके अलावा, अलग-अलग फ़ाइलों को संग्रहीत करने वाली क्रियाओं का निर्माण पूरी तरह से सामान्य दिखता है। ऐसी फाइलें सीधे एक दूसरे से संबंधित क्रियाओं को एनकाउंटर करती हैं। उदाहरण के लिए, एकल फ़ाइल में क्रियाओं का उपयोग और उनके उपयोग के तरीके में समानता हो सकती है।

मान लीजिए कि आप एक आर्केड या भूमिका-खेल खेल विकसित कर रहे हैं और कक्षाओं को warrior (योद्धा), sorceress (जादूगरनी) और archer (आर्चर) बना रहे हैं। ऐसी स्थिति में, आप निम्न कार्यों को व्यवस्थित करके एक उच्च स्तरीय कोड समर्थन प्राप्त कर सकते हैं:

 src/actions/warrior.js src/actions/sorceress.js src/actions/archer.js

सब कुछ एक फाइल में गिर जाए तो बहुत बुरा होगा:

 src/actions/classes.js

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

 src/actions/warrior/skills.js src/actions/sorceress/skills.js src/actions/archer/skills.js

ऐसी संरचना का केवल एक छोटा टुकड़ा यहां दिखाया गया है। यदि आप अधिक व्यापक रूप से सोचते हैं और लगातार इस दृष्टिकोण का उपयोग करते हैं, तो आप कुछ इस तरह की फाइलों के साथ समाप्त हो जाएंगे:

 src/actions/warrior/skills.js src/actions/warrior/quests.js src/actions/warrior/equipping.js src/actions/sorceress/skills.js src/actions/sorceress/quests.js src/actions/sorceress/equipping.js src/actions/archer/skills.js src/actions/archer/quests.js src/actions/archer/equipping.js

यहाँ क्या src/actions/sorceress/skills फ़ाइल से sorceress वस्तु के लिए src/actions/sorceress/skills तरह लग सकता है:

 import { CAST_FIRE_TORNADO, CAST_LIGHTNING_BOLT } from '../constants/sorceress' export const castFireTornado = (target) => ({ type: CAST_FIRE_TORNADO, target, }) export const castLightningBolt = (target) => ({ type: CAST_LIGHTNING_BOLT, target, })

यहाँ src/actions/sorceress/equipping :

 import * as consts from '../constants/sorceress' export const equipStaff = (staff, enhancements) => {...} export const removeStaff = (staff) => {...} export const upgradeStaff = (slot, enhancements) => { return (dispatch, getState, { api }) => {   //                 const state = getState()   const currentEquipment = state.classes.sorceress.equipment.current   const staff = currentEquipment[slot]   const isMax = staff.level >= 9   if (isMax) {     return   }   dispatch({ type: consts.UPGRADING_STAFF, slot })   api.upgradeEquipment({     type: 'staff',     id: currentEquipment.id,     enhancements,   })   .then((newStaff) => {     dispatch({ type: consts.UPGRADED_STAFF, slot, staff: newStaff })   })   .catch((error) => {     dispatch({ type: consts.UPGRADE_STAFF_FAILED, error })   }) } }

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

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

2. Reducer कोड को एक जगह पर न रखें

जब मैं देखता हूं कि मेरे रीड्यूसर का कोड नीचे दिखाए गए समान के समान है, तो मैं समझता हूं कि मुझे कुछ बदलने की आवश्यकता है।

 const equipmentReducers = (state, action) => { switch (action.type) {   case consts.UPGRADING_STAFF:     return {       ...state,       classes: {         ...state.classes,         sorceress: {           ...state.classes.sorceress,           equipment: {             ...state.classes.sorceress.equipment,             isUpgrading: action.slot,           },         },       },     }   case consts.UPGRADED_STAFF:     return {       ...state,       classes: {         ...state.classes,         sorceress: {           ...state.classes.sorceress,           equipment: {             ...state.classes.sorceress.equipment,             isUpgrading: null,             current: {               ...state.classes.sorceress.equipment.current,               [action.slot]: action.staff,             },           },         },       },     }   case consts.UPGRADE_STAFF_FAILED:     return {       ...state,       classes: {         ...state.classes,         sorceress: {           ...state.classes.sorceress,           equipment: {             ...state.classes.sorceress.equipment,             isUpgrading: null,           },         },       },     }   default:     return state } }

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

Reducers के साथ काम करने में एक उपयोगी चाल उच्च क्रम reducer बनाने के लिए है जो अन्य reducers उत्पन्न करते हैं। इसके बारे में यहाँ और पढ़ें।

3. सूचनात्मक चर नामों का उपयोग करें

नामकरण चर, पहली नज़र में, एक प्राथमिक कार्य की तरह लग सकता है। लेकिन वास्तव में, यह कार्य सबसे कठिन में से एक हो सकता है।

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

क्या आपने कभी किसी और के कोड को संपादित करने की कोशिश की है और साथ ही यह समझने में कठिनाइयों का सामना करना पड़ा है कि यह कोड वास्तव में क्या करता है? क्या आपने कभी एक विदेशी कार्यक्रम चलाया है और पाया है कि यह अपेक्षा के अनुरूप काम नहीं करता है?

मैं यह साबित करने का तर्क दूंगा कि ऐसे मामलों में आपने तथाकथित "गंदे कोड" का सामना किया है।

यदि आपको बड़े अनुप्रयोगों में समान कोड से निपटना है, तो यह सिर्फ एक बुरा सपना है। दुर्भाग्य से, यह अक्सर होता है।

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

यह एक मुश्किल काम नहीं था, मुझे जो मुख्य समस्या का सामना करना पड़ा, वह यह था कि मुझे बहुत समय बिताने के लिए यह ढूंढना था कि परियोजना की कोड में मुझे क्या चाहिए।

मैंने शब्द info के लिए कोड में खोजा, dataToSend , dataObject , और अन्य लोगों के लिए, जो मेरी dataObject , सर्वर से प्राप्त डेटा से जुड़े हैं। 5-10 मिनट के बाद, मुझे उस डेटा के साथ काम करने के लिए जिम्मेदार कोड ढूंढने में कामयाबी मिली, जिसकी मुझे ज़रूरत थी। जिस वस्तु में वे समाप्त हुए, उसे भुगतान कहा गया। मेरी राय में, भुगतान से संबंधित एक वस्तु में सीवीवी कोड, क्रेडिट कार्ड नंबर, भुगतानकर्ता ज़िप कोड और अन्य समान जानकारी हो सकती है। मैंने जिस वस्तु की खोज की उसमें 11 गुण थे। उनमें से केवल तीन भुगतान से संबंधित थे: भुगतान विधि, भुगतान प्रोफ़ाइल पहचानकर्ता और कूपन कोड की एक सूची।

स्थिति में सुधार नहीं हुआ, क्योंकि मुझे इस वस्तु में परिवर्तन करना था जो मेरे सामने कार्य को हल करने के लिए आवश्यक थे।

संक्षेप में, यह अनुशंसा की जाती है कि आप फ़ंक्शन और चर के लिए अस्पष्ट नामों का उपयोग करने से बचते हैं। यहां एक उदाहरण कोड दिया गया है जिसमें notify फ़ंक्शन का नाम इसके अर्थ को प्रकट नहीं notify है:

 import React from 'react' class App extends React.Component { state = { data: null } //  -? notify = () => {   if (this.props.user.loaded) {     if (this.props.user.profileIsReady) {       toast.alert(         'You are not approved. Please come back in 15 minutes or you will be deleted.',         {           position: 'bottom-right',           timeout: 15000,         },       )     }   } } render() {   return this.props.render({     ...this.state,     notify: this.notify,   }) } } export default App

4. पहले से कॉन्फ़िगर किए गए एप्लिकेशन डेटा धाराओं में डेटा संरचनाएं या प्रकार न बदलें

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

मैं आपसे यह नहीं करने के लिए कहता हूं। शायद ऐसा कुछ केवल वही व्यक्ति कर सकता है जो यह जानता हो कि आवेदन के किन हिस्सों को यह प्रभावित कर सकता है।

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

5. स्निपेट का उपयोग करें

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

यदि आप वीएस कोड का भी उपयोग करते हैं, तो मैं प्रोजेक्ट स्निपेट्स एक्सटेंशन स्थापित करने की सलाह देता हूं। यह एक्सटेंशन प्रोग्रामर को किसी प्रोजेक्ट में उपयोग किए जाने वाले प्रत्येक कार्यक्षेत्र के लिए कस्टम स्निपेट बनाने की अनुमति देता है। यह एक्सटेंशन उसी तरह काम करता है जैसे वीएस कोड में निर्मित स्निपेट्स तंत्र का उपयोग करें। अंतर यह है कि प्रोजेक्ट स्निपेट्स के साथ काम करते समय .vscode/snippets/ फ़ोल्डर प्रोजेक्ट में बनाया जाता है। यह निम्न आकृति जैसा दिखता है।

.Vscode / स्निपेट / फ़ोल्डर की सामग्री

6. यूनिट, एंड-टू-एंड और इंटीग्रेशन टेस्ट बनाएं

जैसे-जैसे एप्लिकेशन का आकार बढ़ता है, प्रोग्रामर के लिए कोड को संपादित करना अधिक भयावह हो जाता है जो परीक्षणों द्वारा कवर नहीं किया जाता है। उदाहरण के लिए, ऐसा हो सकता है कि किसी ने src/x/y/z/ में संग्रहीत कोड को संपादित किया और इसे उत्पादन में भेजने का फैसला किया। यदि एक ही समय में किए गए परिवर्तन परियोजना के उन हिस्सों को प्रभावित करते हैं जिनके बारे में प्रोग्रामर ने नहीं सोचा था, तो सब कुछ एक त्रुटि में समाप्त हो सकता है कि एक वास्तविक उपयोगकर्ता का सामना होगा। यदि परियोजना में परीक्षण हैं, तो कोड के उत्पादन में आने से पहले प्रोग्रामर को त्रुटि के बारे में पता चल जाएगा।

7. मंथन

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

और क्यों, वैसे, क्या आपको अनुप्रयोगों के विकास के दौरान मंथन करना पड़ता है?

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

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

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

8. एप्लिकेशन मॉकअप बनाएं

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

Moqups एक ऐप मॉकअप टूल है जिसके बारे में मैं अक्सर सुनता हूं। यह एचटीएमएल 5 और जावास्क्रिप्ट का उपयोग करके बनाया गया एक तेज़ उपकरण है और सिस्टम पर विशेष आवश्यकताओं को लागू नहीं करता है।

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

9. अनुप्रयोगों में डेटा प्रवाह की योजना बनाएं

आपके एप्लिकेशन का लगभग हर घटक कुछ डेटा से संबद्ध होगा। कुछ घटक अपने स्वयं के डेटा स्रोतों का उपयोग करेंगे, लेकिन अधिकांश घटक घटक पदानुक्रम में उनके ऊपर संस्थाओं से डेटा प्राप्त करते हैं। आवेदन के उन हिस्सों के लिए जिसमें एक ही डेटा कई घटकों द्वारा साझा किया जाता है, यह पदानुक्रम के शीर्ष स्तर पर स्थित कुछ केंद्रीकृत सूचना भंडारण प्रदान करने के लिए उपयोगी है। यह ऐसी स्थितियों में है कि Redux पुस्तकालय डेवलपर को अमूल्य सहायता प्रदान कर सकता है।

मेरा सुझाव है कि एप्लिकेशन पर काम करते समय, इस एप्लिकेशन में डेटा को स्थानांतरित करने के तरीके दिखाते हुए आरेख बनाएं। यह एक स्पष्ट एप्लिकेशन मॉडल बनाने में मदद करेगा, इसके अलावा, हम प्रोग्रामर द्वारा कोड और एप्लिकेशन की धारणा के बारे में बात कर रहे हैं। ऐसा मॉडल मदद करेगा, इसके अलावा, रीड्यूसर के निर्माण में।

10. डेटा एक्सेस सुविधाओं का उपयोग करें

जैसे-जैसे एप्लिकेशन का आकार बढ़ता है, वैसे-वैसे उसके घटकों की संख्या भी बढ़ने लगती है। और जब घटकों की संख्या बढ़ती है, तो चयनकर्ताओं (प्रतिक्रिया- mapStateToProps ^ v7.1) या mapStateToProps का उपयोग करने की आवृत्ति के साथ एक ही बात होती है। मान लीजिए कि आप पाते हैं कि आपके पुर्जे या हुक अक्सर निर्माण के उपयोग से अनुप्रयोग के विभिन्न भागों में राज्य अंशों तक useSelector((state) => state.app.user.profile.demographics.languages.main) जैसे कि useSelector((state) => state.app.user.profile.demographics.languages.main) । यदि हां, तो इसका मतलब है कि आपको डेटा एक्सेस फ़ंक्शंस बनाने के बारे में सोचना होगा। ऐसे कार्यों के साथ फाइलें सार्वजनिक स्थान पर संग्रहीत की जानी चाहिए, जहां से घटक और हुक उन्हें आयात कर सकते हैं। इसी तरह के कार्य फ़िल्टर, पार्सर या डेटा परिवर्तन के लिए कोई अन्य कार्य हो सकते हैं।

यहाँ कुछ उदाहरण हैं।

उदाहरण के लिए, src/accessors में निम्नलिखित कोड हो सकते हैं:

 export const getMainLanguages = (state) => state.app.user.profile.demographics.languages.main

यहाँ connect का उपयोग connect वाला संस्करण है, जो src/components/ViewUserLanguages साथ स्थित हो सकता है:

 import React from 'react' import { connect } from 'react-redux' import { getMainLanguages } from '../accessors' const ViewUserLanguages = ({ mainLanguages }) => ( <div>   <h1>Good Morning.</h1>   <small>Here are your main languages:</small>   <hr />   {mainLanguages.map((lang) => (     <div>{lang}</div>   ))} </div> ) export default connect((state) => ({ mainLanguages: getMainLanguages(state), }))(ViewUserLanguages)

यहाँ वह संस्करण है जो उपयोग करता है src/components/ViewUserLanguages पर स्थित src/components/ViewUserLanguages :

 import React from 'react' import { useSelector } from 'react-redux' import { getMainLanguages } from '../accessors' const ViewUserLanguages = ({ mainLanguages }) => { const mainLanguages = useSelector(getMainLanguages) return (   <div>     <h1>Good Morning.</h1>     <small>Here are your main languages:</small>     <hr />     {mainLanguages.map((lang) => (       <div>{lang}</div>     ))}   </div> ) } export default ViewUserLanguages

इसके अलावा, यह सुनिश्चित करने के लिए प्रयास करें कि ऐसे कार्य अपरिवर्तनीय हैं, साइड इफेक्ट्स से रहित हैं। पता करें कि मैं यहाँ इस तरह की सिफारिश क्यों देता हूँ।

11. विनाश और प्रसार सिंटैक्स का उपयोग करके गुणों में डेटा के प्रवाह को नियंत्रित करें

something निर्माण से अधिक props.something निर्माण का उपयोग करने के क्या लाभ हैं?

यहाँ यह विनाशकारी का उपयोग किए बिना कैसा दिखता है:

 const Display = (props) => <div>{props.something}</div>

यहाँ एक ही है, लेकिन विनाश के उपयोग के साथ:

 const Display = ({ something }) => <div>{something}</div>

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

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

 const Display = ({ something = 'apple' }) => <div>{something}</div>

आप पहले कुछ उदाहरण देख सकते हैं:

 const Display = (props) => ( <Agenda {...props}>   {' '}   //     Agenda   <h2><font color="#3AC1EF">Today is {props.date}</font></h2>   <hr />   <div>     <h3><font color="#3AC1EF">▍Here your list of todos:</font></h3>     {props.children}   </div> </Agenda> )

ऐसे निर्माण पढ़ना आसान नहीं है, लेकिन यह उनकी एकमात्र समस्या नहीं है। तो, एक त्रुटि है। यदि एप्लिकेशन बाल घटकों को भी प्रदर्शित करता है, तो स्क्रीन पर दो बार props.children प्रदर्शित होता है। यदि किसी टीम में प्रोजेक्ट पर काम किया जाता है और टीम के सदस्य पर्याप्त सावधानी नहीं बरतते हैं, तो ऐसी त्रुटियों की संभावना काफी अधिक है।

यदि आप इसके बजाय गुणों को नष्ट करते हैं, तो घटक कोड स्पष्ट हो जाएगा, और त्रुटियों की संभावना कम हो जाएगी:

 const Display = ({ children, date, ...props }) => ( <Agenda {...props}>   {' '}   //     Agenda   <h2><font color="#3AC1EF">Today is {date}</font></h2>   <hr />   <div>     <h3><font color="#3AC1EF">▍Here your list of todos:</font></h3>     {children}   </div> </Agenda> )

परिणाम

इस लेख में, हमने उन लोगों के लिए १२ सिफारिशों की समीक्षा की जो Redux का उपयोग करके रिएक्ट एप्लिकेशन विकसित कर रहे हैं। हमें उम्मीद है कि आपको यहां कुछ मिलेगा जो आपके लिए उपयोगी है।

प्रिय पाठकों! इस लेख में आप किन टिप्स को जोड़ेंगे?

रिएक्ट एप्लिकेशन विकसित करते समय Redux का उपयोग करने के लिए 11 सुझाव