एंगुलर डेवलपर से स्वच्छ कोड के +10 नियम

नमस्कार, हेब्र!

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

1. पैटर्न में तर्क से बचें

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

<p *ngIf="isShow"> Example </p> 

 public ngOnInit(): void { this.isShow = true; } 

2. "सुरक्षित" लाइनें

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

 private value: 'One' | 'Two'; if (isShow) { value = 'One'; } else { value = 'Two' } 

इस तरह से एक चर के प्रकार की घोषणा करके, हम रनटाइम के बजाय संकलन समय पर कोड लिखते समय त्रुटियों से बच सकते हैं।

3. लंबी विधियों का नियम

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

4. कोड दोहराव

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

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

5. ट्रैकबी

चलो कोणीय के साथ काम करने की सूक्ष्मताओं की सूची को पतला करते हैं।

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

 <li *ngFor="let item of items; trackBy: trackByFn">{{ item }}</li> 

 trackByFn(index, item) { return item.id; //  ,   } 

जब सरणी बदल जाती है, तो कोणीय पूरे DOM पेड़ को फिर से प्रदर्शित करता है। लेकिन अगर आप trackBy का उपयोग करते हैं, तो कोणीय को पता चल जाएगा कि कौन सा तत्व बदल गया है और केवल उस विशेष तत्व के लिए DOM को बदल देगा।

6. टेम्पलेट में सदस्यता लें

मनाया घटक की सदस्यता के उदाहरण पर ध्यान दें:

 <p>{{ text }}</p> 

 blablaObservable .pipe( map(value => value.item), takeUntil(this._destroyed$) ) .subscribe(item => this.text = item); 

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

 <p>{{ text$ | async }}</p> 

 this.text$ = blablaObservable .pipe( map(value => value.item) ); 

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

7. आलसी लोडिंग

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

// app.rout.ts

 { path: 'dashboard', loadChildren: 'lazy-load.module#DashboardModule' } 

8. सदस्यता के अंदर सदस्यता

कभी-कभी किसी कार्रवाई को पूरा करने के लिए आपको एक से अधिक अवलोकन योग्य मूल्यों की आवश्यकता हो सकती है। इस मामले में, एक अवलोकन योग्य सदस्यता ब्लॉक में किसी अन्य अवलोकन के लिए सदस्यता लेने से बचें। इसके बजाय, उपयुक्त चेनिंग ऑपरेटरों का उपयोग करें। उनके सामने बयान से वेधशालाओं पर चेन स्टेटमेंट चलाया जाता है। कुछ चेन ऑपरेटर, जैसे किLatestFrom, CombLLest, आदि ...

करने के लिए:

 oneObservable$.pipe( take(1) ) .subscribe(oneValue => { twoObservable$.pipe( take(1) ) .subscribe(twoValue => { console.log([oneValue, twoValue].join(', ')); }); }); 

के बाद:

 oneObservable$.pipe( withLatestFrom(twoObservable$), first() ) .subscribe(([oneValue, twoValue]) => { console.log([oneValue, twoValue].join(', ')); }); 

9. कैशिंग

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

10. पुन: प्रयोज्य घटकों में क्रश

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

क्या आप ऐसे कॉलम को जारी रखना चाहेंगे?