👵🏻 👨🏻‍🏫 💉 5 चीजें मैं जानना चाहूंगा कि मैंने कब कोणीय का उपयोग करना शुरू किया 🔜 🤟🏻 ⏹️

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

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

निर्भरता इंजेक्शन (DI)

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

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

कल्पना कीजिए कि हमारे आवेदन में एक JokerService वर्ग है जो चुटकुलों का प्रबंधन करता है। getJokes() विधि चुटकुलों की सूची लौटाती है। मान लीजिए कि हम इसे तीन स्थानों पर उपयोग करते हैं। कोड में तीन अलग-अलग स्थानों पर चुटकुले कैसे प्राप्त करें? कई तरीके हैं:

हर जगह कक्षा का एक उदाहरण बनाएं। लेकिन हमें मेमोरी को बंद करने और इतने सारे समान सेवाओं को बनाने की आवश्यकता क्यों है? और अगर 100 सीटें हैं?
विधि को स्थिर करें और JokerService.getJokes () का उपयोग करके डेटा पुनर्प्राप्त करें।
डिजाइन पैटर्न में से एक को लागू करें। यदि हमें संपूर्ण एप्लिकेशन के लिए सेवा की आवश्यकता है, तो यह सिंगलटन होगा। लेकिन इसके लिए आपको कक्षा में एक नया तर्क लिखना होगा।

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

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

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

यह पता चला है कि दूसरा विकल्प हमें सूट नहीं करेगा: यह हमें हर जगह बहुत सारे कोड डुप्लिकेट करेगा। यह केवल सिंगलटन बना हुआ है, जिसे फिर से तर्क को अद्यतन करने की आवश्यकता होगी, लेकिन विविधताओं के साथ। लेकिन कैसे समझें कि हमें किस विकल्प की आवश्यकता है?

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

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

कोणीय में निर्भरता इंजेक्शन

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

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

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

 @Component({ selector: 'jokes', template: './jokes.template.html', }) export class JokesComponent { private jokes: Observable<IJoke[]>; constructor(private jokerService: JokerService) { this.jokes = this.jokerService.getJokes(); } }

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

प्रदाताओं

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

 @Injectable({ providedIn: 'root', //   ,   «»  }) export class JokerService { getJokes(): Observable<IJoke[]> { //     } }

जब पूरे आवेदन के लिए सेवा एक है, तो यह विकल्प पर्याप्त होगा। लेकिन क्या होगा अगर हम कहते हैं, JokerService दो कार्यान्वयन? या यह सिर्फ किसी कारण के लिए है कि एक विशिष्ट घटक को अपने स्वयं के सेवा उदाहरण की आवश्यकता है? उत्तर सरल है: provider ।

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

पूरे आवेदन में - प्रदान करें निर्दिष्ट करें provideIn: 'root' सेवा डेकोरेटर में ही provideIn: 'root' ।
मॉड्यूल में - प्रदाता के रूप में सेवा डेकोरेटर में प्रदाता निर्दिष्ट करें provideIn: JokesModule या @NgModule providers: [JokerService] में @NgModule providers: [JokerService] मॉड्यूल के डेकोरेटर में @NgModule providers: [JokerService] ।
घटक में - मॉड्यूल के डेकोरेटर में प्रदाता को निर्दिष्ट करें, जैसा कि मॉड्यूल में।

आपकी आवश्यकताओं के आधार पर स्थान चुना जाता है। हमने इस जगह का पता लगाया, चलो तंत्र पर ही चलते हैं। यदि हम केवल provideIn: root सेवा में provideIn: root , यह मॉड्यूल में निम्नलिखित प्रविष्टि के बराबर होगा:

 @NgModule({ // ...     providers: [{provide: JokerService, useClass: JokerService}], }) //

इसे कुछ इस तरह से पढ़ा जा सकता है: "अगर एक JokerService अनुरोध किया जाता है, तो JokerService» क्लास का एक उदाहरण दें JokerService» यहाँ से आप विभिन्न तरीकों से एक विशिष्ट उदाहरण प्राप्त कर सकते हैं:

टोकन द्वारा - आपको एक InjectionToken निर्दिष्ट करने और उस पर एक सेवा प्राप्त करने की आवश्यकता है। ध्यान दें कि नीचे दिए गए उदाहरणों में आप एक ही टोकन पास कर सकते हैं:
```
 const JOKER_SERVICE_TOKEN = new InjectionToken<string>('JokerService'); // ...     [{provide: JOKER_SERVICE_TOKEN, useClass: JokerService}]; 
```
वर्ग द्वारा - आप कक्षा को बदल सकते हैं। उदाहरण के लिए, हम JokerService लिए JokerService , और देंगे - JokerHappyService :
```
 [{provide: JokerService, useClass: JokerHappyService}]; 
```
मूल्य से - आप तुरंत वांछित उदाहरण वापस कर सकते हैं:
```
 [{provide: JokerService, useValue: jokerService}]; 
```
फैक्ट्री द्वारा - आप क्लास को उस फैक्ट्री से बदल सकते हैं जो एक्सेस होने पर वांछित उदाहरण बनाएगी:
```
 [{provide: JokerService, useFactory: jokerServiceFactory}]; 
```

वह सब है। यही है, उदाहरण को एक विशेष उदाहरण के साथ हल करने के लिए, आप उपरोक्त विधियों में से किसी का उपयोग कर सकते हैं। अपनी आवश्यकताओं के लिए सबसे उपयुक्त चुनें।

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

एक छोटा सा सारांश

एक पूरी समझ के लिए, मैं सेवा उदाहरण का उपयोग करके चरणों में कोणीय में सरलीकृत निर्भरता इंजेक्शन तंत्र पर विचार करने का प्रस्ताव करता हूं:

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

पता लगाना बदलें

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

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

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

Zone.js

यह समझना कि एंगुलर वर्ग के गुणों पर कैसे नज़र रखता है और समकालिक संचालन बहुत सरल है। लेकिन यह अतुल्यकालिक कैसे ट्रैक करता है? कोणीय डेवलपर्स में से एक द्वारा बनाई गई जोन.जेएस लाइब्रेरी, इसके लिए जिम्मेदार है।

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

ज़ोन.जेएस अपने कार्यान्वयन के साथ लगभग सभी मूल अतुल्यकालिक कार्यों और विधियों की जगह लेता है। इसलिए, यह ट्रैक कर सकता है जब एक अतुल्यकालिक फ़ंक्शन callback कहा जाएगा। यही है, ज़ोन परिवर्तन सत्यापन प्रक्रिया शुरू करने के लिए कब और कहाँ कोणीय बताता है।

परिवर्तन रणनीतियाँ

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

कोणीय डेवलपर्स ने इस बारे में सोचा और हमें परिवर्तन का पता लगाने की रणनीति स्थापित करने का अवसर दिया, जिसका सही विकल्प उत्पादकता में काफी वृद्धि कर सकता है।

चुनने के लिए दो विकल्प हैं:

डिफ़ॉल्ट - जैसा कि नाम से पता चलता है, यह डिफ़ॉल्ट रणनीति है जब प्रत्येक क्रिया के लिए एक सीडी लॉन्च की जाती है।
ऑनपश एक रणनीति है जिसमें केवल कुछ मामलों में एक सीडी लॉन्च की जाती है:
- यदि @Input() का मान बदल गया है;
- अगर घटक या उसके वंश के अंदर कोई घटना घटित हुई है;
- यदि चेक मैन्युअल रूप से शुरू किया गया था;
- यदि कोई नई घटना Async पाइप में आती है।

कोणीय पर अपने स्वयं के विकास के अनुभव के साथ-साथ अपने सहकर्मियों के अनुभव के आधार पर, मैं यह सुनिश्चित करने के लिए कह सकता हूं कि OnPush रणनीति को निर्दिष्ट करना हमेशा बेहतर होता है, जब तक कि default वास्तव में आवश्यक न हो। इससे आपको कई फायदे मिलेंगे:

सीडी प्रक्रिया कैसे काम करती है, इसकी स्पष्ट समझ।
@Input() गुणों के साथ नीट कार्य।
प्रदर्शन लाभ।

`@Input()` साथ काम करें

अन्य लोकप्रिय रूपरेखाओं की तरह, एंगुलर एक डाउनस्ट्रीम डेटा स्ट्रीम का उपयोग करता है। घटक @Input() डेकोरेटर के साथ चिह्नित इनपुट मापदंडों को स्वीकार करता है। एक उदाहरण पर विचार करें:

 interface IJoke { author: string; text: string; } @Component({ selector: 'joke', template: './joke.template.html', }) export class JokeComponent { @Input() joke: IJoke; }

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

 setAuthorNameOnly() { const name = this.joke.author.split(' ')[0]; this.joke.author = name; }

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

 @Component({ selector: 'joke', template: './joke.template.html', changeDetection: ChangeDetectionStrategy.OnPush, }) export class JokeComponent { @Input() readonly joke: IJoke; @Output() updateName = new EventEmitter<string>(); setAuthorNameOnly() { const name = this.joke.author.split(' ')[0]; this.updateName.emit(name); } }

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

RxJS

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

लेकिन आरएक्सजेएस क्या है? यह तीन विचारों को जोड़ती है जिन्हें मैं कुछ सरल भाषा में कुछ चूक के साथ प्रकट करूंगा:

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

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

 private loadUnreadJokes() { this.showLoader(); //   fromEvent(document, 'load') .pipe( switchMap( () => this.http .get('/api/v1/jokes') //   .pipe(map((jokes: any[]) => jokes.filter(joke => joke.unread))), //   ), ) .subscribe( (jokes: any[]) => (this.jokes = jokes), //   error => { /*   */ }, () => this.hideLoader(), //       ); }

सभी सुंदर इंडेंटेशन के साथ केवल 18 लाइनें। अब इस उदाहरण को वेनिला या कम से कम jQuery पर फिर से लिखने का प्रयास करें। इसका लगभग 100% आपको कम से कम दो बार ज्यादा जगह ले जाएगा और इतना अभिव्यंजक नहीं होगा। यहां आप बस अपनी आंखों के साथ लाइन का पालन कर सकते हैं और एक किताब की तरह कोड पढ़ सकते हैं।

नमूदार

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

 const observable = []; let counter = 0; const intervalId = setInterval(() => { observable.push(counter++); }, 1000); setTimeout(() => { clearInterval(intervalId); }, 6000);

हम सरणी में अंतिम मान को प्रासंगिक मानेंगे। हर दूसरे नंबर को ऐरे से जोड़ा जाएगा। हम उस एप्लिकेशन में कहीं और कैसे पता लगा सकते हैं कि एक तत्व को सरणी में जोड़ा गया है? एक सामान्य स्थिति में, हम किसी प्रकार की callback कॉल करेंगे और उस पर सरणी का मान अपडेट करेंगे, और फिर अंतिम तत्व ले लेंगे।

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

 document.addEventListener('click', event => {});

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

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

अब एक वास्तविक उदाहरण देखते हैं:

 export class JokesListComponent implements OnInit { jokes$: Observable<IJoke>; authors$ = new Subject<string[]>(); unread$ = new Subject<number>(); constructor(private jokerService: JokerService) {} ngOnInit() { //  ,    subscribe()    this.jokes$ = this.jokerService.getJokes(); this.jokes$.subscribe(jokes => { this.authors$.next(jokes.map(joke => joke.author)); this.unread$.next(jokes.filter(joke => joke.unread).length); }); } }

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

टेस्टबेड

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

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

आप कोणीय में कुछ भी परीक्षण कर सकते हैं, लेकिन अगर आपको बस एक नियमित वर्ग या सेवा का परीक्षण करने के लिए तुरंत कॉल करने और कॉल करने के तरीकों की आवश्यकता है, तो घटक के साथ स्थिति पूरी तरह से अलग है।

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

 @Component({ selector: 'app-joker', template: '<some-dependency></some-dependency>', styleUrls: ['./joker.component.less'], }) export class JokerComponent { constructor( private jokesService: JokesService, @Inject(PARTY_TOKEN) private partyService: PartyService, @Optional() private sleepService: SleepService, ) {} makeNewFriend(): IFriend { if (this.sleepService && this.sleepService.isSleeping) { this.sleepService.wakeUp(); } const joke = this.jokesService.generateNewJoke(); this.partyService.goToParty('Pacha'); this.partyService.toSay(joke.text); const laughingPeople = this.partyService.getPeopleByReaction('laughing'); const girl = laughingPeople.find(human => human.sex === 'female'); const friend = this.partyService.makeFriend(girl); return friend; } }

तो, वर्तमान उदाहरण में तीन सेवाएं हैं। एक सामान्य तरीके से आयात किया जाता है, एक टोकन द्वारा और दूसरा सेवा वैकल्पिक है। हम परीक्षण मॉड्यूल को कैसे कॉन्फ़िगर करते हैं? मैं तुरंत समाप्त दृश्य दिखाऊंगा:

 beforeEach(async(() => { TestBed.configureTestingModule({ imports: [SomeDependencyModule], declarations: [JokerComponent], //  ,    providers: [{provide: PARTY_TOKEN, useClass: PartyService}], }).compileComponents(); fixture = TestBed.createComponent(JokerComponent); component = fixture.componentInstance; fixture.detectChanges(); //    ,     }));

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

अनावश्यक निर्भरता से बचा जा सकता है

एक कोणीय अनुप्रयोग में मॉड्यूल होते हैं, जिसमें अन्य मॉड्यूल, सेवाएं, निर्देश, और बहुत कुछ शामिल हो सकते हैं। परीक्षण में, हमें वास्तव में, मॉड्यूल के संचालन को फिर से बनाने की आवश्यकता है। यदि हमारे उदाहरण में, हम टेम्पलेट में <some-dependency></some-dependency> का उपयोग करते हैं, तो इसका अर्थ है कि हमें <some-dependency></some-dependency> को परीक्षण में भी आयात करना होगा। और अगर वहाँ व्यसनों रहे हैं? इसलिए, उन्हें भी आयात करने की आवश्यकता है।
यदि आवेदन जटिल है, तो इस तरह की बहुत सारी निर्भरताएं होंगी। सभी आश्रितों को आयात करने से तथ्य यह होगा कि प्रत्येक परीक्षण में संपूर्ण आवेदन स्थित होगा और सभी विधियों को बुलाया जाएगा। शायद यह हमें शोभा नहीं देता।

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

 TestBed.configureTestingModule({ declarations: [JokerComponent], providers: [{provide: PARTY_TOKEN, useClass: PartyService}], }) .overrideTemplate(JokerComponent, '') //   ,   .compileComponents();

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

आप कंस्ट्रक्टर से सभी निर्भरता को गीला कर सकते हैं

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

ts-mockito , , . Angular « ».

 //    export class MockPartyService extends PartyService { meetFriend(): IFriend { return {} as IFriend; } goToParty() {} toSay(some: string) { console.log(some); } } // ... TestBed.configureTestingModule({ declarations: [JokerComponent, MockComponent], providers: [{provide: PARTY_TOKEN, useClass: MockPartyService}], //    }).compileComponents();

वह सब है। .

. , — , — . , :

.
— , . — .

— . , . — .

परिणाम

Angular, . , , «».

, Angular - . HTTP-, , lazy-loading . Angular .

5 चीजें मैं जानना चाहूंगा कि मैंने कब कोणीय का उपयोग करना शुरू किया