मेरे ReactJS अनुप्रयोगों में शीर्ष 5 बग

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

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

1. स्टेटफुल कंपोनेंट (क्लासेस) हुक से भी बदतर हैं

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

यह, ज़ाहिर है, अपने आप में एक त्रुटि नहीं है, लेकिन हुक की तुलना में कक्षाओं का दृष्टिकोण बहुत अधिक त्रुटि प्रवण है, क्योंकि कई लेख पहले ही लिखे जा चुके हैं:

1. आपके रिएक्ट कोड में सबसे आम गलतियाँ जो आप (संभवतः) करते हैं
2. 7 सबसे आम गलतियाँ जो रिएक्ट डेवलपर्स बनाती हैं

2. सहारा के रूप में अनाम कार्यों का उपयोग करना

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

export default function MyOtherComponent() { return ( <MyComponent getValue={i => i.value} /> {/*     */} ); } 

इस त्रुटि का एक और अधिक परिष्कृत संस्करण कुछ इस तरह दिख सकता है (यदि आप Redux से परिचित नहीं हैं तो पढ़ें नहीं):

 import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; const mergeProps = ( { projectId, ...restState }: any, { fetchProjectData, ...restDispatch }: any, { memberId, ...restOwn }: any ) => ({ ...restState, ...restDispatch, ...restOwn, fetchProjectData: () => fetchProjectData(projectId), }); export default connect( mapStateToProps, mapDispatchToProps, mergeProps )(MyComponent); 

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

समस्या यह है कि, अक्सर, ऐसी गलती कुछ भी गलत नहीं करती है। कोड सिर्फ अपने लिए काम करता है - और यह बात है और कुछ भी बुरा नहीं होता है। ठीक उसी समय तक जब तक आप एक बार फिर से सर्वर से डेटा प्राप्त करने के लिए अनाम कॉल को आगे बढ़ाते हैं (दूसरा उदाहरण), तब आप समस्या की गंभीरता को समझेंगे। इस तरह के अनाम प्रॉप्स का संचय, परिणामस्वरूप, 1995 में आपके आवेदन को अनुभव के स्तर तक धीमा कर देगा, जब हमें पेज डाउनलोड करने के लिए पड़ोसियों को टेलीफोन लाइन जारी करने के लिए कहना था।

बस कुछ शब्द, सही तरीके से कैसे लिखें। यहां जानिए कैसे:

 const getValue = i => i.value; return default function MyOtherComponent() { return ( <MyComponent getValue={getValue} /> ); } 

 import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; export default connect( mapStateToProps, mapDispatchToProps )(MyComponent); //     import React, { useEffect } from 'react'; export default function MyComponent({ fetchProjectData, projectId }) { useEffect(() => { fetchProjectData(projectId); }, [fetchProjectData, projectId]); return ( <div>{/* -  */}</div> ); } //        ,       , ..     . , -   ,     . 

3. अनुप्रयोग में कई प्रतिक्रिया उदाहरण

यह त्रुटि सबसे अधिक संभावना है कि संपूर्ण रूप से संपूर्ण एप्लिकेशन की वास्तुकला से संबंधित है, और विशेष रूप से केवल रिएक्टजेएस नहीं। लेकिन यह व्यावहारिक समस्या अक्सर डेवलपर्स के लिए बहुत महंगी होती है और अक्सर रातों की नींद हराम करने के लिए भी।

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

 import React, { useCallback, useEffect } from 'react'; export default function MyComponent() { const reactHandlerOfLegacyEvent = useCallback((event) => {/* event handler */}, []); useEffect(() => { document.addEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); return () => { document.removeEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); }; }, [reactHandlerOfLegacyEvent]); return ({/*  -  */}); } 

4. अपने स्वयं के पुस्तकालयों को लिखना, मौजूदा खुले स्रोत के बजाय

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

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

5. किसी और के कोड का उपयोग करने का डर

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

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

आपका धन्यवाद

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

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