राज्य सह-होस्टिंग के साथ तेजी से प्रतिक्रिया कैसे करें

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

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

यहां एक सरल एप्लिकेशन है जिसमें आप कुत्ते के लिए एक नाम दर्ज कर सकते हैं (यदि विंडो काम नहीं करती है, तो यहां लिंक है ):

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

यहाँ इस आवेदन के लिए कोड है:

 function sleep(time) { const done = Date.now() + time while (done > Date.now()) { // ... } } //      // -       function SlowComponent({time, onChange}) { sleep(time) return ( <div> Wow, that was{' '} <input value={time} type="number" onChange={e => onChange(Number(e.target.value))} /> ms slow </div> ) } function DogName({time, dog, onChange}) { return ( <div> <label htmlFor="dog">Dog Name</label> <br /> <input id="dog" value={dog} onChange={e => onChange(e.target.value)} /> <p> {dog ? `${dog}'s favorite number is ${time}.` : 'enter a dog name'} </p> </div> ) } function App() { //   " " (global state) const [dog, setDog] = React.useState('') const [time, setTime] = React.useState(200) return ( <div> <DogName time={time} dog={dog} onChange={setDog} /> <SlowComponent time={time} onChange={setTime} /> </div> ) } 

यदि आपने Colocation (सह-स्थान) के बारे में लेख नहीं पढ़ा है, तो मेरा सुझाव है कि आप इसे पढ़ें। यह जानते हुए कि सह-होस्टिंग हमारे एप्लिकेशन के साथ काम करना आसान बना सकती है, आइए राज्यों के साथ काम करते समय इस सिद्धांत का उपयोग करें।

हमारे एप्लिकेशन के कोड पर ध्यान दें, अर्थात् time स्थिति - यह हमारे एप्लिकेशन के प्रत्येक घटक द्वारा उपयोग किया जाता है, इसलिए इसे App घटक (हमारे संपूर्ण एप्लिकेशन को लपेटने वाला घटक) को उठा लिया गया था ( राज्य को ऊपर उठाना )। हालांकि, "डॉग" राज्य ( dog और setDog ) का उपयोग केवल एक घटक द्वारा किया जाता है, App घटक में इसकी आवश्यकता नहीं है, इसलिए इसे DogName घटक पर ले जाएं:

 function DogName({time}) { // <-    const [dog, setDog] = React.useState('') // <-   return ( <div> <label htmlFor="dog">Dog Name</label> <br /> <input id="dog" value={dog} onChange={e => setDog(e.target.value)} /> <p> {dog ? `${dog}'s favorite number is ${time}.` : 'enter a dog name'} </p> </div> ) } function App() { //   " " (global state) const [time, setTime] = React.useState(200) return ( <div> <DogName time={time} /> // <-    <SlowComponent time={time} onChange={setTime} /> </div> ) } 

और यहां हमारा परिणाम है (यदि विंडो काम नहीं करती है, लिंक ):

वाह! एक नाम दर्ज करना अब बहुत तेजी से काम करता है। इसके अलावा, सह-स्थान के लिए धन्यवाद बनाए रखने के लिए घटक आसान हो गया है। लेकिन यह तेजी से क्यों काम किया?

वे कहते हैं कि जल्दी से कुछ करने का सबसे अच्छा तरीका यह है कि जितना संभव हो उतना कम काम करें। ठीक ऐसा ही यहां हो रहा है। जब हम घटक ट्री के शीर्ष पर स्थित राज्य का प्रबंधन करते हैं, तो इस राज्य का प्रत्येक अपडेट पूरे पेड़ को अमान्य कर देगा। प्रतिक्रिया नहीं जानता कि क्या बदल गया है, इस वजह से, उसे यह देखने के लिए सभी घटकों की जांच करनी होगी कि क्या उन्हें DOM अपडेट की आवश्यकता है। यह प्रक्रिया मुक्त नहीं है और संसाधनों का उपभोग करती है (विशेषकर यदि आपके पास जानबूझकर धीमा घटक है)। लेकिन यदि आप घटक ट्री में राज्य को यथासंभव कम स्थानांतरित करते हैं, जैसा कि हमने dog स्टेट और DogName घटक के साथ किया है, तो रिएक्ट कम जांच करेगा। प्रतिक्रिया SlowComponent घटक (जिसे हमने जानबूझकर धीमी गति से बनाया है) की जाँच नहीं करेगा, क्योंकि React जानता है कि यह घटक अभी भी आउटपुट को प्रभावित नहीं कर सकता है।

संक्षेप में, पहले, कुत्ते के नाम को बदलते समय, प्रत्येक घटक को परिवर्तनों (पुनः प्रदान) के लिए जांचा गया था। और हम कोड में किए गए परिवर्तनों के बाद, रिएक्ट केवल DogName घटक की जांच करने लगे। इससे उत्पादकता में उल्लेखनीय वृद्धि हुई है!

वास्तविक जीवन में

मैं देख रहा हूं कि डेवलपर्स Redux ग्लोबल रिपॉजिटरी या वैश्विक संदर्भ में डाल रहे हैं जो वास्तव में वैश्विक नहीं होना चाहिए। ऊपर दिए गए उदाहरण से DogName जैसे DogName अक्सर ऐसे स्थान होते हैं जहां एक प्रदर्शन समस्या होती है। मैं अक्सर देखता हूं कि माउस के साथ बातचीत करते समय यह समस्या स्वयं प्रकट होती है (उदाहरण के लिए, जब ग्राफ के ऊपर या डेटा टेबल के ऊपर टूलटिप प्रदर्शित होती है)।

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

एक अन्य समाधान जो डेवलपर्स अक्सर उपयोग करते हैं, वह है रिएक्ट रेस्क्यू रेंडरिंग में से एक का उपयोग करना, उदाहरण के लिए React.memo । यह हमारे दूरगामी उदाहरण में बहुत अच्छी तरह से काम करेगा, क्योंकि यह रिएक्ट को SlowComponent के पुन: प्रतिपादन को छोड़ने की अनुमति देता है, लेकिन व्यवहार में "एक हजार कटौती से मौत" के कारण आवेदन को नुकसान हो सकता है, क्योंकि एक वास्तविक आवेदन में मंदी आमतौर पर एक धीमी गति से नहीं होती है। घटक, और कई घटकों के अपर्याप्त तेजी से काम के कारण, इसलिए आपको हर जगह React.memo का उपयोग React.memo । ऐसा करने के बाद, आपको useMemo और useCallback का उपयोग शुरू करना होगा, अन्यथा आपके द्वारा React.memo में React.memo गए सभी कार्य व्यर्थ हो जाएंगे। ये क्रियाएं समस्या को हल कर सकती हैं, लेकिन वे आपके कोड की जटिलता को काफी बढ़ाते हैं और वास्तव में, वे अभी भी राज्यों को साझा करने की तुलना में कम प्रभावी हैं, क्योंकि रिएक्ट को फिर से प्रस्तुत करने की आवश्यकता है या नहीं यह निर्धारित करने के लिए प्रत्येक घटक (ऊपर से शुरू) से गुजरना पड़ता है।

यदि आप थोड़ी दूर के उदाहरण के साथ खेलना चाहते हैं , तो यहां पर कोडेंडबॉक्स पर जाएं ।

सह-स्थान क्या है?

संयुक्त प्लेसमेंट का सिद्धांत बताता है:

कोड को उस स्थान से जितना संभव हो उतना निकट स्थित होना चाहिए, जिससे वह संबंधित है।

इसलिए, इस सिद्धांत का पालन करने के लिए, हमारे dog स्थिति DogName घटक के अंदर होनी चाहिए:

 function DogName({time}) { const [dog, setDog] = React.useState('') return ( <div> <label htmlFor="dog">Dog Name</label> <br /> <input id="dog" value={dog} onChange={e => setDog(e.target.value)} /> <p> {dog ? `${dog}'s favorite number is ${time}.` : 'enter a dog name'} </p> </div> ) } 

लेकिन क्या होगा अगर हम इस घटक को कई घटकों में तोड़ दें? राज्य कहाँ जाना चाहिए? इसका उत्तर समान है: "जिस स्थान से संबंधित है, उसके करीब जितना संभव हो," और इस तरह का निकटतम सामान्य मूल घटक होगा । एक उदाहरण के रूप में, चलो DogName घटक को DogName हैं DogName input और p विभिन्न घटकों में प्रदर्शित हों:

 function DogName({time}) { const [dog, setDog] = React.useState('') return ( <div> <DogInput dog={dog} onChange={setDog} /> <DogFavoriteNumberDisplay time={time} dog={dog} /> </div> ) } function DogInput({dog, onChange}) { return ( <> <label htmlFor="dog">Dog Name</label> <br /> <input id="dog" value={dog} onChange={e => onChange(e.target.value)} /> </> ) } function DogFavoriteNumberDisplay({time, dog}) { return ( <p> {dog ? `${dog}'s favorite number is ${time}.` : 'enter a dog name'} </p> ) } 

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

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

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

तो क्या उपयोग करें, संदर्भ या Redux?

यदि आप "रिएक्ट री-रेंडरर्स को ऑप्टिमाइज़ करने के लिए एक सरल ट्रिक" पढ़ते हैं, तो आप जानते हैं कि आप यह सुनिश्चित कर सकते हैं कि केवल वे घटक जो बदले हुए राज्य का उपयोग करते हैं, अपडेट किए गए हैं। इस तरह से आप इस समस्या को हल कर सकते हैं। लेकिन संपादक का उपयोग करते समय लोग अभी भी प्रदर्शन के मुद्दों का सामना करते हैं। समस्या यह है कि रिएक्ट-रेडक्स आपको उम्मीद करता है कि जुड़े घटकों के अनावश्यक प्रतिपादन से बचने के लिए इसकी सिफारिशों का पालन करें । हमेशा त्रुटि का एक मौका होता है; आप गलती से घटकों को कॉन्फ़िगर कर सकते हैं ताकि वे तब भी प्रस्तुत करना शुरू करें जब अन्य वैश्विक राज्य बदलते हैं। और आपका आवेदन जितना बड़ा होगा, इसका प्रभाव उतना ही अधिक नकारात्मक होगा, खासकर यदि आप संपादक में बहुत सारे राज्य जोड़ते हैं।

ऐसे तरीके हैं जो आपको इन समस्याओं से बचने में मदद कर सकते हैं, उदाहरण के लिए, memoized Reselect mapState लिए memoized Reselect mapState उपयोग करें, या अनुप्रयोग प्रदर्शन में सुधार के बारे में अधिक जानकारी के लिए संपादकों के प्रलेखन को पढ़ें।

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

वैसे, यदि आप अपने राज्य को डोमेन में विभाजित करते हैं (डोमेन के आधार पर कई संदर्भों का उपयोग करके), तो समस्या कम स्पष्ट होगी।

लेकिन तथ्य यह है: राज्यों का सह-स्थान प्रदर्शन के मुद्दों को कम करता है और कोड रखरखाव को सरल करता है।

तय करें कि राज्य को कहां रखा जाए

निर्णय वृक्ष:

पाठ संस्करण, अगर तस्वीर को देखने का कोई तरीका नहीं है:

• 1 हम एप्लिकेशन का विकास शुरू करते हैं। 2 पर जाएं
• 2 घटक में स्थिति। 3 पर जाएं
• 3 क्या हालत केवल इस घटक द्वारा उपयोग की जाती है ?
  
  • हाँ? हम 4 पर जाते हैं
  • नहीं? क्या इस राज्य को केवल एक बाल घटक की आवश्यकता है?
  • हाँ? इसे इस बाल घटक (सह-स्थान का उपयोग करें) पर ले जाएं। हम 3 पर जाते हैं।
  • नहीं? क्या इस राज्य को माता-पिता या पड़ोसी ("भाई" घटकों की आवश्यकता है, अर्थात, एक ही मूल घटक के बच्चे) घटकों?
    
    • हाँ? राज्य को मूल घटक से ऊपर ले जाएं। 3 पर जाएं
    • नहीं? हम 4 पर जाते हैं
• 4 जैसा है वैसा छोड़ो। 5 पर जाएं
• 5 प्रो ड्रिलिंग के साथ कोई समस्या है?
  
  • हाँ? हम इस राज्य को संदर्भ प्रदाता के पास ले जाते हैं और इस प्रदाता को उस घटक में प्रस्तुत करते हैं जिसमें राज्य प्रबंधित किया जा रहा है। 6 पर जाएं
  • नहीं? 6 पर जाएं
• 6 हम आवेदन भेजते हैं। जब नई आवश्यकताएं दिखाई दें, तो 1 पर जाएं

यह महत्वपूर्ण है कि यह प्रक्रिया आपके नियमित अनुप्रयोग रीफैक्टरिंग / रखरखाव प्रक्रिया का हिस्सा हो। यदि आपकी स्थिति को नहीं उठाया गया है जहां इसे उठाया जाना चाहिए, तो यह राज्य सही ढंग से काम करना बंद कर देगा और आप इसे नोटिस करेंगे। हालांकि, यदि आप राज्य सह-स्थान की पद्धति का पालन नहीं करते हैं, और घटकों के पदानुक्रम में राज्यों को कम नहीं करते हैं, तो आपका आवेदन काम करना जारी रखेगा। इस वजह से, आप तुरंत प्रदर्शन और प्रबंधन की समस्याओं पर ध्यान नहीं देंगे जो धीरे-धीरे जमा हो जाएंगे।

निष्कर्ष

सामान्य तौर पर, डेवलपर्स यह अच्छी तरह से समझते हैं कि जब आवश्यक हो तो राज्य ("उठाने राज्य") को उठाना आवश्यक होता है, लेकिन जब राज्य को कम करने की आवश्यकता होती है तो हम इतनी अच्छी तरह से नहीं समझते हैं। मेरा सुझाव है कि आप अपने आवेदन के कोड पर एक नज़र डालें और सोचें कि "सह-स्थान" के सिद्धांत को लागू करने से राज्य को कहाँ छोड़ा जा सकता है। अपने आप से पूछें, "क्या मुझे संपादक में एक मोडल विंडो की isOpen स्थिति की आवश्यकता है?" (जवाब सबसे अधिक संभावना नहीं है)।

सह-स्थान के सिद्धांत का उपयोग करें, और आपका कोड आसान और तेज़ हो जाएगा।

सौभाग्य है