कोणीय में मॉड्यूल के प्रबंधन के लिए दृष्टिकोण (और न केवल)

आपके साथ काम करने वाली संस्थाओं के संगठन को समझना कुछ ऐसा नहीं है जो तुरंत एक डेवलपर से आता है जो एंगुलर में अपनी पहली परियोजनाओं को लिख रहा है।

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

सौभाग्य से, एंगुलर डेवलपर्स को अपने स्वयं के मॉड्यूल बनाने की क्षमता प्रदान करता है, और उन्हें फीचर मॉड्यूल भी कहता है।

डोमेन फ़ीचर मॉड्यूल

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

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

नीले फ्रेम में सभी विज्ञापन, साथ ही अन्य मेनू आइटम की सामग्री, अपने स्वयं के डोमेन फ़ीचर मॉड्यूल के लायक है।

डोमेन फ़ीचर मॉड्यूल असीमित संख्या में घोषणाओं (घटकों, निर्देशों, पाइपों) का उपयोग कर सकते हैं, हालांकि वे केवल उस घटक को निर्यात करते हैं जो इस मॉड्यूल के UI का प्रतिनिधित्व करता है। डोमेन फीचर मॉड्यूल आयात किया जाता है, आमतौर पर एक में, बड़ा मॉड्यूल।

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

आलसी लोड हो रहा है

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

सेवाएँ और इंजेक्टर

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

आलसी लोडेड मॉड्यूल के इंजेक्टर

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

यह पता चला है कि सेवाओं को किसी भी मॉड्यूल में घोषित किया जा सकता है और चिंता नहीं? वास्तव में ऐसा नहीं है।

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

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

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

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

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

डोमेन सुविधा मॉड्यूल पर वापस लौटना, वर्णित व्यवहार उन में विज्ञापनदाताओं के जीवन को सीमित करने का एक तरीका है।

कोर मॉड्यूल

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

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

इस तथ्य के अलावा कि यह दृष्टिकोण बिना मॉड्यूल के कोणीय भविष्य के उज्ज्वल भविष्य में दिखता है, यह अनावश्यक कोड को कम करने में भी मदद करता है।

सिंगलटन टेस्ट

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

कोर मॉड्यूल में एक कंस्ट्रक्टर जोड़ें जो आपको कोर मॉड्यूल को इसमें इंजेक्ट करने के लिए कहता है (यह सही है, खुद), और इस घोषणा को वैकल्पिक और SkipSelf सज्जाकार के साथ चिह्नित करें। यदि इंजेक्टर एक चर में निर्भरता रखता है, तो कोई कोर मॉड्यूल को फिर से घोषित करने की कोशिश कर रहा है।

BrowserModule में वर्णित दृष्टिकोण का उपयोग करना।

इस दृष्टिकोण का उपयोग मॉड्यूल और सेवाओं दोनों के साथ किया जा सकता है।

घटक में सेवा घोषणा

हमने पहले ही आलसी लोडिंग का उपयोग करने वाले प्रदाताओं के दायरे को सीमित करने का एक तरीका माना है, लेकिन यहां एक और एक है।

प्रत्येक घटक उदाहरण का अपना इंजेक्टर है, और इसे कॉन्फ़िगर करने के लिए, NgModule डेकोरेटर की तरह, कंपोनेंट डेकोरेटर के पास प्रदाताओं की संपत्ति है। और यह भी - viewProviders की एक अतिरिक्त संपत्ति। वे दोनों इंजेक्टर घटकों को कॉन्फ़िगर करने की सेवा करते हैं, हालांकि, प्रत्येक विधियों में घोषित प्रदाताओं में अलग-अलग स्कोप हैं।

अंतर को समझने के लिए, आपको एक छोटी पृष्ठभूमि की आवश्यकता है।

एक घटक में दृश्य और सामग्री शामिल होती है।

घटक देखें

सामग्री घटक

घटक की HTML फ़ाइल में वह सब कुछ है, जबकि उसके खुलने और बंद होने के बीच पारित होने वाले घटक टैग इसकी सामग्री है।

प्राप्त परिणाम:

परिणाम

इसलिए, प्रदाताओं के लिए जोड़े गए प्रदाता दोनों घटक के दृश्य में उपलब्ध हैं जिसमें वे घोषित किए जाते हैं, और उस सामग्री के लिए जिसे घटक को पारित किया जाता है। जबकि ViewProviders, जैसा कि नाम का अर्थ है, सेवाओं को केवल देखने के लिए दृश्यमान बनाता है और उन्हें सामग्री के लिए बंद कर देता है।

इस तथ्य के बावजूद कि रूट इंजेक्टर में सेवाओं की घोषणा करना सबसे अच्छा अभ्यास है, इंजेक्टर घटक का उपयोग करते समय परिदृश्य होते हैं:

पहला यह है कि प्रत्येक नए घटक की अपनी सेवा आवृत्ति होनी चाहिए। उदाहरण के लिए, एक ऐसी सेवा जो किसी घटक के प्रत्येक नए उदाहरण के लिए विशिष्ट डेटा संग्रहीत करती है।

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

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

पुन: प्रयोज्य अवयव

जिन घटकों का हम पुन: उपयोग करना चाहते हैं, उनका क्या करना है? इस प्रश्न का कोई निश्चित उत्तर नहीं है, लेकिन सिद्ध दृष्टिकोण हैं।

साझा मॉड्यूल

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

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

इस तरह के एक मॉड्यूल को आमतौर पर SharedModule कहा जाता है।

यह ध्यान रखना महत्वपूर्ण है कि SharedModule को सेवाओं की घोषणा नहीं करनी चाहिए। या forRoot दृष्टिकोण का उपयोग कर घोषित करें। हम उसके बारे में थोड़ी देर बाद बात करेंगे।

हालांकि SharedModules दृष्टिकोण काम करता है, इसके कुछ बिंदु हैं:

1. हमने एप्लिकेशन संरचना को क्लीनर नहीं बनाया, हमने बस गंदगी को एक स्थान से दूसरे स्थान पर स्थानांतरित कर दिया;
2. यह दृष्टिकोण कोणीय के उज्ज्वल भविष्य में नहीं दिखता है, जिसमें कोई मॉड्यूल नहीं होगा।

एक दृष्टिकोण जो इन कमियों से रहित है और इसमें प्रत्येक घटक के लिए एक मॉड्यूल का निर्माण शामिल है।

मॉड्यूल प्रति घटक या SCAM (एकल घटक कोणीय मॉड्यूल)

एक नया घटक बनाते समय, आपको इसे अपने मॉड्यूल में रखना चाहिए। आपको एक ही मॉड्यूल में घटक निर्भरता को आयात करना होगा।

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

अंग्रेजी में, इस दृष्टिकोण को प्रति घटक मॉड्यूल या SCAM कहा जाता है - एकल घटक कोणीय मॉड्यूल। यद्यपि नाम में शब्द घटक होता है, यह दृष्टिकोण पाइप और निर्देशों (SPAM, SDAM) पर भी लागू होता है।

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

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

ModuleWithProviders इंटरफ़ेस

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

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

रणनीतियाँ forRoot (), forChild ()

वैश्विक इंजेक्टर में ठीक से तय की जाने वाली सेवाओं के लिए, प्रदाताओं के साथ मॉड्यूल केवल AppModule में आयात किया जाता है। आयातित मॉड्यूल की ओर से, आपको केवल एक स्थिर विधि बनाने की आवश्यकता होती है जो ModuleWithProviders को लौटाती है, जिसे ऐतिहासिक रूप से forRoot नाम मिला है।

ModuleWithProviders को वापस करने वाले तरीके किसी भी संख्या में हो सकते हैं, और उन्हें आपके पसंद के अनुसार नाम दिया जा सकता है। forRoot एक आवश्यकता से अधिक सुविधाजनक सम्मेलन है।

उदाहरण के लिए, राउटरमॉड्यूल में एक स्टेटिक फोरहिल विधि है, जिसका उपयोग आलसी लोड किए गए मॉड्यूल में रूटिंग को कॉन्फ़िगर करने के लिए किया जाता है।

निष्कर्ष:

1. उपयोगकर्ता इंटरफ़ेस को मुख्य कार्यों से अलग करें और प्रत्येक चयनित भाग के लिए अपना स्वयं का मॉड्यूल बनाएं: प्रोजेक्ट कोड की संरचना को समझने के लिए अधिक सुविधाजनक के अलावा, इंटरफ़ेस के कुछ हिस्सों को लोड करने का अवसर प्राप्त करें
2. यदि एप्लिकेशन आर्किटेक्चर को इसकी आवश्यकता है, तो आलसी लोड किए गए मॉड्यूल और घटकों के इंजेक्टर का उपयोग करें
3. एक अलग मॉड्यूल, कोर मॉड्यूल में वैश्विक सेवा घोषणाओं को पोस्ट करें, और इसे केवल ऐप मॉड्यूल में आयात करें। यह एप मॉड्यूल को साफ करने में मदद करेगा।
4. बेहतर, Injectable डेकोरेटर के मूल मूल्य के साथ दिए गए विकल्प में उपयोग करें।
5. मॉड्यूल और सेवाओं के फिर से आयात को रोकने के लिए वैकल्पिक और SkipSelf सज्जाकारों के साथ हैक का उपयोग करें
6. साझा मॉड्यूल में पुन: प्रयोज्य घटकों, निर्देशों और पाइपों को स्टोर करें
7. हालांकि, सबसे अच्छा दृष्टिकोण, जो भविष्य में भी दिखता है, और परीक्षण की सुविधा प्रत्येक घटक (निर्देश और पाइप, भी) के लिए एक मॉड्यूल बनाने के लिए है
8. यदि आप प्रदाता विरोधों से बचना चाहते हैं तो ModuleWithProviders इंटरफ़ेस का उपयोग करें। एक लोकप्रिय तरीका यह है कि प्रदाताओं को रूट मॉड्यूल में जोड़ने के लिए forRoot पद्धति को लागू किया जाए