रिएक्ट कंपोनेंट्स के दस कमांड

कैरोलिन ओडेन के सहयोग से क्रिस्टोफ़र सेल्बेक द्वारा लिखित। जून 2019 में ओस्लो में ReactJS बैठक में इसी नाम और समान लोगों के साथ एक व्याख्यान के आधार पर।

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

ऐसे घटक बनाना आसान नहीं है जो कई डेवलपर्स उपयोग करेंगे। आपको सावधानी से विचार करना चाहिए कि ये प्रॉप सार्वजनिक एपीआई का हिस्सा हैं या नहीं।

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

एपीआई क्या है?

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

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

उसी सिद्धांत का पालन करते हुए, जो आपके घटक को स्वीकार करता है, वह उसका एपीआई है । इस तरह से डेवलपर्स आपके घटक के साथ बातचीत करते हैं।

कुछ बेस्ट एपीआई डिज़ाइन प्रैक्टिस

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

स्थिर संस्करण

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

वर्णनात्मक त्रुटि संदेश

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

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

डेवलपर्स के लिए आश्चर्य कम करें

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

साथ ही, आपका कोड हमेशा सुसंगत होना चाहिए। यदि आप गुणों के तार्किक नामों का उपयोग एक स्थान पर करते हैं या करते हैं, लेकिन उन्हें आगे छोड़ दें, तो यह लोगों को भ्रमित करेगा।

API भूतल को छोटा करें

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

आपके API के आकार को नियंत्रित करने का हमेशा एक तरीका होता है। उनमें से एक पुराने से नए एपीआई को फिर से तैयार कर रहा है।

वेब घटकों के लिए दस आज्ञाएँ

तो, ये चार सुनहरे नियम REST API के लिए और पास्कल पर पुराने प्रक्रियात्मक टुकड़ों के लिए अच्छी तरह से काम करते हैं - लेकिन उन्हें प्रतिक्रिया की आधुनिक दुनिया में कैसे स्थानांतरित किया जाए?

जैसा कि हमने पहले कहा, घटकों का अपना एपीआई है। हम उन्हें props कहते हैं, और यह उनकी मदद से है कि डेटा घटकों को स्थानांतरित किया जाता है। हम संरचना कैसे बनाते हैं ताकि उपरोक्त नियमों का उल्लंघन न हो?

हमने दस स्वर्ण नियमों की यह सूची बनाई है जो आपके घटकों को बनाते समय सर्वोत्तम रूप से अनुसरण किए जाते हैं। हमें उम्मीद है कि वे आपके लिए उपयोगी होंगे।

1. घटकों के उपयोग का दस्तावेज

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

आपके घटकों को दस्तावेज करने के कई तरीके हैं, लेकिन हम अनुशंसा करते हैं कि आप इन तीनों पर ध्यान दें:

• कहानियों का संग्रह
• Styleguidist
• Docz

पहले दो आपको अपने घटकों को विकसित करते समय काम करने के लिए जगह देते हैं, और तीसरा आपको एमडीएक्स का उपयोग करके नि: शुल्क रूप में दस्तावेज लिखने की अनुमति देता है

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

2. प्रासंगिक शब्दार्थ को सक्षम करें

एचटीएमएल एक अर्थपूर्ण तरीके से जानकारी को संरचित करने के लिए एक भाषा है। केवल यहाँ, हमारे अधिकांश घटकों में <div /> टैग शामिल हैं। यह समझ में आता है - सार्वभौमिक घटक अग्रिम में नहीं जान सकते हैं कि वे क्या होंगे, शायद <article /> , या <section /> , या <aside /> - लेकिन यह स्थिति आदर्श से बहुत दूर है।

एक और विकल्प है, बस अपने घटकों को प्रोप as स्वीकार करने दें, और इस तरह यह निर्धारित करें कि कौन सा डोम तत्व प्रदान किया जाएगा। इसे कैसे लागू किया जाए इसका एक उदाहरण इस प्रकार है:

 function Grid({ as: Element, ...props }) { return <Element className="grid" {...props} /> } Grid.defaultProps = { as: 'div', }; 

हम Element चर के as प्रोप का नाम बदलते हैं और इसे हमारे जेएसएक्स में उपयोग करते हैं। यदि हमारे पास पास करने के लिए अधिक अर्थपूर्ण HTML टैग नहीं है, तो हम एक सामान्य डिफ़ॉल्ट div मान देते हैं।

जब <Grid /> घटक का उपयोग करने का समय आता है, तो आप केवल सही टैग पास कर सकते हैं:

 function App() { return ( <Grid as="main"> <MoreContent /> </Grid> ); } 

यह भी प्रतिक्रिया घटकों के साथ काम करता है। उदाहरण के लिए, यदि आप रिएक्टर राउटर <Link /> रेंडर करने के लिए <Button /> घटक चाहते हैं:

 <Button as={Link} to="/profile"> Go to Profile </Button> 

3. बूलियन प्रॉप्स से बचें

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

 <Button large>BUY NOW!</Button> 

लेकिन हालांकि यह अच्छा लग रहा है, तार्किक गुण केवल दो संभावनाएं हैं। पर या बंद दिखाई या छिपा हुआ। 1 या 0।

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

 <Button large small primary disabled secondary>   ?? </Button> 

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

 <Button variant="primary" size="large">     </Button> 

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

4. props.children उपयोग करें। props.children

रिएक्ट में कुछ विशेष गुण होते हैं जिन्हें दूसरों से अलग तरीके से व्यवहार किया जाता है। सूची आइटम के क्रम को ट्रैक करने के लिए इनमें से एक key की आवश्यकता होती है। और इस तरह के एक और विशेष children ।

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

क्यों? क्योंकि content लिए प्रॉप content या ऐसा कुछ करना बहुत आसान है, जो आमतौर पर केवल साधारण मान लेता है, जैसे कि टेक्स्ट।

 <TableCell content="Some text" /> //  <TableCell>Some text</TableCell> 

props.children का उपयोग करने के कई फायदे हैं। सबसे पहले, यह नियमित HTML कैसे काम करता है के समान है। दूसरे, आप स्वतंत्र रूप से जो चाहें ट्रांसफर कर सकते हैं! अपने कंपोनेंट में leftIcon और rightIcon leftIcon जैसे प्रॉप्स जोड़ने के बजाय - बस उन्हें props.children हिस्से के रूप में पास करें।

 <TableCell> <ImportantIcon /> Some text </TableCell> 

आप तर्क दे सकते हैं कि आपके घटक को केवल सादे पाठ को प्रस्तुत करने की आवश्यकता है, और कुछ मामलों में यह है। कुछ बिंदु तक। props.children का उपयोग करते props.children , आप गारंटी देते हैं कि आपकी एपीआई बदलती आवश्यकताओं के लिए तैयार होगी।

5. माता-पिता को आंतरिक तर्क से चिपके रहने दें

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

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

लेकिन क्या होगा अगर हम सिर्फ एक एकल, मानकीकृत सहारा प्रदान कर सकते हैं जो डेवलपर को घटक के डिफ़ॉल्ट व्यवहार को नियंत्रित करने, प्रतिक्रिया देने या बदलने की अनुमति देता है?

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

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

यहाँ यह है कि यह कैसा दिख सकता है:

 function MyCustomDropdown(props) { const stateReducer = (state, action) => { if (action.type === Dropdown.actions.CLOSE) { buttonRef.current.focus(); } }; return ( <> <Dropdown stateReducer={stateReducer} {...props} /> <Button ref={buttonRef}>Open</Button> </> } 

वैसे, आप घटनाओं पर प्रतिक्रिया देने के सरल तरीके बना सकते हैं। पिछले उदाहरण में onClose का उपयोग करने से घटक को अधिक सुविधाजनक बनाने की संभावना है। जरूरत पड़ने पर "राज्य रिड्यूसर" पैटर्न का उपयोग करें।

6. शेष प्रॉप्स के लिए प्रसार ऑपरेटर का उपयोग करें

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

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

आप इसे इस तरह से कर सकते हैं:

 function ToolTip({ isVisible, ...rest }) { return isVisible ? <span role="tooltip" {...rest} /> : null; } 

जब भी आपका घटक आपके कार्यान्वयन के लिए प्रोप से गुजरता है, जैसे कि एक वर्ग का नाम या onClick हैंडलर, सुनिश्चित करें कि कोई अन्य डेवलपर भी ऐसा कर सकता है। एक वर्ग के मामले में, आप बस सुविधाजनक npm classnames लाइब्रेरी (या सिर्फ स्ट्रिंग संक्षेपण) का उपयोग करके प्रोप क्लास जोड़ सकते हैं:

 import classNames from 'classnames'; function ToolTip(props) { return ( <span {...props} className={classNames('tooltip', props.tooltip)} /> } 

क्लिक हैंडलर्स और अन्य कॉलबैक के मामले में, आप एक छोटी उपयोगिता का उपयोग करके उन्हें एक फ़ंक्शन में जोड़ सकते हैं। यहाँ ऐसा करने का एक तरीका है:

 function combine(...functions) { return (...args) => functions .filter(func => typeof func === 'function') .forEach(func => func(...args)); } 

यहां हम एक फ़ंक्शन बनाते हैं जो उन्हें संयोजित करने के लिए कार्यों की एक सूची को स्वीकार करता है। यह एक नया कॉलबैक देता है, जो समान तर्क के साथ उन सभी को कॉल करता है।

इस फ़ंक्शन का उपयोग इस तरह से किया जा सकता है:

 function ToolTip(props) { const [isVisible, setVisible] = React.useState(false); return ( <span {...props} className={classNames('tooltip', props.className)} onMouseIn={combine(() => setVisible(true), props.onMouseIn)} onMouseOut={combine(() => setVisible(false), props.onMouseOut)} /> ); } 

7. डिफ़ॉल्ट मानों का उपयोग करें

सुनिश्चित करें कि आप अपने प्रॉप्स को पर्याप्त डिफॉल्ट्स (चूक) दें। इस प्रकार, आप अनिवार्य सहारा की संख्या कम कर देंगे। यह आपके एपीआई को बहुत सरल करेगा।

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

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

8. HTML विशेषताओं का नाम बदलने की आवश्यकता नहीं है

एक भाषा के रूप में एचटीएमएल का अपना एक सहारा है - या विशेषताएँ, और यह स्वयं HTML तत्वों के लिए एक एपीआई है। तो क्यों नहीं इस एपीआई का उपयोग करते रहें?

जैसा कि हमने पहले उल्लेख किया है, एपीआई सतह को कम करना और इसकी तीव्रता आपके घटकों के एपीआई को बेहतर बनाने के लिए उपयोगी तरीके हैं। तो अपने screenReaderLabel प्रॉप को बनाने के बजाय, मौजूदा screenReaderLabel aria-label उपयोग क्यों न करें?

अपने "उपयोग में आसानी" के लिए किसी भी मौजूदा HTML विशेषताओं का नाम बदलने से दूर रहें । आप मौजूदा API की जगह भी नहीं लेते - आप बस इसके ऊपर अपना खुद का जोड़ देते हैं। लोग अभी भी आपके स्क्रीन के साथ aria-label पास कर सकते हैंरेलेबेल screenReaderLabel - और फिर अंतिम मूल्य क्या होना चाहिए?

इसके अलावा, सुनिश्चित करें कि आप कभी भी अपने घटकों में HTML विशेषताओं को ओवरराइड नहीं करते हैं। एक महान उदाहरण <button /> तत्व का type विशेषता है। इसे submit (डिफ़ॉल्ट), button या reset किया जा सकता है। हालांकि, कई डेवलपर्स बटन के दृश्य प्रकार ( primary , cta , आदि) को निरूपित करने के लिए इस प्रोप को फिर से परिभाषित करते हैं।

यदि आप इस तरह के प्रोप का उपयोग करेंगे, तो आपको सही type विशेषता के लिए एक ओवरराइड जोड़ना होगा। इससे डेवलपर्स की ओर से भ्रम, संदेह और झुंझलाहट पैदा होगी।

मेरा विश्वास करो - मैंने यह गलती बार-बार की - यदि आप इसे बनाते हैं, तो आपको इसे लंबे समय तक विघटित करना होगा।

9. सहारा के प्रकार (या सिर्फ प्रकार) लिखें

कोई भी दस्तावेज़ आपके कोड के अंदर रहने वाले दस्तावेज़ के रूप में अच्छा नहीं होगा। रीप prop-types पैकेज का उपयोग करके आपके एपीआई की घोषणा करने का एक शानदार तरीका है। इसका उपयोग करें।

आप अपने अनिवार्य और वैकल्पिक सहारा के लिए किसी भी प्रारूप की आवश्यकताओं को निर्दिष्ट कर सकते हैं, और आप उन्हें JSDoc टिप्पणियों के साथ सुधार सकते हैं।

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

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

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

10. डेवलपर्स के लिए डिजाइन

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

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

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

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

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

तो अपने भविष्य के उपयोगकर्ताओं के लिए डिज़ाइन करें। भविष्य से अपने लिए डिजाइन करें। जब आप बाहर निकलते हैं, तो दुर्भाग्यपूर्ण के लिए डिज़ाइन करें, जिसे आपके कोड को बनाए रखना होगा! डेवलपर्स के लिए डिजाइन।

कुल मिलाकर

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