🚨 🤷🏻 🕺🏼 सर्वोत्तम प्रथाओं और सुझावों को पढ़ें जो प्रत्येक डेवलपर को जानना चाहिए। भाग 1 🌦️ 🏛️ ⚰️

नमस्कार, हेब्र! मैं आपके लिए एलेक्स डेवेरो के लेख "रिएक्ट बेस्ट प्रैक्टिसेज एंड टिप्स हर रिएक्ट डेवलपर डे पंड 1 को जानना चाहिए" का अनुवाद प्रस्तुत करता हूं।

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

सामग्री:

अपने घटकों को छोटा रखें
घटकों को जमा करने से बचें
राज्य घटकों के उपयोग को कम करें
कक्षाओं पर घटकों के बजाय हुक और ज्ञापन के साथ कार्यात्मक घटकों का उपयोग करें
मूल स्थिति में प्रॉप्स का उपयोग न करें।

उपसंहार: अभिक्रिया सर्वश्रेष्ठ अभ्यास और युक्तियाँ हर डेवलपर को जानना चाहिए भाग 1

1. अपने घटकों को छोटा रखें

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

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

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

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

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

यह था

/// // file: index.jsx import React from 'react' const books = [ { category: 'Business', price: '$20.00', name: 'Private Empires', author: 'Steve Coll' }, { category: 'Philosophy', price: '$25.00', name: 'The Daily Stoic', author: 'Ryan Holiday' }, { category: 'Sport', price: '$15.95', name: 'Moneyball', author: 'Michael Lewis' }, { category: 'Biography', price: '$21.00', name: 'Titan', author: 'Ron Chernow' }, { category: 'Business', price: '$29.99', name: 'The Hard Thing About Hard Things', author: 'Ben Horowitz' }, { category: 'Fiction', price: '$4.81', name: 'Limitless: A Novel', author: 'Alan Glynn' } ] class Bookshelf extends React.Component { render() { const tableRows = [] this.props.books.forEach((book) => { tableRows.push( <tr> <td>{book.name}</td> <td>{book.author}</td> <td>{book.price}</td> <td>{book.category}</td> </tr> ) }) return ( <div> <form> <input type="text" placeholder="Search..." /> <button>Search</button> </form> <table> <thead> <tr> <th>Name</th> <th>Author</th> <th>Price</th> <th>Category</th> </tr> </thead> <tbody>{tableRows}</tbody> </table> </div> ) } } // Render Bookshelf component ReactDOM.render(<Bookshelf books={booksData} />, document.getElementById('container'))

बन गया है

 /// // file: books-data.js const books = [ { category: 'Business', price: '$20.00', name: 'Private Empires', author: 'Steve Coll' }, { category: 'Philosophy', price: '$25.00', name: 'The Daily Stoic', author: 'Ryan Holiday' }, { category: 'Sport', price: '$15.95', name: 'Moneyball', author: 'Michael Lewis' }, { category: 'Biography', price: '$21.00', name: 'Titan', author: 'Ron Chernow' }, { category: 'Business', price: '$29.99', name: 'The Hard Thing About Hard Things', author: 'Ben Horowitz' }, { category: 'Fiction', price: '$4.81', name: 'Limitless: A Novel', author: 'Alan Glynn' } ] export default booksData /// // file: components/books-table.jsx import React from 'react' class BooksTable extends React.Component { render() { const tableRows = [] this.props.books.forEach((book) => { tableRows.push( <tr> <td>{book.name}</td> <td>{book.author}</td> <td>{book.price}</td> <td>{book.category}</td> </tr> ) }) return ( <table> <thead> <tr> <th>Name</th> <th>Author</th> <th>Price</th> <th>Category</th> </tr> </thead> <tbody>{tableRows}</tbody> </table> ) } } export default BooksTable /// // file: components/search-bar.jsx import React from 'react' class SearchBar extends React.Component { render() { return ( <form> <input type="text" placeholder="Search..." /> <button>Search</button> </form> ) } } export default SearchBar /// // file: components/bookshelf.jsx import React from 'react' // Import components import BooksTable from './components/books-table' import SearchBar from './components/search-bar' class Bookshelf extends React.Component { render() { return ( <div> <SearchBar /> <BooksTable books={this.props.books} /> </div> ) } } export default Bookshelf /// // file: index.jsx import React from 'react' // Import components import Bookshelf from './components/bookshelf // Import data import booksData from './books-data' // Render Bookshelf component ReactDOM.render(<Bookshelf books={booksData} />, document.getElementById('container'))

2. घटकों को जमा करने से बचें

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

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

व्यवहार में, यह व्यर्थ है। हां, इनमें से कुछ तत्व एक दूसरे से स्वतंत्र रूप से मौजूद हो सकते हैं। हालांकि, क्या यह केवल एक पैराग्राफ या एक हेडिंग से युक्त एक घटक बनाने के लिए उपयोगी है? आगे क्या होगा? लेबल, इनपुट या स्पैन के लिए घटक? यह दृष्टिकोण टिकाऊ नहीं है।

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

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

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

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

3. राज्य घटकों के उपयोग को कम करें

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

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

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

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

 // Button defined as a stateful component class Button extends React.Component { handleClick = () => { // Do something } render() { return( <button type="button" onClick={this.handleClick}>Click me</button> ) } } // Button defined as a functional component const Button = () => { const handleClick = () => { // Do something } return( <button type="button" onClick={handleClick}>Click me</button> ) }

4. कक्षाओं पर घटकों के बजाय हुक और ज्ञापन के साथ कार्यात्मक घटकों का उपयोग करें

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

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

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

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

5. मूल अवस्था में प्रॉप्स का उपयोग न करें

यह सबसे अच्छी रिएक्ट प्रथाओं में से एक है जिसे मैं सीखना शुरू करने के बारे में जानना चाहूंगा। तब मुझे नहीं पता था कि प्रारंभिक अवस्था में प्रॉप्स का उपयोग करना बहुत बुरा विचार था। यह एक बुरा विचार क्यों है? समस्या यह है कि निर्माणकर्ता को केवल एक बार घटक निर्माण के दौरान कहा जाता है।

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

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

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

उपसंहार: अभिकर्मक सर्वोत्तम अभ्यास और टिप्स हर डेवलपर को जानना चाहिए भाग 1

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

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

अगर आपको यह आर्टिकल पसंद आया हो तो प्लीज सब्सक्राइब करें

मूल रूप से एलेक्स डेवरो ब्लॉग पर पोस्ट किया गया।