Redux / NgRx के बिना प्रतिक्रियाशील अनुप्रयोग

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

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

लेकिन ये उपकरण हमारे अनुप्रयोगों को बहुत अच्छी सुविधाएँ देते हैं:

• पूर्वानुमानित डेटा प्रवाह;
• समर्थन डिजाइन द्वारा OnPush;
• डेटा की अपरिवर्तनीयता, संचित दुष्प्रभावों की कमी और अन्य सुखद चीजें।

हम समान विशेषताओं को प्राप्त करने की कोशिश करेंगे, लेकिन अतिरिक्त जटिलता को पेश किए बिना।

जैसा कि आप लेख के अंत तक देखेंगे, यह एक काफी सरल कार्य है - यदि आप लेख से कोणीय और ऑनपश के विवरण को हटाते हैं, तो केवल कुछ सरल विचार हैं।

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

लेख के एक आरामदायक पढ़ने के लिए, शब्दों को स्मार्ट, प्रस्तुतिकरण और कंटेनर घटकों की समझ की आवश्यकता होती है।

कार्य योजना

आवेदन का तर्क, साथ ही सामग्री की प्रस्तुति का क्रम, निम्नलिखित चरणों के रूप में वर्णित किया जा सकता है:

1. पढ़ने के लिए अलग डेटा (GET) और लेखन (PUT / POST)
2. कंटेनर घटक में धारा के रूप में लोड स्थिति
3. राज्य को ऑनपश घटकों के एक पदानुक्रम को वितरित करें
4. घटक परिवर्तनों के बारे में कोणीय को सूचित करें
5. समझाया डेटा संपादन

OnPush को लागू करने के लिए, हमें Angular में परिवर्तन का पता लगाने के लिए सभी तरीकों को पार्स करने की आवश्यकता है। इस तरह के केवल चार तरीके हैं, और हम पूरे लेख में क्रमिक रूप से उन पर विचार करेंगे।

तो चलिए चलते हैं।

पढ़ने और लिखने के लिए डेटा साझा करें

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

हम जिस डेमो प्रोजेक्ट पर विचार कर रहे हैं, उसमें वास्तविक बैकएंड नहीं है, लेकिन इसमें पूर्व-तैयार विवरण फ़ाइल swagger.json है । इसके आधार पर, टाइपस्क्रिप्ट अनुबंधों को sw2dts उपयोगिता द्वारा उत्पन्न किया जाता है।

उत्पन्न अनुबंधों में दो महत्वपूर्ण गुण होते हैं।

सबसे पहले, पढ़ना और लिखना विभिन्न अनुबंधों का उपयोग करके किया जाता है। हम एक छोटे से सम्मेलन का उपयोग करते हैं और प्रत्यय "राज्य" के साथ अनुबंध पढ़ने के लिए संदर्भित करते हैं, और प्रत्यय "मॉडल" के साथ अनुबंध लिखते हैं।

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

दूसरा महत्वपूर्ण बिंदु यह है कि सभी राज्य क्षेत्र आसानी से संशोधित किए गए हैं। इसलिए हमें टाइपस्क्रिप्ट स्तर पर प्रतिरक्षा सहायता मिलती है। अब हम गलती से राज्य को कोड में नहीं बदल सकते हैं या [(ngModel)] का उपयोग करके इसे बांध सकते हैं - जब AOT मोड में आवेदन को संकलित करते हैं, तो हमें एक त्रुटि मिलेगी।

कंटेनर घटक में धारा के रूप में लोड स्थिति

राज्य को लोड करने और आरंभ करने के लिए, हम साधारण कोणीय सेवाओं का उपयोग करेंगे। वे निम्नलिखित परिदृश्यों के लिए जिम्मेदार होंगे:

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

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

एक सेवा का एक उदाहरण फ़ाइल में पाया जा सकता है कुछ-Unit.service.ts ।

यह कंटेनर घटक और लोड स्थिति में DI के माध्यम से सेवा प्राप्त करने के लिए बनी हुई है। यह आमतौर पर इस तरह किया जाता है:

route.params .pipe( pluck('id'), filter((id: any) => { return !!id; }), switchMap((id: string) => { return myFormService.get(id); }) ) .subscribe(state => { this.state = state; }); 

लेकिन इस दृष्टिकोण के साथ, दो समस्याएं उत्पन्न होती हैं:

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

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

Async पाइप का उपयोग करने का एक उदाहरण कुछ-निकाय । Com घटक के लिए टेम्पलेट में पाया जा सकता है।

और घटक कोड में, हमने कस्टम आरएक्सजेएस ऑपरेटरों में दोहराया तर्क को हटा दिया, एक खाली स्थिति बनाने के लिए स्क्रिप्ट को जोड़ा, दोनों राज्य स्रोतों को मर्ज ऑपरेटर के साथ एक धारा में विलय कर दिया और संपादन के लिए एक फॉर्म तैयार किया, जिसे हम बाद में चर्चा करेंगे:

 this.state$ = merge( route.params.pipe( switchIfNotEmpty("id", (requestId: string) => requestService.get(requestId) ) ), route.params.pipe( switchIfEmpty("id", () => requestService.getEmptyState()) ) ).pipe( tap(state => { this.form = new SomeEntityFormGroup(state); }) ); 

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

राज्य को ऑनपश घटकों के एक पदानुक्रम को वितरित करें

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

एक नियम के रूप में, घटकों को डेटा पदानुक्रम के समान एक पदानुक्रम में विभाजित किया जाता है, और प्रत्येक घटक टेम्पलेट में उन्हें प्रदर्शित करने के लिए इनपुट मापदंडों के माध्यम से डेटा का अपना टुकड़ा प्राप्त करता है।

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

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

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

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

क्या करें?

यदि घटक किसी भी वैश्विक प्रभाव पर निर्भर नहीं करता है (वैसे, इस तरह से घटकों को डिजाइन करना बेहतर है), तो इसकी आंतरिक स्थिति निम्न द्वारा निर्धारित की जाती है:

• इनपुट पैरामीटर ( @Input );
• घटक में होने वाली घटनाएँ ( @Output )।

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

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

इस प्रकार, यदि हम OnPush रणनीति के अनुसार अपने पूरे एप्लिकेशन का निर्माण करते हैं, तो हम शुरुआत से ही प्रदर्शन समस्याओं की एक पूरी श्रेणी को समाप्त कर देंगे।

चूंकि हमारे आवेदन में राज्य पहले से ही अपरिवर्तनीय है, इसलिए अपरिवर्तनीय वस्तुओं को भी बाल घटकों के इनपुट मापदंडों में स्थानांतरित किया जाता है। यही है, हम बाल घटकों के लिए ऑनपश को सक्षम करने के लिए तैयार हैं और वे राज्य परिवर्तनों का जवाब देंगे।
उदाहरण के लिए, ये readonly -info.component और nested-items.component घटक हैं

अब देखते हैं कि OnPush प्रतिमान में घटकों की स्थिति में परिवर्तन को कैसे लागू किया जाए।

अपनी स्थिति के बारे में कोणीय से बात करें

प्रस्तुति की स्थिति - ये घटक की उपस्थिति के लिए जिम्मेदार पैरामीटर हैं: संकेतक लोड करना, तत्वों की दृश्यता के झंडे या एक या किसी अन्य उपयोगकर्ता की पहुंच, तीन फ़ील्ड से उपयोगकर्ता के नाम की एक पंक्ति से चिपके हुए, आदि।

हर बार एक घटक की प्रस्तुति स्थिति में परिवर्तन होता है, हमें कोणीय को सूचित करना चाहिए ताकि वह UI पर परिवर्तनों को प्रदर्शित कर सके।

घटक की स्थिति का स्रोत क्या है इसके आधार पर, कोणीय को सूचित करने के कई तरीके हैं।

प्रस्तुति स्थिति, इनपुट मापदंडों के आधार पर गणना की जाती है

यह सबसे आसान विकल्प है। हम प्रस्तुति स्टेट कम्प्यूटेशन लॉजिक को ngOnChanges हुक में रखते हैं। परिवर्तन का पता @ इनपुट-मापदंडों को बदलकर स्वयं ही प्रारंभ हो जाएगा। डेमो में, यह readonly-info.component है ।

 export class ReadOnlyInfoComponent implements OnChanges { @Input() public state: Backend.SomeEntityState; public traits: ReadonlyInfoTraits; public ngOnChanges(changes: { state: SimpleChange }): void { this.traits = new ReadonlyInfoTraits(changes.state.currentValue); } } 

सब कुछ बेहद सरल है, लेकिन एक बिंदु है जिस पर ध्यान दिया जाना चाहिए।

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

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

घटक मूल घटनाएँ

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

डेमो प्रोजेक्ट में, यह पूरी तरह से सिंथेटिक है, लेकिन एक उदाहरण घटक submit- button.component है , जो एक फॉर्मवेटेड ईवेंट फेंकता है। कंटेनर घटक इस घटना के लिए सदस्यता लेता है और एक अधिसूचना के साथ एक अलर्ट प्रदर्शित करता है।

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

स्मार्ट घटकों में परिवर्तन

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

सामान्य तौर पर, एप्लिकेशन में कम स्मार्ट घटक जो कंटेनर घटक नहीं होते हैं, यह जीना आसान होगा। लेकिन कभी-कभी आप उनके बिना नहीं कर सकते।

परिवर्तन का पता लगाने के साथ एक स्मार्ट घटक की स्थिति को जोड़ने का सबसे सरल तरीका यह है कि इसे एक ऑब्जर्वेबल में बदल दिया जाए और ऊपर बताए गए async पाइप का उपयोग किया जाए। उदाहरण के लिए, यदि परिवर्तनों का स्रोत एक सेवा कॉल या प्रतिक्रियाशील रूप स्थिति है, तो यह एक तैयार किया गया अवलोकन है। यदि राज्य कुछ और जटिल से बनता है, तो आप RxJS की संरचना से Promise , websocket , टाइमर , अंतराल का उपयोग कर सकते हैं। या Subject का उपयोग करके अपने आप एक स्ट्रीम तैयार करें।

यदि कोई भी विकल्प उपयुक्त नहीं है

उन मामलों में जहां पहले से अध्ययन किए गए तीन तरीकों में से कोई भी उपयुक्त नहीं है, हमारे पास अभी भी बुलेटप्रूफ विकल्प है - ChangeDetectorRef का सीधे उपयोग करना । हम इस वर्ग के पता लगाने के तरीके और निशान के तरीके के बारे में बात कर रहे हैं।

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

हर समय हमें केवल कुछ ही मामले मिलते हैं जहाँ इस पद्धति की आवश्यकता हो सकती है:

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

डेमो एप्लिकेशन में उपयोग के उदाहरण के रूप में, आधार वर्ग OnPushControlValueAccessor है , जो अंतिम पैराग्राफ में वर्णित समस्या को हल करता है। इसके अलावा परियोजना में इस वर्ग के लिए एक वारिस है - कस्टम रेडियो-बटन.कॉम ।

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

समझाया डेटा संपादन

प्रतिक्रियात्मक रूपों में कई सीमाएँ हैं, लेकिन फिर भी यह सबसे अच्छी चीजों में से एक है जो कि कोणीय पारिस्थितिकी तंत्र में हुई थी।

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

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

यह हमारे लिए रहता है कि हम इस एनकैप्सुलेशन का यथासंभव समर्थन करें और प्रस्तुति-तर्क और रूप के तर्क को मिलाने से बचें।

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

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

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

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

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

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

यह लगभग सभी है। जब हम आवेदन के बाकी हिस्सों से फॉर्म लॉजिक को अलग नहीं कर सकते तो बॉर्डर केस बचे हैं:

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

इस प्रकार, सभी "सीमा रेखा" तर्क सबसे प्रमुख स्थान पर है - घटकों में।

निष्कर्ष

आइए संक्षेप में बताएं कि अध्ययन और विकास के लिए हमें क्या मिला और क्या अन्य बिंदु हैं।

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

इस स्थिति के दो परिणाम हैं।

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

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

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

हमने प्रदर्शन पर अच्छे प्रभावों का भी उल्लेख किया। अब, बहुत ही सरल उपकरणों का उपयोग कर, जैसे कि profiler.timeChangeDetection , हम किसी भी समय यह देख सकते हैं कि हमारा आवेदन अभी भी ठीक है।

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

यहीं पर हम अपनी कहानी समाप्त करते हैं।

हम संपर्क में रहेंगे!