मुझे ऐसा नहीं लगता कि ngModules उस सेटअप को प्रतिबंधित करता है जिसके लिए आप जा रहे हैं, क्या आपने अभी तक इसके साथ खेला है? आपके पास कई अलग-अलग मॉड्यूल हो सकते हैं और आलसी लोडिंग आदि कर सकते हैं। http://plnkr.co/edit/NAtRQJBy50R19QAl90jg?p=info

आप जो करने की कोशिश कर रहे हैं, उसके समान कुछ और के लिए, सामग्री 2 के संक्रमण पर नज़र रखें: https://github.com/angular/material2/pull/950/files

हाय @qdouble ,

त्वरित उत्तर के लिए धन्यवाद।
https://github.com/jelbourn/material2/blob/ecbb4f42e0473899f6ad15d8e4ed8f262ded7a99/src/components/button-toggle/button-toggle.ts को देखते हुए, क्या आप कह रहे हैं कि उसी कार्यक्षमता को प्राप्त करने के लिए जो हमारे पास अभी है, हमें चाहिए प्रत्येक घटक पर एक NgModule घोषित करने के लिए? (यही वह है जो फ़ाइल के अंत में जोड़ा गया था?)

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

@jpsfs यदि आप प्रत्येक घटक के लिए अलग-अलग दायरा बनाना चाहते हैं, तो मुझे लगता है कि आपको प्रत्येक के लिए अलग-अलग ngModules बनाना होगा। हालांकि यह आपके मामले में अधिक कोड बना सकता है, मुझे लगता है कि यह प्रति घटक के बजाय मेरे मॉड्यूल को स्कोप करके अन्य लोगों के विशाल बहुमत के लिए कम कोड बनाएगा।

जहां तक ​​​​दूसरे मुद्दे की बात है, आप एक दूसरे के ठीक बगल में ngModule और घटक की घोषणा कर सकते हैं, इसलिए जब यह आपकी फ़ाइलों में कोड की अतिरिक्त 3 या 4 पंक्तियाँ जोड़ देगा, तो मुझे नहीं लगता कि यह एक बहुत बड़ा मुद्दा बनाता है।

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

@qdouble धन्यवाद।

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

मैं इसे यह देखने के लिए खोल रहा हूं कि किसी के पास इस मामले में जोड़ने के लिए कुछ है या नहीं।

@jpsfs समझ गया, अगर मैं आपकी स्थिति में था, तो मैं निश्चित रूप से पसंद करूंगा कि वे दोनों विकल्प खुले छोड़ दें :)

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

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

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

यहां तक ​​कि मैं वर्तमान में एक विशाल एंटरप्राइज ऐप के लिए आर्किटेक्चर डिजाइन करने पर काम कर रहा हूं।
आपकी स्थिति @jpsfs के विपरीत, मैं NgModules से उत्साहित हूं और NgModule के आसपास अपने ऐप आर्किटेक्चर पर आधारित हूं।

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

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

मॉड्यूल का पदानुक्रम बनाना भी बहुत सरल है, और यह मुफ्त में शानदार प्लग एंड प्ले सुविधा प्रदान करता है।

हम वर्तमान में बहुत सारे घटकों (सैकड़ों नहीं बल्कि दर्जनों) के साथ एक एप्लिकेशन पर काम कर रहे हैं। इस एप्लिकेशन को कई (आलसी-लोडेड) मॉड्यूल में विभाजित करने के लिए हमारे लिए कोई वास्तुशिल्प आवश्यकता नहीं है, लेकिन अब उन सभी घटकों को बूटस्ट्रैप-फाइल में आयात करना और उन्हें declarations में पास करना किसी भी तरह गलत लगता है और घटक के इनकैप्सुलेशन को तोड़ देता है . जैसा कि @jpsfs ने कहा, इससे पहले यह बहुत स्पष्ट था कि कौन से घटक और निर्देश किसी अन्य घटक द्वारा उपयोग किए गए थे। तो मैं भी पसंद करने की सराहना करता हूं:

• यदि यह आमतौर पर इस्तेमाल किया जाने वाला निर्देश है तो इसे मॉड्यूल पर घोषित करें
• अगर यह TaskListItem जैसा कुछ है तो बस इसे TaskList में आयात करें।

हो सकता है कि कुछ कोर-सदस्य दूसरे दृष्टिकोण को पदावनत करने के निर्णय के बारे में अधिक बता सकें। इसके साथ कई महीनों तक काम करने के बाद, यह बहुत अच्छा लगता है;)

@choeller की बात को प्रतिध्वनित करने के लिए, घटक एनकैप्सुलेशन प्रदान करने की क्षमता से दूर जाना अजीब लगता है।

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

अब सभी चयनकर्ताओं को प्रति घटक अद्वितीय होने की आवश्यकता होगी, है ना? या क्या मैं गलत समझ रहा हूं कि यह कैसे काम करता है?

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

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

angular.module("myApp")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.component("…")
.component("…")
.component("…")
.component("…")
.component("…")
.component("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.service("…")
.service("…")
.service("…")
.service("…")
.service("…")
.service("…")

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

यह पुन: प्रयोज्य घटकों को और अधिक कठिन बना देता है। मुझे नहीं पता कि यह कैसे वैश्विक/मॉड्यूल दायरे में सबकुछ बेहतर बनाता है, मुझे लगता है कि एनजी 2 टीम ने एनजी 1 उपयोगकर्ताओं को चेतावनी दी है जो बदलाव नहीं चाहते हैं।

@DaSchTour @damiandennis मैं इस वास्तुकला की आलोचना को समझता हूं, हालांकि, इसे किसी प्रकार के वैश्विक दायरे के रूप में संदर्भित करना गलत है, वे जिस पद्धति का सुझाव दे रहे हैं वह फीचर मॉड्यूल है: https://angular.io/docs/ts /नवीनतम/गाइड/ngmodule.html#! #सुविधा-मॉड्यूल

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

जबकि RC4 तक एप्लिकेशन के प्रत्येक "पेज"/दृश्य के लिए एक घटक पर्याप्त था, मुझे पता है कि मुझे प्रत्येक दृश्य के लिए एक मॉड्यूल, एक घटक और रूटिंग बनाना होगा। मुझे इरादा मिलता है। लेकिन मुझे किसी तरह यह आभास होता है, कि यह कुछ चीजों को आसान बनाने के लिए डिज़ाइन किया गया है जबकि कई अन्य बिंदुओं से संबंधित नहीं है। और यहां तक ​​​​कि फीचर मॉड्यूल पैटर्न के साथ मुझे निर्भरता नरक से बचने के लिए उन्हें बहुत छोटा करना होगा, जो कुछ भी आवश्यक हो सकता है, क्योंकि मैं यह नहीं देख सकता कि मेरे आवेदन के किस हिस्से को किन घटकों की आवश्यकता है।

अंत में मॉड्यूल इतने छोटे होते हैं कि उनके पास वर्तमान घटकों की तरह समान दोहरावदार निर्भरता सूची होती है।

अंत में, यह हल नहीं करता है कि इसे किस लिए डिज़ाइन किया गया था और केवल बहुत सारे काम जोड़ता है। मुझे लगता है कि यहां डिजाइन और वास्तविकता के बीच कुछ बेमेल है।

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

@DaSchTour यदि प्रत्येक घटक को अपने स्वयं के दायरे की आवश्यकता है, तो हाँ यह अधिक बॉयलरप्लेट बनाएगा ... पर्याप्त है और कुछ घटक प्रत्येक फीचर स्पेस में रहने में सक्षम होंगे।

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

मुझे लगता है कि यह अधिक उत्पादक है यदि आलोचना एक स्ट्रॉ मैन डिज़ाइन पैटर्न के बजाय उनके वास्तविक डिज़ाइन सुझावों के आसपास आधारित है जो वे सुझाव नहीं दे रहे हैं (यानी एक एंटरप्राइज़ ऐप बनाना जो केवल एक बड़ा एनजी मॉड्यूल है)

@qdouble डिज़ाइन पैटर्न सरल है। यह निर्भरता को वैश्विक, मॉड्यूल स्कोप पर ले जाने के बजाय एक निर्भरता पेड़ का उपयोग करता है। मुझे लगता है कि मुख्य बिंदु यह है कि पुन: प्रयोज्य घटकों को अब मॉड्यूल होना चाहिए, भले ही वे बहुत छोटे हों और केवल बहुत कम कार्यक्षमता हो। कोणीय सामग्री 2 एक बहुत अच्छा उदाहरण है। एक बटन एक घटक सहित एक मॉड्यूल है। हो सकता है कि यह कई डेवलपर्स की एक सामान्य गलत धारणा है, कि एक मॉड्यूल कुछ ऐसा होता है जिसमें केवल एक बटन से अधिक होता है। और अब एक कदम आगे सोचते हैं। इस लेख के विचारों का पालन करते हुए https://angularjs.blogspot.com/2016/08/angular-2-rc5-ngmodules-lazy-loading.html मैं अपने आप को इस बिंदु पर पाता हूं, कि मेरे पास बहुत सारे मॉड्यूल हैं कोणीय सामग्री 2 मॉड्यूल की एक सूची आयात करें और इनमें से प्रत्येक मॉड्यूल में एक घटक शामिल है।
वास्तव में यह वही है जो कोणीय सामग्री 2 करता है।

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

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

@DaSchTour अच्छी तरह से हां, मैं मानता हूं कि यदि आपके द्वारा बनाए गए प्रत्येक घटक को अपने स्वयं के मॉड्यूल की आवश्यकता है, तो ngModules का उपयोग करके अधिक बॉयलरप्लेट बनाता है ... मैं बस यह मानता हूं कि टीम यह नहीं सोचती है कि अधिकांश लोगों को प्रत्येक के लिए अलगाव के उस स्तर की आवश्यकता होगी अवयव।

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

आप इसके लिए साझा मॉड्यूल का उपयोग करेंगे: https://angular.io/docs/ts/latest/guide/ngmodule.html#! #साझा-मॉड्यूल

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

मुझे लगता है कि घटक दायरे वाले निर्देशों/पाइपों को हटाने की आलोचना पूरी तरह से मान्य है। हालाँकि, मुझे नहीं लगता कि यह आवश्यक है कि ऐसा प्रतीत हो कि ngModules के लिए अच्छे डिज़ाइन पैटर्न नहीं हैं।

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

@choeller . का उदाहरण लेते हुए
मॉड्यूल टास्क डैशबोर्ड में निम्नलिखित चीजें हैं:

1. कार्यसूची घटक
2. टास्किटम घटक
3. टास्कफिल्टर घटक
4. कार्य सेवा

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

1. कार्यसूची घटक
2. कार्य खोज घटक
3. कार्य सेवा

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

ठीक है, मॉड्यूल गाइड के माध्यम से आगे पढ़ने के दौरान मुझे यह लाइन मिली

घटक, निर्देश और पाइप बिल्कुल एक मॉड्यूल से संबंधित होने चाहिए।

तो उदाहरण वास्तव में उस चिंता को दर्शाता है जो यहाँ उठाई गई है। कोई साझा घटक नहीं हो सकता है। तो मेरे उदाहरण से मुझे सब कुछ मॉड्यूल में विभाजित करना होगा।

ngModule का उपयोग करते समय आने वाली अजीब और मायावी त्रुटियों पर काम करते हुए मैंने यह भी पाया कि घटकों का विस्तार अब पहले की तरह अच्छा काम नहीं करता है। मेरे पास आवश्यक निर्भरताओं के साथ घटकों का एक सेट था जिसे मैं आसानी से बढ़ा सकता था। अब मुझे मॉड्यूल में निर्भरताओं को आयात करने का ख्याल रखना है जिसमें मैं अपना विस्तारित घटक शामिल करता हूं।

@DaSchTour उदाहरण में, टास्किटम टास्कलिस्ट मॉड्यूल का एक हिस्सा होना चाहिए ... ताकि तार्किक रूप से एक मॉड्यूल में दो घटक हों, प्रत्येक के लिए एक नहीं।

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

@qdouble @DaSchTour यह सच है कि नए आर्किटेक्चर का अर्थ यह नहीं है कि आप अपने सभी घटकों को एक फ़ाइल में सूचीबद्ध करते हैं, लेकिन हम जिस ऐप का निर्माण कर रहे हैं उसे देखते हुए मैं वर्तमान में @DaSchTour के इस कथन के साथ बहुत कुछ करूंगा

मुझे लगता है कि यहां डिजाइन और वास्तविकता के बीच कुछ बेमेल है।

इसलिए हमारे पास पृष्ठ पर छोटी इकाइयों का प्रतिनिधित्व करने वाले घटकों का एक समूह है जैसे TaskListItem जो एक विशेष दृश्य के लिए 100% बाध्य हैं। उन पृष्ठों में से प्रत्येक के लिए मॉड्यूल बनाना कुल ओवरकिल होगा। हमारे मामले में कई मॉड्यूल में विभाजित होने के बहुत कम कारण हैं लेकिन घटकों को एनकैप्सुलेट करने के लिए और अधिक कारण हैं।

टीएल; डॉ
मॉड्यूल स्तर पर कुछ निर्भरता को परिभाषित करने में सक्षम होना अच्छा है, लेकिन यह वास्तव में दुखद है, कि हम अब घटक स्तर पर निर्भरता को परिभाषित करने में सक्षम नहीं हैं

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

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

@choeller मैं मानता हूं कि मॉड्यूल होना एक अच्छा जोड़ है, घटक स्तर पर निर्भरता को दूर करना हालांकि गलत लगता है।

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

ऐसा करने से, मॉड्यूल उन्हें बड़ी परियोजनाओं पर चलाने के लिए काफी उपयोगी अवधारणा के रूप में सामने आना चाहिए।

यह बहुत अच्छी तरह से संक्षेप में @kylecordes है। NgModules एप्लिकेशन की अच्छी संरचना में मदद करता है। छोटे पुन: प्रयोज्य मॉड्यूल पूरे एप्लिकेशन को बनाते हैं।
अन्य लाभ में निर्देशों की परिवेश उपलब्धता शामिल है। पहले हम पूरे एप्लिकेशन में ROUTER_DIRECTIVES जोड़ते थे। अब RouterModule.forRoot() हमारे लिए यही करता है।
BrowserModule, CommonModule, FormsModule प्रत्येक घटक के माध्यम से निर्देशों को शामिल करने की तुलना में अधिक समझ में आता है।

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

इसके ऊपर LazyLoading है। यदि NgModules के लिए नहीं, तो कोई उन घटकों और सेवाओं की संख्या को कैसे परिभाषित कर सकता है जिन्हें एक नियमित इकाई बनाने के लिए एक साथ जाने की आवश्यकता है। आप ढीली फ़ाइलें डाउनलोड नहीं कर सकते क्योंकि इससे नेटवर्क अनुरोधों की संख्या बहुत अधिक हो जाएगी। इसके अलावा आपको एक बंडलर बनाने की जरूरत है जहां आप सभी आश्रित फाइलों को सूचीबद्ध करते हैं और एक बंडल बनाते हैं। NgModule सहज ज्ञान युक्त वाक्य रचना के साथ ऐसा करता है।

@kylecordes

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

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

@सिराजसी

इसके ऊपर LazyLoading है। यदि NgModules के लिए नहीं, तो कोई उन घटकों और सेवाओं की संख्या को कैसे परिभाषित कर सकता है जिन्हें एक नियमित इकाई बनाने के लिए एक साथ जाने की आवश्यकता है। आप ढीली फ़ाइलें डाउनलोड नहीं कर सकते क्योंकि इससे नेटवर्क अनुरोधों की संख्या बहुत अधिक हो जाएगी। अन्यथा आपको एक बंडलर बनाने की आवश्यकता है जहां आप सभी आश्रित फाइलों को सूचीबद्ध करते हैं और एक बंडल बनाते हैं। NgModule सहज ज्ञान युक्त वाक्य रचना के साथ ऐसा करता है।

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

यह वास्तव में ऐसा लगता है जैसे ngModule किसी समस्या की तलाश में एक समाधान है ...

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

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

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

"हार्ड सेल" का एक हिस्सा जो एनजी 2 टीम को एनजी 1 से समुदाय को बनाना था "हाँ, आपको प्रत्येक घटक के लिए अपने निर्देशों को आयात और घोषित करना होगा, लेकिन हम पर विश्वास करें, आप अधिक स्पष्ट होने की सराहना करेंगे जैसे-जैसे आपका आवेदन बढ़ता है"। मैं एक बड़े पैमाने पर टीम के माहौल में पठनीयता और स्कैनेबिलिटी के लिए कुछ दोहराव के माध्यम से पीड़ित होने में एक बड़ा विश्वास रखता हूं, जहां एक टीम का सदस्य किसी भी समय घटकों के बहुत छोटे उपसमुच्चय पर काम कर सकता है।

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

ngModules को अनिवार्य रूप से अधिकांश अनुप्रयोगों के पुनर्लेखन की आवश्यकता होती है यदि उन्हें ठीक से संरचित किया जाना है ... होना।

यदि आपको हर एक घटक के लिए एक नया मॉड्यूल बनाने की आवश्यकता है, तो इसका परिणाम अधिक बॉयलरप्लेट = मान्य होगा।

अधिकांश एप्लिकेशन के लिए आपको प्रत्येक घटक के लिए एक मॉड्यूल बनाने की आवश्यकता होगी = अमान्य (विशेषकर यदि आप स्मार्ट/गूंगा घटक पैटर्न और फीचर पैटर्न का उपयोग कर रहे हैं)

आज पहली बार, मुझे क्लाइंट साइड/जावास्क्रिप्ट थकान महसूस हुई, जो कई सहयोगियों ने मुझे बताई है। पिछले कुछ दिनों में मैंने अपने RC4 एप्लिकेशन को नए RC5 मॉड्यूल का उपयोग करने के लिए रिफैक्टर करने की कोशिश में अनगिनत घंटे गंवाए हैं।

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

अंत में, अगर मैं घटकों को निर्यात करने के लिए "भूल" जाता हूं, तो मेरा घटक बस प्रस्तुत नहीं करता है, कोई त्रुटि नहीं दी गई है। यह खोजना आसान है कि क्या आपके पास एक बहुत ही सपाट मॉड्यूल ग्राफ है, जब आपके पास कई स्तर हैं, तो असंभव के करीब!

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

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

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

मुझे यकीन है कि बहुत सी टीमों ने अपने नए ऐप्स के लिए आर्किटेक्चर पर घंटों बिताए हैं और अब यह सब पागल है।

अगला ब्रेकिंग परिवर्तन क्या होगा? मैं कल्पना भी नहीं कर सकता, लेकिन मुझे डर है कि कोई अगला ब्रेकिंग बदलाव लाने का कोई तरीका ढूंढ लेगा।

RC5 ब्लॉग पोस्ट से:

यदि आपने कोई कोणीय 2 कोड बिल्कुल भी लिखा है, तो आपने शायद खुद से पूछा है "लेकिन मुझे इन सभी चीजों को सूचीबद्ध करने की आवश्यकता क्यों है?" - खासकर यदि आपने देखा है कि एंगुलर 2 में कुछ निर्देश और पाइप "विशेष" हैं - वे आपके पूरे एप्लिकेशन के लिए आपके बिना कुछ भी किए उपलब्ध हैं (उदाहरण के लिए *ngFor / *ngIf / *ngSwitch)।

मैंने व्यक्तिगत रूप से किसी के द्वारा पूछे गए प्रश्न को काफी समय से नहीं देखा है। RC5 तक, एंगुलर टीम, ऑनलाइन शिक्षण संसाधन, किताबें, आदि सभी ने यह स्पष्ट कर दिया है कि उन घोषणाओं की आवश्यकता क्यों है - और ऐसा लगता है कि सभी ने इस तथ्य को बहुत पहले स्वीकार कर लिया (और कुछ ने स्वीकार कर लिया)।

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

यदि कोड पहले से ही एक ngModule में निर्देशों के उत्थापन को संभालने के लिए मौजूद है, और वह कोड एंड-यूज़र के लिए अदृश्य काम करता है, तो दोनों दृष्टिकोणों को अनुमति देने में क्या नुकसान है? यह एक वास्तविक प्रश्न है, क्योंकि मुझे कुछ पेचीदगियों के बारे में पता नहीं हो सकता है कि क्या हो सकता है यदि कोई डेवलपर दृष्टिकोण को मिलाता है और मेल खाता है। कोणीय 2 में कई अन्य "विभाजन विकल्प" हैं - मॉडल बनाम टेम्पलेट-संचालित रूप, 3 अलग-अलग भाषा विकल्प, इनपुट/आउटपुट/होस्ट डेकोरेटर बनाम संपत्ति दृष्टिकोण - इस बिंदु पर दूसरे में क्या नुकसान है?

मैं आगे बढ़ सकता था, लेकिन मैं जो बात कहने की कोशिश कर रहा हूं, वह यह है कि कोणीय टीम और समुदाय ने यह संदेश देने के लिए काफी समय लगाया है कि अधिक स्पष्ट होना एक _good_ बात है, केवल झपट्टा मारने के लिए -- _release पर हर समय के उम्मीदवार 5_ - हमें एक ऐसा समाधान प्रस्तुत करने के लिए जो काफी समय से कोई समस्या नहीं है।

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

इस चर्चा ने कई डेवलपर्स के लिए एक बहुत बड़ी समस्या खड़ी कर दी, जो अत्यधिक अपेक्षित कोणीय 2: ब्रेकिंग परिवर्तन के साथ जल्दी विकास करना शुरू करना चाहते थे। मैंने बीटा 17 के बाद से कोणीय 2 पर आधारित अवधारणा का एक गुच्छा किया और महत्वपूर्ण कंपनियों और संगठनों को इसे अपनाया। मुझे खेद नहीं है, लेकिन मुझे यकीन नहीं है कि मैंने भी अच्छा प्रदर्शन किया है। सबसे हालिया प्रोजेक्ट में से कुछ POC थे और लड़ाई Vue.js के खिलाफ थी। कोणीय 2 ने स्पष्ट रूप से उस लड़ाई को जीत लिया। लेकिन आज, सभी कोड पुनर्लेखन, ब्रेकिंग परिवर्तन, वास्तव में आरसी रिलीज के साथ, लोग मेरा पीछा करना शुरू कर देते हैं और यह बहुत गंभीर हो जाता है। यह मामला नहीं होता अगर मैं एक Vue या प्रतिक्रिया विकास की पेशकश करता हूं और यह बहुत निराशाजनक है क्योंकि बदनाम एंगुलर 2 लोगों को इसमें डाल सकता है।

मुझे ऐसा लगता है कि मैं एंगुलर टीम के रूप में रिलीज़ कैंडिडेट की समान परिभाषा साझा नहीं करता।

विषय के लिए, NgModule, मैं @jpsfs पर पूरी तरह से सह-हस्ताक्षर करता हूं , यदि आपको अपने मॉड्यूल घोषणा के भीतर अपने सभी घटकों और सूक्ष्म घटकों को सूचीबद्ध करना है, तो आपके पास कहीं न कहीं prune फ़ंक्शन है या होना चाहिए मॉडलिंग का राजा क्योंकि यह सभी शक्तिशाली हो सकता है, यह बड़े पैमाने पर परियोजनाओं के लिए बहुत संवेदनशील है ...

मुझे लगता है कि प्रतिरूपकता का यह अतिरिक्त उच्च स्तर लगभग अपरिहार्य था; और यह कि विभिन्न प्रतिस्पर्धी ढांचे अंततः कुछ समान के साथ समाप्त हो जाएंगे।

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

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

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

व्यक्तिगत रूप से मुझे लगता है कि यह परिवर्तन बिना अधिक लाभ के बॉयलरप्लेट का निम्न स्तर ला रहा है।

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

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

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

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

इससे भी बदतर, अगर मेरे पास एक ऐप है जो आरसी -2 या 3 से शुरू हुआ है (जो सैद्धांतिक रूप से लगभग स्थिर थे) मुझे अब एक अच्छा कोणीय 2 आरसी -5 ऐप बनाने के लिए बहुत काम करना है और किसी तरह ग्राहक को समझाने की जरूरत है और अन्य डेवलपर्स यह। और अगर मैं ऐसा करता भी हूं, तो भगवान जानता है कि आप आगे क्या बदलेंगे और मेरा काम व्यर्थ हो सकता है।

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

यह अच्छा नहीं है और कुछ आयात बदलते हैं या इंजेक्शन घटकों को गतिशील रूप से 5 रिलीज में 3 बार बदलता है लेकिन इसे मैं स्वीकार और समझ सकता हूं। ऐसे परिवर्तन लाना जो न केवल ऐप्स को तोड़ते हैं बल्कि जिस तरह से डेवलपर्स इस ढांचे में सोचते हैं, विकासशील चक्र में इतनी देर से मैं दुर्भाग्य से स्वीकार नहीं कर सकता।

वैसे भी, जैसा कि आप देख सकते हैं, बहुत से लोग मेरी बात से सहमत हैं और कुछ लोग इससे भी नाराज़ हैं। आपके पास एक बहुत बड़ा ढांचा है जिस पर लोग भरोसा करते हैं (क्योंकि ज्यादातर Google) लेकिन आप इस पर सब कुछ दांव पर नहीं लगा सकते हैं या आपको आश्चर्य हो सकता है क्योंकि सभी के पास विकल्प हैं (और जब जेएस के बारे में बात करते हैं, तो बहुत कुछ होता है)।

यदि नए मॉड्यूल में एक टेम्पलेट होगा तो यह घटक हो सकता है। इसके बारे में सोचो।

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

क्या इस सब के बारे में कोर टीम का कोई व्यक्ति कुछ कह सकता है? पिछली साप्ताहिक बैठक के नोट्स से, टीम बहिष्कृत एपीआई को हटाने के साथ आगे बढ़ रही है।

@महेवरी

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

• मुझे एक घटक के चयनकर्ता को कक्षा से तत्व में बदलना पड़ा, क्योंकि पूरी तरह से असंबंधित घटक में, उस वर्ग का उपयोग स्टाइल के लिए किया जाता है और अचानक घटक को तुरंत चालू करना शुरू कर दिया।
• मुझे पूरा यकीन है कि #10850 केवल मौजूद है, क्योंकि मेरे पास SpectrumComponent नामक दो घटक थे (एक चयनकर्ता के बिना नेविगेट करने के लिए एक संपूर्ण पृष्ठ और चयनकर्ता के साथ विज़ुअलाइज़ेशन के लिए एकाधिक घटकों में उपयोग किया जाने वाला एक "साझा" घटक)। होस्टिंग की संभावना इससे भ्रमित हो जाती है - directives: घोषणाएं नहीं।

मेरे एसवीजी घटकों के लिए, यह अब एक बड़ा मुद्दा बन गया है, क्योंकि मैं वहां एक कस्टम तत्व का उपयोग नहीं कर सकता। मुझे अभी तक पता नहीं है कि इनका दायरा कैसे सुनिश्चित किया जाए ताकि यह सुनिश्चित किया जा सके कि उनके वर्ग चयनकर्ता एप्लिकेशन में कहीं भी एक घटक तत्कालता (!) को ट्रिगर नहीं करते हैं।

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

ngModules समझ में आता है। घटक स्तर पर घोषित/प्रदान करने की क्षमता को हटाना नहीं है।

छोटा उदाहरण

मेरे पास एक ऐसा एप्लिकेशन है जिसमें कई अलग-अलग संवाद हैं (कुछ साधारण वाले - चलो उन्हें सरल -1 और सरल -2 कहते हैं, और एक जटिल जिसमें अन्य घटक होते हैं - आइए उस जटिल को कॉल करें 3)।

फिलहाल मेरे पास एक साधारण फ़ोल्डर संरचना है (जाहिर है कि ऐप इसमें से बाहर बैठता है)

- dialogs
   - simple-1 (containing single component and template for simple-1 dialog)
   - simple-2 (containing single component and template for simple-2 dialog)
   - complex-3 (contains the main complex-3 component plus a number of other internal components)
      - internal-component-1
      - internal-component-2
      - internal-service-3

मेरे लिए, यह एक अलग फीचर मॉड्यूल में डालने के लिए एक आदर्श फीचर है। तो मैं जोड़ता हूँ

   dialogs.module.ts
   - simple-1
   - simple-2
   - complex-3
      - internal-component-1
      - internal-component-2
      - internal-service-3

और मैं डायलॉग मॉड्यूल की घोषणा के रूप में Simple1Component, Simple2Component और Complex3Component जोड़ता हूं। बिल्कुल सही, अच्छा काम करता है और पूरी तरह से समझ में आता है।

लेकिन...

कॉम्प्लेक्स -3 में उन सभी आंतरिक घटकों के बारे में क्या। मेरे पास अब दो विकल्प हैं

• डायलॉग्समॉड्यूल में सभी बाहरी जटिल घटकों और सेवाओं को जोड़ें। यह एक खराब निर्णय है क्योंकि यह कॉम्प्लेक्स -3 के इनकैप्सुलेशन को तोड़ता है क्योंकि अब डायलॉग मॉड्यूल में सब कुछ इसके आंतरिक (आंतरिक-घटक -1, आंतरिक-घटक -2, आंतरिक-सेवा -3) के बारे में जानता है।
• कॉम्प्लेक्स-3 को अपने आप में एक मॉड्यूल बनाएं। यह स्कोपिंग समस्या को ठीक करता है (और मेरा मानना ​​है कि मैं किसी अन्य मॉड्यूल से मॉड्यूल निर्यात कर सकता हूं ताकि क्लाइंट को केवल रैपर मॉड्यूल आयात करने की आवश्यकता हो) लेकिन अब मुझे समान समूहों (संवाद) के लिए घटकों और मॉड्यूल के मिश्रण के साथ छोड़ देता है।

इनमें से कोई भी वास्तव में समझ में नहीं आता है, और जैसे-जैसे आवेदन बढ़ता है, दोनों के बीच संघर्ष केवल बढ़ता जाएगा।

मेरे लिए एकमात्र समझदार/स्पष्ट/रखरखाव योग्य समाधान शीर्ष स्तर के घटकों (सरल -1, सरल -2, जटिल -3) को निर्यात करने के लिए मॉड्यूल का उपयोग करना होगा, लेकिन जटिल -3 _component_ को स्वयं के आंतरिक घटकों को परिभाषित करने दें।

/ cc: @robwormald

मैं इस बारे में सोच रहा था कि @kylecordes ने नई ngModules चीज़ जोड़ने के बजाय कोड के कौरसर अनाज संग्रह को परिभाषित करने के लिए मौजूदा टाइपस्क्रिप्ट मॉड्यूल सिस्टम का उपयोग करने के बारे में क्या कहा था। मैं विचार के लिए एक उदाहरण प्रस्तुत करना चाहूंगा, जो 1-से-1 फैशन में ngModules को परिभाषित करने के लिए टाइपस्क्रिप्ट मॉड्यूल का उपयोग करता है। टिप्पणियों और विचारों का स्वागत है।

https://github.com/jbalbes/autoNgModule

10901

मुझे कुछ याद आ गया होगा, लेकिन जिस तरह से निर्भरता इंजेक्शन गैर आलसी लोड मॉड्यूल के साथ काम करता है वह "बड़ी परियोजनाओं" के लिए एक बड़ा मुद्दा बन सकता है (मेरा नहीं है और यह पहले से ही पीड़ित है)।

यह दिलचस्प है। हमारे पास पहले से ही Angular1 पर एक एंटरप्राइज़ एप्लिकेशन है। और हम विभिन्न मॉड्यूल के लिए पैकेज (ओं) को परिभाषित करने के लिए requjs का उपयोग कर रहे हैं (प्रत्येक मॉड्यूल में 10-20 निर्देश/सेवाएं/फ़िल्टर शामिल हैं)। हम इन पैकेजों को उत्पादन के लिए एकल फ़ाइल में बंडल करते हैं (मुख्य निर्देशों को छोड़कर)। निर्देशों का उपयोग किए जाने पर आवेदन में आलसी लोड किया जाता है (हमारे पास एक मूल निर्देश है कि आलसी आवश्यक निर्देशों को लोड करता है)।

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

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

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

हो सकता है कि ngModules विकास संरचना/पैटर्न को बेहतर बनाने के लिए प्रयास कर रहा हो (और हे, शायद यह सफल हो जाएगा), लेकिन अब तक मैंने जो थोड़ा देखा है और एपीआई पर चर्चा की है, उसके आधार पर, यह एक ऐसी दिशा में आगे बढ़ रहा है जो कि अधिक जटिल है पालन ​​करें और बनाए रखें।

साथ ही, क्या हमें वास्तव में किसी अन्य मॉड्यूल सिस्टम की आवश्यकता है?

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

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

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

@kylecordes नाम के बारे में जारी करता है https://github.com/angular/angular/issues/10087

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

@ बैरीरोवे इसे स्वयं बेहतर नहीं कह सकते थे - वास्तव में ऐसा लगता है कि अधिकांश ऐप्स इससे लाभ नहीं उठाएंगे - क्या यह केवल जटिलता को जोड़ा जा रहा है? मुझे आशा नहीं है।

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

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

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

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

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

मुझे ऐसा लगता है कि ढांचा अपने मूल उपकरणों का उनके पूर्ण प्रभाव में उपयोग नहीं कर रहा है। उदाहरण के लिए, टाइपस्क्रिप्ट घोषणाएं बिल्कुल मुहावरेदार नहीं हैं और any और any[] से अटी पड़ी हैं। वे शक्तिशाली भाषा सुविधाओं को भी अनदेखा करते हैं जो एपीआई की उपयोगिता और टूलेबिलिटी में सुधार करते हैं। उनमें export declare type Type = Function जैसी घृणित चीजें भी शामिल हैं।

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

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

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

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

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

. @jbalbes धन्यवाद, यह सुनकर अच्छा लगा।

@radusuciu आप बिल्कुल सही हैं, यह बॉयलरप्लेट में कमी नहीं है बल्कि उस बॉयलरप्लेट को एप्लिकेशन के दूसरे क्षेत्र में स्थानांतरित करना है। जैसा कि पहले ही दूसरों ने कहा है, यहां कोई भी घटक स्तर के दायरे और एनजीमॉड्यूल स्तर के दायरे के बीच संघर्ष नहीं है। हमें जो चाहिए वह बारीक स्कोपिंग है जिसे हम चुन सकते हैं कि कौन से घटक, निर्देश, पाइप और सेवाएं उनके एप्लिकेशन-विशिष्ट उपयोग और शब्दार्थ के आधार पर एप्लिकेशन के निचले आँसू के लिए उपलब्ध होनी चाहिए।

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

मुझे नहीं लगता कि ऐप डेवलपमेंट बनाम "अन्य वादा की गई सुविधाओं को काम करना" के सभी निहितार्थ एजेंडे में उतने ही उच्च थे, जब उन्हें जोड़ा गया था, लेकिन जैसे-जैसे अधिक से अधिक बड़े ऐप RC5 में परिवर्तित होते हैं, वे स्पष्ट होने लगे हैं।

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

Gang, NgModule एक जलन है जैसा कि कई लोगों ने वाक्पटुता से समझाया है। लेकिन व्यावहारिक रूप से यह इतनी बड़ी बात नहीं है। यहां पर (ओएसिस डिजिटल / एंगुलर बूट कैंप) हमने पहले से ही कई छोटी चीजों को अपडेट कर दिया है, और कुछ छोटी-छोटी चीजों को आरसी 5 में अपडेट कर दिया है, और यह कुछ ही समय में (अध्ययन और समझ के लंबे समय के बाद) किया गया था।

हर किसी के ऐप पर अलग-अलग असर पड़ने वाला है। इसके अलावा, मुझे लगता है कि एंगुलर 2 में मंथन और परिवर्तन के लिए आपका दृष्टिकोण संभवतः अलग होने जा रहा है यदि आप एक ऐप देने पर ध्यान केंद्रित कर रहे हैं बनाम यदि आप एंगुलर 2 के लिए प्रशिक्षण और समर्थन भी बेच रहे हैं। मेरे लिए, आरसी 5 में अपग्रेड करने के लिए सभी काम होंगे पूरी तरह से मृत और व्यर्थ प्रयास - यह वास्तव में नकारात्मक लाभ (बड़े बंडल) प्रदान करेगा, इसलिए इसे सही ठहराना मुश्किल है।

बस मैंने सोचा था कि मैं अपने विचारों को आरसी 6 * तक पहुंचने के लिए हमारे मंच पर पांच दिन के धक्का के फ्लिप-साइड से बाहर आऊंगा (हम नाइटली पर हैं, आरसी 6 तकनीकी रूप से अभी तक लेखन के समय तक नहीं गिरा है)। मुझे लगता है कि जबकि मेरी मूल टिप्पणियां अभी भी मान्य हैं, इस मुकाम तक पहुंचने के लिए राहत की भावना है। सबसे बड़े संघर्ष नए रूटिंग सिंटैक्स का उपयोग करना जारी रखते हैं - बहुत सारे खाली path: '' नियम! (मैं पछताता हूं) लेकिन यह कुछ ऐसा है जिसे हम शायद दूर कर देंगे।

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

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

@SaltyDH मुझे लगता है कि यह मूल्यवान प्रतिक्रिया है।
मुझे लगता है कि संचार के बारे में शिकायतें वास्तव में उचित नहीं हैं।

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

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

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

मैं पूरी तरह से सहमत हूं कि मास्टर बिल्ड (लगभग-आरसी 6) पर यह आसान है क्योंकि पिछले वर्ष + बहिष्करण अंततः दूर हो रहे हैं।

@kylecordes किस तरह से मास्टर के साथ काम करना आसान हो जाता है?

NgModules के लिए डिज़ाइन दस्तावेज़ (पहले AppModules के रूप में जाना जाता था जब डिज़ाइन दस्तावेज़ लिखा गया था) RC5 जारी होने से एक महीने पहले जारी किया गया था, और मैं इसके आने के लिए तैयार था।
इसके अलावा, चूंकि NgModule नई अवधारणा थी, इसलिए इसे पूरी तरह से हथियाना और अपने माध्यम को बड़े ऐप में स्थानांतरित करना कठिन था।
इसके बजाय मैंने जो किया वह है, पहले NgModules की बारीकियों को पूरी तरह से समझें और एक कोणीय 2 एप्लिकेशन को डिज़ाइन करने के लिए NgModules में कैसे सोचें । फिर NgModules के एप्लिकेशन के साथ एक सेल्फ लर्निंग ऐप बनाया।
दूसरा चरण है - इस बारे में सोचें कि मॉड्यूल में वर्तमान ऐप को कैसे तोड़ा जा सकता है और फिर उन्हें ऊपर से नीचे माइग्रेट किया जा सकता है। AppModule से शुरू करते हुए एक बार में एक मॉड्यूल बनाना। यह वास्तव में मदद करता है और अंतिम ऐप अधिक व्यवस्थित दिखता है।

और हाँ, RC5 जारी होने से पहले ही Gitter NgModule पर सहायता प्रदान करने में वास्तव में सहायक था। RC5 के बाद हमारे पास बेहतर सीखने के लिए डॉक्स और ब्लॉग उपलब्ध हैं।

@zoechi इस चर्चा को बहुत अधिक प्रभावित किए बिना मुझे लगता है कि मुझे अपनी टिप्पणियों को स्पष्ट करना चाहिए। मैं दस्तावेज़ीकरण का बिल्कुल भी जिक्र नहीं कर रहा था, मेरी अधिकांश समझ गिटहब में काम और मुद्दों की समीक्षा करने से आई है, मैं इसके साथ ठीक हूं। मेरी निराशा इस मुद्दे में प्रतिनिधित्व की कमी से आती है, हम 61 टिप्पणियों और गिनती पर हैं। एक सरल, "हम इस मुद्दे में यहां सभी की चिंताओं से अवगत हैं, हम वास्तव में मानते हैं कि यह एंगुलर 2 के लिए सबसे अच्छा तरीका है और हम इसके कारण होने वाली कठिनाइयों को पहचानते हैं लेकिन यह उत्पाद के भविष्य के लिए बेहतर है"। गटर बहुत अच्छा है लेकिन व्यक्तिगत संदेश अक्सर कोणीय 2 के विभिन्न पहलुओं को समझने की कोशिश कर रहे लोगों के समुद्र में खो जाते हैं। मैं इस माध्यम से पहुंच गया था लेकिन समय क्षेत्र के अंतर या अन्य प्राथमिकताओं के कारण, मैं आधिकारिक प्रतिक्रिया प्राप्त करने में सक्षम नहीं था I एक सूचित निर्णय लेने के लिए उपयोग कर सकते हैं। कोणीय पॉडकास्ट में इस एडवेंचर्स ने क्या मदद की https://devchat.tv/adv-in-angular/106-aia-angular2-rc5-and-beyond। इससे मुझे NgModule अपग्रेड के साथ आगे बढ़ने का विश्वास मिला।

शुभकामनाएं।

प्रतिक्रिया के लिए सभी को धन्यवाद, उत्तर पाने में इतना समय लगने के लिए खेद है - हम पिछले सप्ताह में बहुत व्यस्त रहे हैं (आंतरिक Google ऐप्स को NgModules पर माइग्रेट कर रहे हैं, इसलिए हमें रिफैक्टरिंग दर्द भी महसूस होता है)

मुझे देखने दो कि क्या मैं यहाँ कुछ प्रश्नों और भ्रांतियों को दूर कर सकता हूँ।

@NgModule() (और @Component और किसी अन्य अंगुकर डेकोरेटर) के बारे में समझने वाली पहली बात यह है कि वे विशुद्ध रूप से समय निर्माण को संकलित करते हैं - वे कोणीय संकलक को एक एप्लिकेशन में एक निर्भरता ग्राफ की खोज करने की अनुमति देने के लिए मौजूद हैं।

हमारे सज्जाकार जो करते हैं उसका एक (सरलीकृत) संस्करण इस तरह दिखता है:

//simplified Component decorator
export function Component(componentConfig){
  return function(componentClass){
    Reflect.defineMetadata('annotations', componentConfig, componentClass);
  }
}

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

जीआईटी मोड में, यह "जस्ट इन टाइम" होता है - बूटस्ट्रैप मॉड्यूल को कॉल करने और आपके पहले घटक प्रतिपादन के बीच, एंगुलर का कंपाइलर रिफ्लेक्ट एपीआई का उपयोग करके कक्षाओं से जुड़े मेटाडेटा को पुनः प्राप्त करता है:

let metadata = Reflect.getOwnMetadata('annotations', componentClass);

हालांकि, एओटी मोड में, यह थोड़ा अलग तरीके से काम करता है - निर्माण के समय, हम _statically_ (अर्थात, आपके कोड को निष्पादित किए बिना) डेकोरेटर के लिए स्कैन करके स्रोत कोड से समान मेटाडेटा निकालते हैं।

जब आप किसी एक घटक को बूटस्ट्रैप कर रहे होते हैं तो यह ठीक काम करता है, लेकिन हमने डेवलपर्स से बहुत सारी प्रतिक्रियाएँ सुनी हैं जो अधिक जटिल चीजें कर रहे हैं - कई रूट घटकों को बूटस्ट्रैप करना, या स्थिति की स्थिति के आधार पर विभिन्न घटकों को बूटस्ट्रैप करना आदि।

इसलिए जबकि @Component डेकोरेटर्स ने हमें एक कंपोनेंट का सांख्यिकीय रूप से विश्लेषण करने की क्षमता दी, हमारे पास एक _Application_ का मज़बूती से सांख्यिकीय रूप से विश्लेषण करने की क्षमता नहीं थी।

चीजें जो "एप्लिकेशन" की छतरी के नीचे आती हैं

• PLATFORM_DIRECTIVES/पाइप/प्रदाता
• चीजें जो आपने पहले बूटस्ट्रैप में जोड़ी थीं ()
• संकलक स्तर सेटिंग्स
• एकाधिक रूट घटक
• सर्वर साइड उपयोग।

NgModules सुविधाओं के एक सांख्यिकीय रूप से विश्लेषण योग्य सेट के विचार का परिचय देते हैं। मजे की बात यह है कि AoT कंपाइल मोड में, हम आपके रूट मॉड्यूल का विश्लेषण करते हैं, और एप्लिकेशन में प्रत्येक मॉड्यूल के लिए _generate_ एक मॉड्यूल फैक्ट्री - यह एक मॉड्यूल का पूर्व-संकलित संस्करण है, जिसमें _only_ वे फैक्ट्रियां शामिल हैं जिन्हें आप टेम्प्लेट में स्थिर रूप से संदर्भित करते हैं और जिन्हें आप "एंट्रीकंपोनेंट्स" के रूप में चिह्नित करें

क्योंकि हमने पहले से ही संकलन के लिए आवश्यक जानकारी पहले ही निकाल ली है, हम वास्तव में डेकोरेटर्स को ट्री-शेक कर सकते हैं (एनजीसी इसे फाइनल के लिए स्वचालित रूप से संभाल लेगा) - और अपने रूट मॉड्यूल से शुरू होने वाले अपने एप्लिकेशन को बंडल करने के बजाय, आप शुरू करते हैं आपके जेनरेट किए गए रूट मॉड्यूल_फैक्टरी_ पर, जिसमें केवल वह कोड होता है जो वास्तव में आपके एप्लिकेशन में उपयोग किया जाता है, इसलिए आप मॉड्यूलरिटी के लिए दंड का भुगतान नहीं करते हैं, और रोलअप और वेबपैक 2 जैसे टूल _more_ कुशलता से काम कर सकते हैं

अगले उत्तर में अनुसरण करने के लिए और अधिक ...

@robwormald मैं इस तरह की पृष्ठभूमि की जानकारी के लिए प्रशंसा की राशि इमोजी में नहीं डाल सकता।

आपको धन्यवाद!

एक और समस्या जिसे हमने NgModules में हल किया:

ऐसे मामले पर विचार करें जहां आप डायलॉग सेवा या इसी तरह का निर्माण करना चाहते हैं।

ऐतिहासिक रूप से, आप कुछ ऐसा करेंगे:

@Injectable()
export class MyDialogService {
  //inject the dynamic compiler 
  constructor(private componentResolver:ComponentResolver){}

  //accept a component and a viewContainerRef
  showDialog(component:Type, target:ViewContainerRef){
    //compile the component into a factory, async
    return this.componentResolver.resolveComponent(component)
      .then(componentFactory => {
         //dynamically insert the compiled componentFactory into the view:
        return target.createComponent(componentFactory);
      })
  }
}

...जिसका आप उपयोग करेंगे जैसे

myDialogService.showDialog(MyRandomDialogComponent).then(...)

यहां ध्यान देने योग्य बातें-

• बाहरी टेम्पलेट यूआरएल और स्टाइल यूआरएल के कारण जीआईटी मोड में घटक संकलन _मस्ट_ एसिंक्रोनस होना चाहिए
• एक व्यूकंटेनर एक _componentFactory_ स्वीकार करता है - तो अब आपके कोड में एक समस्या है: आपको या तो मोड स्विच करने के लिए कोड को फिर से लिखना होगा (JIT और AoT के बीच), _or_ आपको हमेशा यह मानना ​​​​होगा कि घटक प्रविष्टि एपीआई एसिंक्रोनस है। संवाद के मामले में यह ठीक हो सकता है, लेकिन यदि आप गतिशील रूप से जटिल UI का निर्माण कर रहे हैं (डैशबोर्ड या ग्रिड व्यू या जो कुछ भी सोचें), तो आप बड़ी मात्रा में अनावश्यक वादा शेड्यूलिंग करते हैं।
• तृतीय पक्ष या साझा सेवाओं/घटकों (जैसे SharedDialogService) में एक ही समस्या है, _या तो_ घटकों या घटक कारखानों को स्वीकार करना

यह समस्या _any_ एप्लिकेशन के लिए उत्पन्न होती है जो गतिशील घटक प्रविष्टि कर रहा है (जिसका मतलब आलसी लोडिंग नहीं है) - संवाद, राउटर, आदि, सभी चयनकर्ताओं (फू-बार) के बजाय घटक प्रकार (कक्षाओं) के साथ बातचीत करने की उम्मीद करते हैं।

इसलिए, जब आप एक NgModule डेकोरेटर में अपने entryComponents सरणी में एक घटक जोड़ते हैं:

@NgModule({
  declarations: [ MyRandomDialogComponent ],
  entryComponents: [ MyRandomDialogComponent ]  
})
export class MyApp {}

यह संकलक को बताता है कि "मुझे MyRandomDialogComponent और इसके संकलित MyRandomDialogComponentNgFactory के बीच एक मैपिंग उत्पन्न करें", और इसे NgModuleFactory में _store करें जिसमें इसे घोषित किया गया है_

इस प्रकार, उपरोक्त संवाद सेवा का एक NgModule संचालित संस्करण इस तरह दिखता है:

@Injectable()
export class MyDialogService {
  //inject the component factory resolver 
  constructor(private componentFactoryResolver:ComponentFactoryResolver){}

  //accept a component and a viewContainerRef
  showDialog(component:Type, target:ViewContainerRef){
    //*retrieve* the componentFactory by component, sync
   let componentFactory = this.componentFactoryResolver.resolveComponentFactory(component)
   //add the componentFactory to the view, sync
   return target.createComponent(componentFactory);
  }
}

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

स्पष्टीकरण के लिए धन्यवाद @robwormald

एक प्रश्न यह है: क्या इसके लिए निर्देश/पाइप घोषणाओं को हटाने की आवश्यकता है? क्या कोई कारण है कि वे NgModule के साथ सह-अस्तित्व में नहीं रह सकते हैं?

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

मैं यह भी देखता हूं कि निर्देश/पाइप घोषणाओं को हटाने के लिए पुल अनुरोध ऊपर है (https://github.com/angular/angular/pull/10912) - मुझे उम्मीद है कि कुछ भी सेट होने से पहले हमें इस बिंदु पर प्रतिक्रिया मिल सकती है पत्थर।

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

"वैश्विक दायरे" के संबंध में यहां कुछ टिप्पणियां हैं - यह संकलक और मॉड्यूल के यांत्रिकी को गलत समझता है (जो पूरी तरह से समझ में आता है, यह जटिल सामान है)।

अपने पूरे एप्लिकेशन को एक NgModule में डंप करना "ठीक" है जिस तरह से $rootScope पर आपके पूरे एप्लिकेशन की स्थिति को डंप करना Angular1 में "ठीक" था (पढ़ें: यह काम करता है, लेकिन इसका खराब एप्लिकेशन डिज़ाइन)

कोणीय 1 में, एक मॉड्यूल को एक एप्लिकेशन में लाना कमोबेश आपके पूरे एप्लिकेशन को "प्रदूषित" कर देता है, क्योंकि सब कुछ एक इंजेक्टर बैग में डंप कर दिया गया था।

Angular2 में, NgModus में कुछ बहुत शक्तिशाली स्कोपिंग तंत्र हैं जो प्रदूषण के बिना रचना की अनुमति देते हैं। फिर से, यह वापस संकलक के पास जाता है।

जब कोणीय आपके एप्लिकेशन को ट्रैवर्स कर रहा है और संकलित कर रहा है, तो इसका सामना करने वाले प्रत्येक घटक को उस संदर्भ में संकलित किया जाता है जिसमें इसे घोषित किया गया था_

उदाहरण के लिए - कल्पना करें कि आपके पास एक साझा मॉड्यूल है जिसमें कुछ कार्यक्षमता है जिसे आप किसी एप्लिकेशन में साझा करना चाहते हैं

@Component({
  selector: 'shared-component-one',
  template: `
    <div>Shared Component One</div>
    <shared-component-two>
  `
})
export class SharedComponentOne {}

@Component({
  selector: 'shared-component-two',
  template: `
    <div>Shared Component Two</div>
  `
})
export class SharedComponentTwo {}

@NgModule({
  declarations: [ SharedComponentOne, SharedComponentTwo ],
  exports: [ SharedComponentOne ]
})
export class SharedModule {}

SharedComponentOne और SharedComponentTwo दोनों SharedModule में _declared_ हैं - घोषणाओं का अर्थ _ownership_ है - इसलिए ये दोनों घटक SharedModule के स्वामित्व में हैं। हालांकि, _only_ SharedComponentOne मॉड्यूल से _exported_ है - SharedComponentTwo SharedModule पर _private_ रहता है।

यदि आप SharedModule में लाना चाहते थे और इसे किसी अन्य मॉड्यूल में उपयोग करना चाहते थे, जैसे:

@Component({
  selector: 'some-component',
  template: `
    <div>hello from some component</div>
    <shared-component-one></shared-component-one>
  `
})
export class SomeComponent {}

@NgModule({
  imports: [ SharedModule ],
  declarations: [ SomeComponent ]
})
export class SomeModule {}

...जब कंपाइलर SomeComponent को संकलित करना शुरू करता है, तो यह shared-component-one चयनकर्ता का पता लगाता है, और क्योंकि SharedModule (जो SharedComponentOne निर्यात करता है) को SomeModule में आयात किया जाता है।

दिलचस्प बात यह है कि जब कंपाइलर वास्तव में SharedComponentOne को संकलित करता है, तो वह ऐसा "अंदर" SharedModule करता है, जो इसे SharedModule के भीतर उन चीजों का उपयोग करने की अनुमति देता है जो बाहरी दुनिया के संपर्क में नहीं हैं।

यह बहुत हद तक उसी तरह है जैसे यह Component.directives के साथ काम करता था, और इस मामले में वे बराबर हैं।

विचार करें कि क्या आपके पास Tabs सुविधा जैसी कोई चीज़ है:

@Component({
  selector: 'my-tabs',
  template: '...'
})
export class TabsComponent {}

@Component({
  selector: 'my-tab',
  template: '...'
})
export class TabComponent {}

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

export const TAB_DIRECTIVES = [ TabsComponent, TabComponent ]

एक अधिक जटिल टैब सुविधा में एक ऐसी सेवा हो सकती है जो टैब के कई उदाहरणों को प्रबंधित करती है, इसलिए आपको उस मामले को भी संभालना होगा ...

export const TAB_PROVIDERS = [ ... ]

और इसका उपयोग करना उन सभी चीजों को याद रखने का अभ्यास बन जाता है जिन्हें आपको निर्यात और आयात करना है...

import {TAB_DIRECTIVES, TAB_PROVIDERS}

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

एक NgModule के साथ, आप उन्हें केवल एक इकाई में पैकेज कर सकते हैं, और इसे अपने एप्लिकेशन के चारों ओर पास कर सकते हैं, और जहां प्रासंगिक हो वहां इसे आयात कर सकते हैं।

मटीरियल डिज़ाइन जैसे पुस्तकालयों के लिए, जिसमें कई मॉड्यूल में फैली कई सुविधाएँ हो सकती हैं, आप इसे और भी पोर्टेबल बनाने के लिए समान आयात / निर्यात शब्दार्थ का लाभ उठा सकते हैं:

@NgModule({
  exports: [ TabsModule, NavbarModule ]
})
export class MaterialSharedModule {}

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

हमने Component.directives / पाइप्स को क्यों हटाया, हमने दोनों दिशाओं में बहुत सारी प्रतिक्रियाएँ सुनी हैं। हमें ऐसा लगता है कि एक ही चीज़ को पूरा करने के दो तरीके होना आम तौर पर एक खराब पैटर्न है, इसलिए हमने लोगों को आम तौर पर कम कोड लिखने में सक्षम बनाने के लिए चुनाव किया, और जो लोग पहले Component.directives द्वारा दी गई स्पष्ट स्कोपिंग चाहते हैं, वे _same_ कार्यक्षमता को पूरा कर सकते हैं। मॉड्यूल स्तर पर स्कोपिंग।

RC5 में, हमने Component.directives को "वैश्विक" दायरे में एक तरह से स्वचालित रूप से उत्थापन किया। यह संक्रमण को सुचारू करने का एक प्रयास था, और जब इसने अधिकांश लोगों के लिए काम किया, तो मिश्रित पुराने और नए व्यवहार ने कुछ अजीब त्रुटियों और व्यवहार का कारण बना, जबकि निराशा होती है, अस्थायी होती है। यह RC6 में चला जाता है (और त्रुटि संदेशों में सुधार किया गया है)

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

सभी के धैर्य के लिए धन्यवाद। मैं इसे खुला छोड़ दूंगा यदि अन्य प्रश्न हैं जिन्हें मैंने यहां शामिल नहीं किया है।

लूटना

अच्छा काम, @robwormald

मैं कुछ और अवलोकन जोड़ना चाहता हूं:

प्रदाताओं

रोब ने _declarations_, _imports_, और _exports_ पर ध्यान केंद्रित किया। मॉड्यूल _प्रदाता_ अलग हैं।

@Component.providers रहता है! केवल @Component.directives और @Component.pipes जा रहे हैं।

आप @NgModules.providers और @Component.providers दोनों का उपयोग कर सकते हैं। उनके अलग-अलग उद्देश्य हैं:

a) @NgModules.providers _extends_ "मुख्य" इंजेक्टर (उत्सुकता से लोड किए गए मॉड्यूल के लिए ऐप रूट इंजेक्टर) में प्रदाताओं को जोड़कर एप्लिकेशन। इस प्रकार RouterModule आपके ऐप को प्रदान किए बिना रूटिंग सेवा जोड़ता है।

बी) @Component.providers _encapsulates_ घटक उदाहरण (और इसके घटक उप-पेड़) के दायरे में सेवा प्रावधान।

दोनों दृष्टिकोण अलग-अलग जरूरतों को पूरा करते हैं।

मेरी सामान्य सलाह: _यदि आपके पास आज @Component पर प्रदाता है, तो उसे वहीं छोड़ दें_

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

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

मैं अपने ऐप में प्राकृतिक सीम की तलाश करता हूं। मैं पागल नहीं जाता। मैं हर घटक को मॉड्यूलर नहीं करता।

मटीरियल डिज़ाइन ऐसा करने का कारण यह है कि वे हमारे लिए जो हम चाहते हैं उसका उपयोग करना आसान बनाने की कोशिश कर रहे हैं।

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

यह एक ऐसा पैटर्न है जिसका पालन कोई भी पुस्तकालय विक्रेता कर सकता है और उद्यम में समझ में आ सकता है जहां हम अपनी कंपनी द्वारा अनुमोदित गैजेट्री की "किट" को एक साथ रखते हैं।

डिक्लेरेशन डिपेंडेंसीज का पता लगाना

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

प्री-आरसी5 से माइग्रेट करना नुकसान की भावना को बढ़ावा देता है। हमें अपनी पिछली directives और pipes सूचियों में निर्भरता खोजने का कठिन काम करना होगा। और हमें डी-डुप्लिकेट करना होगा। यह किनारे पर रहने की अनिवार्य अप्रियता है।

एक आरसी को इतना नहीं बदलना चाहिए

हां। उस पर आपको टीम की ओर से कोई तर्क नहीं मिलेगा। यह जानबूझकर नहीं था। अगर हमें पता होता कि हमें NgModule की जरूरत है तो हम इसे बीटा में प्राप्त कर लेते।

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

मैंने अब कई ऐप्स को रूपांतरित किया है और ऐसा करने में दूसरों की मदद की है। एक बार "_ वे मेरे पनीर (फिर से) _" चरण में चले गए, यह एक बहुत ही यांत्रिक प्रवास है और हर किसी को लगता है कि वे एक बेहतर जगह पर हैं। शायद वे मेरे साथ अच्छे व्यवहार कर रहे हैं। ओटीओएच, मैं ऐसे लोगों के साथ नहीं रहता जो इतने अच्छे हैं ;-)

(also, पुन: नाम)
हमने मौत के घाट उतार दिए। उन्हें शुरू में AppModules कहा जाता था (चूंकि वे एक घटक की तुलना में कुछ उच्च स्तर का वर्णन करते हैं, एक "ऐप") लेकिन यह एक व्यापक पर्याप्त शब्द नहीं था। पैकेज, बंडल, बैरल, ग्लब्स, आदि।

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

इसलिए नामकरण कठिन है। एनजीमॉड्यूल यह है।

हम 2.0.0 के लिए एपीआई पूर्ण हैं, और इसलिए हम रिलीज के बाद अगले कुछ महीनों में देखेंगे कि कौन से पैटर्न विकसित होते हैं, और हम चीनी कहां कर सकते हैं और 2.1 के लिए बेहतर अनुमान लगा सकते हैं।

बहुत ही व्यावहारिक टिप्पणियों के लिए @robwormald @wardbell का तहे दिल से धन्यवाद। मुझे लगता है कि मेरे लिए सबसे बड़ी राहत है

"हम 2.0.0 के लिए एपीआई पूर्ण हैं, और इसलिए हम रिलीज के बाद अगले कुछ महीनों में देखेंगे कि कौन से पैटर्न विकसित होते हैं, और हम चीनी कहां कर सकते हैं और 2.1 के लिए बेहतर निष्कर्ष निकाल सकते हैं।"

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

मुझे ईमानदारी से विश्वास है कि आप कह सकते हैं कि @SaltyDH। कोणीय 2 मंथन समाप्त हो गया है।

इसका मतलब यह नहीं है कि कोणीय 2 विकसित हो रहा है। भविष्य में रिलीज़ होंगी। लेकिन 2.0... की ओर ले जाने वाला मंथन... खत्म हो गया है!

ईमानदारी और स्पष्ट उपयोग के मामलों के लिए बहुत बहुत धन्यवाद, दोस्तों। यह वास्तव में मदद करता है।

NgModule के लिए एपीआई में नामकरण और दोहराव पर बस एक त्वरित विचार, जो मुझे लगता है कि थोड़ा बोझिल है।

आईएमओ यह:

@NgModule({
  declarations: [ SharedComponentOne, SharedComponentTwo ],
  exports: [ SharedComponentOne ]
})
export class SharedModule {}

... स्पष्ट और अधिक संक्षिप्त हो सकता है:

@NgModule({
  private: [ SharedComponentTwo ],
  public: [ SharedComponentOne ]
})
export class SharedModule {}

1) नामकरण के लिए डब्लूआरटी (सार्वजनिक और निजी बनाम घोषणाएं और निर्यात), यह अनिवार्य रूप से ऊपर @robwormald है और मुझे यकीन है कि कई अन्य इसे समझा रहे हैं

2) (नामकरण की उपेक्षा) SharedComponentOne को दोहराने की आवश्यकता क्यों होगी? निश्चित रूप से आप कह सकते हैं कि यदि यह "निर्यात" है तो यह "घोषणा" होना चाहिए, तो इसे इस तरह से हटा दिया जा सकता है?

अत्यधिक व्यक्तिपरक कुछ पर बस मेरे दो सेंट 😄 - विस्तृत स्पष्टीकरण के लिए फिर से धन्यवाद!

@robwormald @wardbell विस्तृत स्पष्टीकरण के लिए धन्यवाद।

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

@JamesHenry declarations , imports और exports का उपयोग NgModules को ES6 मॉड्यूल के अनुरूप रखने के लिए किया जाता है जैसे कि हम import , export और declare ES6 मॉड्यूल में सामान।
मैं शुगरिंग से सहमत हूं, जो चीजें निर्यात की जाती हैं, उन्हें स्वचालित रूप से घोषणाओं में डी-शुगर किया जा सकता है।

@ जेम्स हेनरी

1), हम आयात/निर्यात के साथ फंस गए क्योंकि मानसिक मॉडल ईएस मॉड्यूल कैसे काम करता है (कम से कम स्कोपिंग के मामले में) के करीब है - आप मॉड्यूल में चीजों की घोषणा करते हैं, अन्य मॉड्यूल से चीजों को आयात करते हैं, और उन्हें उपलब्ध कराने के लिए चीजों को निर्यात करते हैं अन्य।

2) if it is an "export" it must be a declaration, so it could just be desugared that way? -> यह तब तक काम करता है जब तक आप फिर से निर्यात करने के लिए एक ngModule का उपयोग नहीं करते हैं, जैसा कि ऊपर दिए गए MaterialModule उदाहरण में है - ऐसे बहुत से मामले हैं जहाँ आप किसी अन्य मॉड्यूल में घोषित किसी चीज़ को फिर से निर्यात करने के लिए ngModule का उपयोग कर सकते हैं, और तब अनुमान अलग हो जाते हैं।

@robwormald बढ़िया टिप्पणियाँ! निश्चित रूप से एक ब्लॉग पोस्ट के लायक।

मेरे पास एक संवाद पुस्तकालय है जो अब @NgModule का उपयोग करता है और मैं कह सकता हूं कि मैं कस्टम घटकों को जोड़ने का प्रयास करते समय उपयोगकर्ताओं को संघर्ष करते हुए देखता हूं क्योंकि वे उन्हें entryComponents में पंजीकृत करना भूल जाते हैं, यह स्पष्ट रूप से पर्याप्त स्पष्ट नहीं है लेकिन समझ में आता है क्योंकि यह एक उन्नत विशेषता है ...

मुझे यकीन है कि यह समय के साथ डूब जाएगा

@shlomiassaf धन्यवाद!

आपके जैसे मामलों के लिए भी उल्लेख करना चाहिए:

ध्यान दें कि जब आप कोणीय के राउटर का उपयोग करते हैं, तो आप घोषणाओं और रूट कॉन्फ़िगरेशन में घटकों को जोड़ते हैं, लेकिन _not_ को entryComponents, इस तथ्य के बावजूद कि राउटर entryComponents की बहुत परिभाषा है। (याद रखें - entryComponent === वह चीज जिसे आप चयनकर्ता के बजाय कक्षा द्वारा संदर्भित करना चाहते हैं)

एक अच्छी चाल है जिसका कोई भी पुस्तकालय लाभ उठा सकता है - ANALYZE_FOR_ENTRY_COMPONENTS नामक एक जादुई टोकन है - देखें https://github.com/angular/angular/blob/master/modules/%40angular/router/src/ राउटर_मॉड्यूल.ts#L117 राउटर इसका उपयोग कैसे करता है।

तो गतिशील रूप से सम्मिलित घटकों से निपटने वाले libs के लिए, आप कुछ ऐसा कर सकते हैं:

@NgModule({
  providers: [ DialogService ]
})
export class DialogModule {
  static withComponents(componentList): NgModuleWithProviders {
    return {
      ngModule: DialogModule,
      providers : [
         { provide: ANALYZE_FOR_ENTRY_COMPONENTS, useValue: componentList, multi: true }
      ]
     }
  }
}

की तरह इस्तेमाल किया

@NgModule({
  declarations: [ MyConfirmDialog, MyQuestionDialog ],
  imports: [
    DialogModule.withComponents([ MyConfirmDialog, MyQuestionDialog ])
  ]
})
export class MyAppModule {}

आपके उपयोग के मामले में काम कर सकता है, शायद नहीं।

@JamesHenry बहुत महत्वपूर्ण है कि declarations private के साथ भ्रमित नहीं है। आप कह रहे हैं _यह मॉड्यूल इस घटक को घोषित करता है_। आप सार्वजनिक या निजी के बारे में कोई बयान नहीं दे रहे हैं। आप स्वामित्व का दावा कर रहे हैं।

यह वास्तव में वैसा ही है जैसा ES6 मॉड्यूल में होता है। फ़ाइल के अंदर जो कुछ भी आप परिभाषित करते हैं वह उस फ़ाइल द्वारा परिभाषित मॉड्यूल से "संबंधित" है। यह सार्वजनिक है या नहीं यह आपके द्वारा कीवर्ड export के उपयोग पर निर्भर करता है।

और जैसा कि ES6 मॉड्यूल के साथ आप आयात किए गए सामान को फिर से निर्यात कर सकते हैं।

मैं declarations को "चाल" के रूप में सोचना पसंद करता हूं जो मुझे भौतिक रूप से मेरे सभी घटकों, निर्देशों और पाइपों को एक ही भौतिक फ़ाइल में रखने से रोकता है (जैसा कि आपको ES6 मॉड्यूल के साथ करना होगा यदि आप चाहते हैं वे सभी वर्ग समान ES6 मॉड्यूल से संबंधित हैं)।

तो, मेरे लिए, declarations उन फ़ाइलों को एक भयानक बड़ी फ़ाइल में चिपकाने का एक विकल्प है। वैसे भी वह _my_ मानसिक मॉडल है।

ध्यान देने वाली एक बात एक मॉड्यूल के संदर्भ में प्रदाताओं और घटकों के बीच तार्किक अंतर है।

प्रदाता और घटक एक ही स्थान ( NgModuleMetadataType ) में घोषित किए जाते हैं, इसलिए एक डेवलपर सहज रूप से महसूस कर सकता है कि प्रदाता घटकों की तरह व्यवहार करते हैं ... .

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

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

@wardbell धन्यवाद वार्ड जो वास्तव में बहुत अच्छा है! बस यह स्पष्ट करने के लिए कि यह अभी चर्चा में आया है, जब हम कहते हैं कि एंगुलर 2 एपीआई पूर्ण है, तो हम यहां किन नामस्थानों के बारे में बात कर रहे हैं? @कोणीय/???

@robwormald धन्यवाद! एक बढ़िया टिप !!!
एक चीनी के स्वाद वाला! लागू करेगा।

मैं Google कर्मचारी नहीं हूं और शायद Google कर्मचारी नहीं कह सकता। मैं केवल वही रिपोर्ट कर सकता हूं जो मैं अपनी दो आंखों से देख रहा हूं: पुस्तकालयों के @angular/ सेट में एक बहुत ही गंभीर एपीआई फ्रीज।

ऐसे अच्छे विचार हैं जो शेल्फ पर बैठे हैं क्योंकि वे इतने अच्छे या इतने गहरे नहीं थे कि रिलीज को रोके रखने का औचित्य साबित कर सकें। इसे ऐसा होना चाहिए। अच्छे विचार कभी खत्म नहीं होते। लेकिन यह कहने का समय आ गया है _यह आपका कोणीय 2.0_ है।

हमारे पास अब और "अंतिम" के बीच आने वाले पदावनत एपीआई को हटाने का वादा किया गया है। इसमें ट्वीक हैं ... जैसा कि कोई भी मास्टर को देखकर देख सकता है। मुझे ऐसा लग रहा है कि हम कर चुके हैं।

@wardbell निर्यात के बारे में आप जो कहते हैं, मैं उसकी प्रतिध्वनि करता हूं।
index.ts एक बार भरा हुआ था

export * from 'a.component'
export * from 'b.component'
export * from 'c.component'
export * from 'p.directive'
export * from 'x.service'
export * from 'z.pipe'

अब घटाकर केवल export * from my.module . कर दिया गया है
बाकी सभी सामान साफ ​​NgModule निर्यात के रूप में बैठता है
exports: [ AComponent, BComponent, CComponent, PDirective ]

@wardbell मुझे लगता है कि @NgModules.providers होना चाहिए था @NgModules.rootProviders या @NgModules.appProviders ।

मुझे लगता है कि यह प्रदाताओं के संदर्भ का स्पष्ट रूप से वर्णन करता है।

@shlomiassaf यह भ्रामक होगा। उत्सुक और आलसी मॉड्यूल के लिए @NgModules.providers का प्रभाव अलग है। आलसी लोड किए गए मॉड्यूल को अपना स्वयं का बच्चा इंजेक्टर मिलता है जिसका अर्थ है कि _उनके प्रदाता_ _child_ इंजेक्टर में जोड़े जाते हैं, _root_ इंजेक्टर नहीं। और ऐसा ही होता है अगर एक आलसी ने एक आलसी को लोड किया।

शायद कोई और नाम हो सकता था। तुम्हें पता है वह कैसे चलता है। लेकिन rootProviders मेरे द्वारा दिए गए कारणों से कोई सुधार नहीं होता।

@ वार्डबेल सहमत हुए, उस परिदृश्य के बारे में नहीं सोचा।

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

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

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

तो, मेरे लिए, घोषणाएं उन फ़ाइलों को एक भयानक बड़ी फ़ाइल में चिपकाने का एक विकल्प है। वैसे भी यह मेरा मानसिक मॉडल है।

@wardbell शायद मुझे कुछ मौलिक याद आ रही है, लेकिन मुझे नहीं लगता कि NgModule.declarations का उपयोग करना सभी को आयात करने से मौलिक रूप से अलग है, लेकिन केवल आपके ESModules में से कुछ को फिर से निर्यात करना है। विडंबना यह है कि ESModules की प्राथमिक सीमा यह है कि वे केवल भौतिक मॉड्यूल की अवधारणा प्रदान करते हैं, तार्किक नहीं। मैं नहीं देखता कि कैसे NgModule इसमें सुधार करता है। यह सिर्फ एक अलग एकत्रीकरण वाक्यविन्यास है लेकिन अमूर्तता के स्तर को सार्थक डिग्री तक नहीं बढ़ाता है।

इसके अलावा, NgModules एक बड़ी समस्या का समाधान करने में पूरी तरह विफल:

संपूर्ण Function[] पैटर्न सभी गलत तरीकों से अपारदर्शी है। यह खोज योग्यता को शून्य कर देता है। प्रदाताओं की एक सरणी में क्या है, यह निर्धारित करने के लिए स्रोत को पढ़ना होगा। NgModule.exports के बारे में भी यही सच है।

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

@wardbell मेरे लिए आरसी के बारे में सबसे बड़ी निराशा यह धारणा है कि एनजी-कॉन्फ और Google i/o के कारण बीटा को आरसी पर धक्का दिया गया है। प्रगति करने के लिए, कारण स्पष्ट रूप से रखा जाना चाहिए: यह _विपणन_ रहा है और प्रौद्योगिकीविदों के रूप में हमें परिपक्वता की इन लचीली धारणाओं की प्रवृत्ति से लड़ना चाहिए। आप घाटी में एक लोकप्रिय कार निर्माता को जानते होंगे जहां चर्चा मौसम के बारे में है कि उत्पाद के लिए बीटा बेचने का अधिकार है क्योंकि इसमें जीवन लग सकता है। मैं अतिशयोक्ति नहीं करना चाहता, लेकिन प्रौद्योगिकीविदों के रूप में हमें बोलना चाहिए कि क्या हमारा उद्योग इस तरह से चल रहा है क्योंकि तब यह गलत दिशा में जा रहा है।

मुझे ngmodule दृष्टिकोण पसंद है लेकिन मेरा एक प्रश्न है @robwormald :

मेरे पास एक साझा सेवा है जिसमें कोई घटक नहीं है, कोई निर्देश नहीं है और कोई पाइप नहीं है। इसमें केवल सेवाएं ( forRoot ) हैं और इसमें सभी व्यवसाय मॉडल वर्ग शामिल हैं। app.module आयात ServerApiModule.forRoot() इसलिए सेवाएं पूरे एप्लिकेशन के लिए उपलब्ध हैं। क्या फीचर मॉड्यूल, जो सेवाओं और व्यापार मॉडल वर्गों का उपयोग करता है, इस साझा मॉड्यूल को आयात करना चाहिए? तकनीकी रूप से यह आवश्यक नहीं है (कोई त्रुटि नहीं) लेकिन अर्थपूर्ण दृष्टिकोण से यह समझ में आता है (कोई त्रुटि भी नहीं)। हमें उस तरह के मॉड्यूल के साथ क्या करना चाहिए? उन्हें आयात करें या नहीं? मुझे व्यक्तिगत रूप से दूसरी संभावना पसंद है क्योंकि यह कहता है 'अरे मैं एक फीचर मॉड्यूल हूं और मुझे इस सेवाओं की आवश्यकता है और मुझे इस व्यवसाय मॉडल कक्षाओं की आवश्यकता है'।

उत्तर के लिए धन्यवाद!

इसलिए मैं पुस्तकालयों/मॉड्यूलर एप्लिकेशन पुस्तकालयों और ngModule के साथ दर्द महसूस कर सकता हूं।

लेकिन जैसा कि कई बार कहा गया है कि दो संभावित तरीकों को न मिलाएं। वह है और भ्रमित करने वाला होगा।

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

तो जिस तरह से कंपोनेंट मॉड्यूल नामक एक नया डेकोरेटर नहीं जोड़ा जाता है, जो कि घटक और मॉड्यूल जैसे सामग्री को घोषित करने से बचने के लिए कम या ज्यादा चीनी है।

इस तरफ? अगर मुझे एक घटक दिखाई देता है। मुझे पता है कि यह एक ngModule का हिस्सा होना चाहिए। अगर मेरे पास कई कॉमनेंट्स को एक साथ बंडल करने का मामला है तो मैं NgModule का उपयोग कर सकता हूं। अगर मैं सिर्फ "पुराने घटकों" की तरह एक स्टैंडअलोन घटक चाहता हूं तो मैं कंपोनेंट मॉड्यूल का उपयोग करता हूं और मैं सभी निर्भरताओं को जानता हूं और यह अन्य मॉड्यूल के लिए मॉड्यूल निर्भरता हो सकता है, लेकिन उनका हिस्सा नहीं है

@nathraQ यदि प्रत्येक घटक के लिए NgModule का उपयोग करने के लिए सही दृष्टिकोण है, और यह अच्छी तरह से हो सकता है, तो NgModule को पेश नहीं किया जाना चाहिए था, और घटक को अभी बढ़ाया जाना चाहिए था। बॉयलरप्लेट के संबंध में, कोणीय 2 इस पर इतना भारी है कि इस बिंदु पर यह शायद ही मायने रखता है।

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

@aluanhaddad क्षमा करें मैं असहमत हूं। मेरे पास कस्टम निर्भरता प्रबंधन (जैसे इस धागे के स्टार्टर) के साथ कोणीय 1.x में केवल एक मॉड्यूल के लिए मेरे उपयोग के मामले थे, लेकिन मेरे पास नियंत्रकों, निर्देशों और सेवाओं के एक सेट को बंडल करने के लिए मॉड्यूल के मामलों का भी उपयोग किया गया था।

दोनों उपयोगी है। अब हमें यह पता लगाना होगा कि इसे सभी के लिए समझने योग्य कैसे एकीकृत किया जाए

वाह, वह एक लंबा पढ़ा था: मुस्कान:

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

@wardbell @robwormald -

यदि मैं SharedModule पैटर्न का उपयोग करता हूं, और मैं दो तृतीय पक्ष पुस्तकालयों (ui- my-selectbox बनाम angular-strap किसी को भी आयात करता हूं?)

यदि मैं उन दोनों को आयात करने का प्रयास करूँगा तो मुझे एक त्रुटि मिलेगी? अधिकार?

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

साथ ही, ऐसा हो सकता है कि मेरे पास एक ही नाम के साथ मेरा अपना घटक चयनकर्ता हो (और बड़ी परियोजनाओं में जो एक से अधिक बार हो सकता है)

क्या इस समस्या का कोई अनुशंसित समाधान है? या यह "आवरण मॉड्यूल" है?
(मुझे आशा है कि हम चयनकर्ताओं के लिए उपसर्ग का उपयोग करने के लिए वापस नहीं आएंगे, यह कोई मजेदार नहीं था)

अग्रिम में धन्यवाद!

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

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

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

यह सच है कि सरल अनुप्रयोगों को उन लाभों से उतना लाभ नहीं हो सकता है, लेकिन उन मामलों में NgModules वैसे भी "परेशान" से कम होना चाहिए।

@ एमिलियो-मार्टिनेज, जैसा कि @aluanhaddad ने लिखा है, ES6 और "पुराने कोणीय 2 तरीके" ने हमें वह नाम स्थान दिया जिसकी हमें आवश्यकता थी।

मैंने कोणीय 1 के साथ बहुत बड़ी परियोजनाओं पर काम किया है, जिसका नाम चयनकर्ता है: mb-product-list यदि यह एक बड़ी परियोजना है (यहां तक ​​​​कि 5+ डेवलपर्स की टीम में भी) दूसरों के साथ बहुत जल्दी टकरा सकता है।

इसे और अधिक नेमस्पेसिंग के साथ हल करने का प्रयास करने से आप समाप्त होते हैं: mb-somefeature-product-list जो टेम्प्लेट को गंदा दिखता है।

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

ngModules के अपने फायदे हैं जो निश्चित रूप से हैं, यह अतुल्यकालिक टुकड़ों को लोड करने में मदद करता है और हमें कम आयात लिखने और उत्पादकता में सुधार करने में भी मदद करता है।

लेकिन SharedModule पैटर्न का उपयोग करने से एक वैश्विक नामस्थान का परिचय होता है, जैसा कि हमने ng1 में किया था।

कम से कम प्रदाताओं के साथ, इसे ES6 टोकन, फ़ाइल स्थान द्वारा नामित किया गया है।

घटकों के साथ, चयनकर्ताओं के कारण, यह चिल्लाएगा कि एक ही चयनकर्ता के साथ दो घटक हैं।

काश हमारे पास तीसरे पक्ष या स्थानीय साझा घटकों के साथ टकराव के मामलों के उपयोग के लिए एक विशेष नामस्थान को कॉन्फ़िगर करने का कोई आसान तरीका होता।

"चयनकर्ता ओवरराइड" जैसा कुछ।

मैं यही पूछ रहा था

आपकी विस्तृत अंतर्दृष्टि के लिए धन्यवाद @robwormald , लेकिन मेरे जैसे नए लोगों से एक बात (ज्यादातर, मैं बैकएंड डेवलपर हूं)। मैं कोणीय 2 और टाइपप्रति के साथ सीख रहा हूँ। तो ES6 मॉड्यूल अवधारणा मेरे लिए धुंधली है
हमारे पास एक जटिल अनुप्रयोग संरचना है। यह एक एनालिटिक्स ऐप है, जहां मेरी कंपोनेंट काउंट लगभग 60 है।
और मुझे लगता है कि यह RC4 के तहत अच्छी तरह से संरचित है। लॉगिन के अलावा हमने किसी भी प्रकार की रूटिंग का उपयोग नहीं किया, क्योंकि राउटर पूरे घटक को फिर से बनाता है। इसलिए हम टैब आधारित ऐप के रूप में योजना बना रहे हैं। दो मुख्य टैब हैं (1.विश्लेषण 2.डैशबोर्ड)।
Analytics टैब में कई टैब होंगे, जिनमें से प्रत्येक के अंतर्गत एक ही विश्लेषण होगा। डैशबोर्ड में भी होगा
एकाधिक टैब लेकिन प्रत्येक टैब में एकाधिक विश्लेषण शामिल होंगे जो नीचे सहेजे गए थे
विश्लेषिकी अनुभाग। तो कई टैब से आगे और पीछे जा रहे हैं (डैशबोर्ड और विश्लेषण दोनों के तहत)
और डैशबोर्ड टैब और एनालिटिक्स टैब के बीच स्विच करने पर, हमें लगता है कि रूटिंग काम नहीं करेगी
हमारा उद्देश्य (अगर मैं कुछ गूंगा कह रहा हूं तो मुझे सुधारें)।
अब RC5 NgModule हमारे एप्लिकेशन को तोड़ रहा है। हम वास्तव में नहीं जानते कि कैसे
हमारे आवेदन को नया स्वरूप दें। क्या हम वास्तव में अपने आवेदन में एओटी संकलन का उपयोग कर सकते हैं? नहीं है
पूरी AoT चीज़ रूटिंग पर आधारित है?

@shairez NgModules इस तरह के नेमस्पेसिंग प्रदान करते हैं। इस बात को थोड़ा और स्पष्ट करने का प्रयास करता हूँ...

यहां समझने वाली महत्वपूर्ण बात यह है कि एक घटक संकलित है, कमोबेश, "अंदर" मॉड्यूल में इसे घोषित किया गया है - एक उदाहरण के लिए https://plnkr.co/edit/9w10b1Y8Bjr5DDIxOwnC?p=preview देखें।

ध्यान दें कि दो परस्पर विरोधी चयनकर्ता हैं ( my-generic-selector ) - प्रत्येक फीचर मॉड्यूल उनमें से एक को आयात करता है, किसी भी "वैश्विक" नामस्थान को प्रदूषित किए बिना, उस मॉड्यूल में आंतरिक रूप से इसका उपयोग करने में सक्षम है।

तो इस्तेमाल किया जैसे

<my-app>
  <!-- belongs to FeatureModuleOne -->
  <feature-one></feature-one>
  <!-- belongs to FeatureModuleTwo -->
  <feature-two></feature-two>
</my-app>

तक फैलता है

<my-app>
  <!-- belongs to FeatureModuleOne -->
  <feature-one>
    <!-- the generic imported in FeatureModuleOne -->
     <my-generic-selector></my-generic-selector>
  </feature-one>
  <!-- belongs to FeatureModuleTwo -->
  <feature-two>
    <!-- the generic imported in FeatureModuleTwo -->
    <my-generic-selector></my-generic-selector>
  </feature-two>
</my-app>

बिना किसी विरोध के, क्योंकि जब कंपाइलर फीचर-वन और फीचर-दो को संकलित करता है, तो यह उस मॉड्यूल के संदर्भ में ऐसा करता है जिससे वे संबंधित हैं, जो वैश्विक दायरे को प्रदूषित करने से बचाता है।

@robwormald ज़रूर, यह कमाल है और उस अर्थ में कोणीय 1 से बेहतर है।

मैंने जिस उपयोग के मामले के बारे में लिखा था, वह वैश्विक SharedModule का उपयोग करने के पैटर्न का जिक्र कर रहा था जैसा कि डॉक्स में सुझाया गया था।

अगर मैं GenericSelectorFeatureOne और GenericSelectorFeatureTwo दोनों को SharedModule के अंदर घोषित करने का प्रयास करूंगा, तो मुझे एक त्रुटि सही मिलेगी?

या अगर SharedModule में उपयोगी सामान्य घटकों का एक पूरा समूह है और मैं इसे हर फीचर मॉड्यूल में आयात करना चाहता हूं।

अगर मेरे फीचर मॉड्यूल में एक टकराने वाला चयनकर्ता है, या किसी तीसरे पक्ष के पास मौजूदा पुस्तकालयों में से एक के साथ टकराने वाला चयनकर्ता है SharedModule , तो यह एक त्रुटि जारी करेगा, है ना?

@shairez मुझे लगता है कि अधिकांश एप्लिकेशन कई "साझा मॉड्यूल" के साथ समाप्त हो जाएंगे, और टकराव की संभावना कम है - मॉड्यूल सस्ते हैं, इसलिए बहुत सारे होने की कोई बड़ी लागत नहीं है।

यदि आपके पास दस्तावेज़ों को बेहतर बनाने के बारे में विचार हैं तो एक पीआर का सहर्ष स्वागत किया जाएगा।

धन्यवाद वह उत्तर है जिसे मैं ढूंढ रहा था, मैं इसका परीक्षण करूंगा।

मॉड्यूल लिखने के नए तरीके के साथ इसे हल करने के बारे में मेरे पास अभी तक बेहतर विचार नहीं हैं, इसलिए मैंने इसे यहां पूछा, लेकिन एक बार जब मैं एकाधिक साझा मॉड्यूल समाधान का परीक्षण करूंगा तो मेरे पास इस पर चर्चा करने के लिए और सामग्री होगी @ वार्डबेल और एक पीआर जमा करें।

@robwormald मदद के लिए धन्यवाद!

https://angular.io पर उपलब्ध नवीनतम दस्तावेज़ों से, एंटी-पैटर्न और बग के बारे में _many_ चेतावनियां हैं जो आसानी से उभर सकती हैं यदि NgModule s गलत तरीके से बनाए गए हैं। उदाहरण के लिए

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

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

एक और, प्रतीत होता है कि अधिक गंभीर समस्या डॉक्स के निम्नलिखित अनुभागों को जोड़ने से उत्पन्न होती है

मान लीजिए कि एक मॉड्यूल को एक अनुकूलित HttpBackend की आवश्यकता होती है जो सभी Http अनुरोधों के लिए एक विशेष शीर्षलेख जोड़ता है। यदि एप्लिकेशन में कहीं अन्य मॉड्यूल भी HttpBackend को अनुकूलित करता है या केवल HttpModule आयात करता है, तो यह इस मॉड्यूल के HttpBackend प्रदाता को ओवरराइड कर सकता है, विशेष हेडर खो देता है। सर्वर इस मॉड्यूल से http अनुरोधों को अस्वीकार कर देगा।
HttpModule को केवल AppModule, एप्लिकेशन रूट मॉड्यूल में आयात करके इस समस्या से बचें।

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

तो एक तरफ, दस्तावेज़ उपयोगकर्ताओं को कुछ मॉड्यूल को फिर से निर्यात करने से हतोत्साहित करते हैं, जबकि साथ ही यह बताते हुए कि ऐसा करने से एक बड़ी सुविधा मिलती है।

NgModule पुन: निर्यात की धारणा ES मॉड्यूल पुन: निर्यात के समान है सिवाय इसके कि आपके पास कम नियंत्रण है। जावास्क्रिप्ट स्थिर रूप से स्कोप है (हाँ मुझे पता है कि this नहीं है) और यह इसकी सबसे बड़ी ताकत है, जो बेहद लचीली रचना और जानकारी छिपाने की अनुमति देता है। जावास्क्रिप्ट भी छायांकन का समर्थन करता है ताकि आपके पास हमेशा एक दायरे को ओवरराइड करने का एक तरीका हो।

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

डॉक्स इस बारे में कुछ नहीं कह रहे हैं कि क्या पुन: निर्यात सकर्मक हैं ... मॉड्यूल ए कॉमनमॉड्यूल को फिर से निर्यात करता है। मॉड्यूल बी फिर से निर्यात करता है मॉड्यूल ए। मॉड्यूल सी मॉड्यूल बी आयात करता है। क्या इसका मतलब यह है कि मॉड्यूल सी अब कॉमन मॉड्यूल से निर्देशों का उपयोग कर सकता है?

@ मार्टिन-वेग्नर वे यहाँ वर्णित के अनुसार सकर्मक हैं https://angular.io/docs/ts/latest/cookbook/ngmodule-faq.html#! #q-पुनः निर्यात

@aluanhaddad कहाँ? मुझे एक से अधिक हॉप के साथ ट्रांजिटिव री-एक्सपोर्ट के बारे में कोई शब्द नहीं मिल रहा है ...

यह पढ़कर कि @aluanhaddad ने कोणीय के डॉक्स से क्या पकड़ा है, मुझे ऐसा लगता है कि मुझे एंगुलर 2 के बारे में जो कुछ भी सीखा है, उस पर पुनर्विचार करना होगा और हो सकता है कि ऐसा कोई ढांचा न हो जो निर्भरता को बेहतर तरीके से संभालता हो।

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

आपने अभी जो कहा, उसमें वास्तव में बहुत समझदारी है। मैंने इसे शुरू किया
angular2 पिछले साल से यात्रा और धड़कन महसूस करने का कोई कारण नहीं है
अब तक देखे गए सभी महत्वपूर्ण परिवर्तनों के बावजूद (अल्फ़ा से बीटा तक,
और आरसी)। यह उन चरणों में समझ में आता है और चूंकि यह धार्मिक रूप से अटका हुआ है
दर्शन के लिए यह मुझे मेरे न्यूनतम बैकबोनज से परिवर्तित करने में उपयोग करता था।
मेरे लिए इस ngModules का पूरा विचार कुछ हद तक विपरीत साबित हुआ है
उत्पादक। और यह देखकर दुख होता है कि मैंने पूरे समय सुसमाचार प्रचार में लगा दिया
न्यूनतावादी और ब्लोट-मुक्त "घटकों" की समृद्ध अच्छाई पर जाएं
बिल्कुल बेकार।
29 अगस्त 2016 को सुबह 9:44 बजे, "डैनियल शूबा" नोटिफिकेशन @github.com ने लिखा:

पढ़ना क्या @aluanhaddad https://github.com/aluanhaddad से पकड़ा गया
कोणीय के डॉक्स मुझे ऐसा लगता है कि मुझे अपने पास मौजूद हर चीज पर पुनर्विचार करना होगा
कोणीय 2 के बारे में सीखा और शायद भले ही कोई ढांचा न हो
निर्भरता को बेहतर तरीके से संभालता है।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/angular/angular/issues/10552#issuecomment -243066961
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AF675h8_np9i5cHgL8mMOOu8vMMQmWKkks5qkpv8gaJpZM4Jee-o
.

अगर मैं गलत हूं तो क्या कोई मुझे सही कर सकता है।

मैं एक ऐप को निम्नानुसार व्यवस्थित करने पर सोच रहा हूं।

अनुप्रयोग
|--कानून/
|----कई घटक।
|----LawNGModule.
|--उपयोगकर्ता/
|----कई घटक
|---- UserNGModule
|--AppNGModule
|--SomeFirstLeveComponents

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

या हो सकता है कि यह एक ऐसा मामला है जहां आप y (सामग्री) को फिर से निर्यात करने के लिए एक मॉड्यूल x बनाते हैं, और आप इसे उन मॉड्यूल में आयात करते हैं जिनकी आपको आवश्यकता होती है?

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

@robwormald ऊपर आपकी टिप्पणी के जवाब में:

हालांकि, एओटी मोड में, यह थोड़ा अलग तरीके से काम करता है - निर्माण के समय, हम सांख्यिकीय रूप से (अर्थात, आपके कोड को निष्पादित किए बिना) डेकोरेटर के लिए स्कैन करके स्रोत कोड से समान मेटाडेटा निकालते हैं।

क्या इसका मतलब यह है कि आप मूल स्रोत कोड से स्थिर रूप से मॉड्यूल निकाल रहे हैं, और इस तरह, हम प्रभावी रूप से गतिशील रूप से मॉड्यूल नहीं बना सकते हैं?

माइग्रेशन को आसान बनाने के लिए, मैं एक ऐसा फ़ंक्शन बनाने के बारे में सोच रहा था जो गतिशील रूप से मॉड्यूल बनाएगा; कुछ इस तरह:

function createModule (entryComponent: Type, dependencies: Type[]) {
    @NgModule({
        imports: [CommonModule, FormsModule],
        declarations: [entryComponent, ...dependencies],
        exports: [entyComponent]
    })
    class FeatureComponent {}
    return FeatureComponent;
}

तो जबकि यह (संभावना?) जेआईटी संकलन के साथ काम करेगा, यह एओटी के साथ काम नहीं करेगा क्योंकि एओटी डेकोरेटर्स की तलाश में स्रोत कोड को स्थिर रूप से पार्स करता है?

ES@next.... @aluanhaddad के युग में यह अनावश्यक जटिलता कुछ बहुत अच्छी बातें बताती है।

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

मुझे @DaSchTour की तरह करना पड़ सकता है और अन्य फ्रंट-एंड फ्रेमवर्क पर शोध करना पड़ सकता है। बहुत बुरा, क्योंकि कुछ महीने पहले, NG2 के साथ काम करने में काफी आनंद आया था और कूड़े से मेरी स्पष्ट पसंद थी।

@iyobo बदलने के शुरुआती दर्द के अलावा, NgModules पर प्रतिक्रिया के _vast_ बहुमत (और मैं डेवलपर्स के _lot_ से बात करता हूं) सकारात्मक रहा है।

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

मैं यहां @robwormald के साथ हूं, RC4/5 से NgModules में माइग्रेट करने का प्रारंभिक दर्द हर एक घटक/पाइप को नए बनाए गए पृष्ठ में आयात न करने के लाभों को देखने के बाद प्रबंधनीय था।
NgModules थोड़ा अधिक जटिल होने और बहुत सारे साझा घटकों के होने के बाद चमकने लगते हैं।

SharedModule आयात करना और इसके साथ काम करना इतना आसान है।

अरे @robwormald , यह धारणा कि कोई एनजी 2 की वर्तमान दिशा से असहमत है, किसी भी तरह से एक तथ्यात्मक दावा नहीं है कि वे केवल "हैलो वर्ल्ड" स्तर के ऐप्स पर काम करते हैं।

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

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

यह सिर्फ मुझे लगता है कि NgModules एक समस्या की तलाश में एक वास्तविक समस्या के समाधान की तुलना में एक समाधान है। लेकिन फिर, मैं सब कुछ जानने का दावा नहीं कर सकता...

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

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

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

मैं वास्तव में सराहना करता हूं यदि NgModules के लिए एक तंत्र _in अतिरिक्त_ था जो घटकों को अन्य घटकों या निर्देशों को स्थानीय रूप से स्कोप्ड निर्भरता के रूप में परिभाषित करने की अनुमति देता है जो केवल उस सटीक घटक के भीतर लागू होता है (ठीक उसी तरह जैसे directives लिस्टिंग मॉड्यूल से पहले काम करती है)।

मुझे उन लोगों के लिए एक विकल्प रखने का @poke का सुझाव पसंद है जो पूर्ण NgModules नहीं जाना चाहेंगे।

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

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

मुझे मूल घटक-केंद्रित योजना अधिक पसंद आई, शायद यही वजह है कि मैं अब पॉलिमर/वेब घटकों को बेहतर फिट पा रहा हूं। मॉड्यूल सिर्फ एंगुलर 1 से आधा कदम पीछे की तरह लगता है।

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

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

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

@ Angular2 के सभी लेखकों के लिए: क्या आप कृपया हमें ईमानदारी से बता सकते हैं कि NgModules के नकारात्मक भाग क्या हैं? मुझे पता है कि आप सभी अच्छी चीजों के बारे में एक किताब लिख सकते हैं। यह ठीक है। लेकिन मुझे हमेशा छिपी हुई बुरी चीजों से निपटने की जरूरत है जो स्पष्ट नहीं होंगी यदि आप उनके बारे में बात नहीं करेंगे।

क्या कोई मुझे दिखा सकता है कि NgModules वास्तव में एक जटिल ऐप में कैसे काम करता है जहां कई घटकों को कई स्तरों पर कई अन्य की आवश्यकता होती है?

ऐसा करने का एक तरीका केवल उन घटकों के लिए एक निर्भरता मॉड्यूल बनाना होगा: मान लें कि आपके पास घटकों के तीन सेट हैं A , B , और C जिसमें कई घटक हैं प्रत्येक और प्रत्येक सेट में वे होते हैं जो कुछ हद तक संबंधित होते हैं। तो ये तीन सेट तीन अलग-अलग मॉड्यूल के लिए अच्छा काम करेंगे।

अब, उन सेटों में से प्रत्येक में घटकों को एक सेट D से कई घटकों की आवश्यकता होती है। D में वे घटक केवल उन तीन सेटों के घटकों के लिए उपयोग किए जाते हैं। चूंकि वे उन सभी में उपयोग किए जाते हैं, आप केवल उन मॉड्यूल में घटकों को नहीं जोड़ सकते हैं (क्योंकि घटक केवल एक मॉड्यूल का हिस्सा हो सकते हैं)। इस बिंदु पर, आप A , B , C , और D को एक विशाल मॉड्यूल में मर्ज कर सकते हैं, इसलिए सभी निर्भरताएं हैं। लेकिन यह निश्चित रूप से बहुत गन्दा है। इसके बजाय, आप केवल D के लिए एक नया मॉड्यूल बनाते हैं जिसमें केवल वे निर्भरताएँ होती हैं। यह मॉड्यूल उन मॉड्यूल तक पहुंच प्रदान करने के अलावा कुछ नहीं करता है। अब आप उन तीन अन्य मॉड्यूलों में से प्रत्येक में उस मॉड्यूल को आयात कर सकते हैं, और घटकों का उपयोग करने में सक्षम हैं। लेकिन चूंकि घटक अभी भी "निजी" हैं, इसलिए आप मॉड्यूल का पुन: निर्यात नहीं करते हैं या किसी अन्य मॉड्यूल में मॉड्यूल D आयात नहीं करते हैं।

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

मैं अपना वर्तमान सेटअप साझा कर सकता हूं। मैंने ऐप में 3 मॉड्यूल का उपयोग किया है: कॉमन मॉड्यूल, ऐप मॉड्यूल और टेस्ट मॉड्यूल।

• CommonModule सबसे सामान्य सामान जैसे HttpModule, FormsModule, MdInputModule आदि का आयात और निर्यात करता है
• AppModule BrowserModule, CommonModule, app.routing और अलग-अलग घटकों को आयात करता है
• TestModule बेसमॉड्यूल को आयात और निर्यात करता है, लेकिन कुछ प्रदाताओं को अधिलेखित कर देता है, जैसे XHRBackend MockBackend के साथ

मैंने इस सेटअप को TestBed.configureTestingModule को सरल बनाने के लिए पेश किया है,
ताकि मुझे TestModule आयात करना पड़े और फिर केवल एक घटक जैसे:

TestBed.configureTestingModule({
  imports: [ TestModule ],
  declarations: [ MyFormComponent ]
});

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

यह सीधे तौर पर @poke की बात से जुड़ा है

मैं वास्तव में सराहना करता हूं अगर NgModules के अलावा एक तंत्र था जो घटकों को अन्य घटकों या निर्देशों को स्थानीय रूप से स्कोप्ड निर्भरता के रूप में परिभाषित करने की अनुमति देता है जो केवल उस सटीक घटक के भीतर लागू होते हैं (ठीक उसी तरह जैसे कि निर्देश सूची मॉड्यूल से पहले कैसे काम करती है)।

मैं दृढ़ता से असहमत हूँ। एक मॉड्यूलर आर्किटेक्चर जैसा कि एंगुलर 2 द्वारा प्रस्तावित किया गया है, जहां आवश्यक हो, स्केल करना, समायोजित करना और रिफैक्टर करना आसान है। ज़रूर, RC4 से RC5 तक थोड़ा सा समायोजन था, लेकिन अगर कुछ भी हो, तो मेरे लिए NgModules ने बहुत अधिक लचीले अनुप्रयोग की अनुमति देने के लिए सिद्ध किया है।

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

@ एमिलियो-मार्टिनेज: मेरी राय में, एनजीएमड्यूल को कभी भी पेश नहीं किया जाएगा, अगर जीईटी को शामिल करते समय एंगुलर 2 बूटस्ट्रैपिंग में इतना धीमा नहीं था। अन्य सभी 'सुधार' जैसे 'स्केलिंग, एडजस्टिंग, और रिफैक्टरिंग' बहस योग्य हैं, जैसा कि इस चर्चा से पता चलता है।

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

मेरा मानना ​​​​है कि हम सभी अब से एक साल बाद पाएंगे कि कई कोणीय 2+ एप्लिकेशन मॉड्यूल का व्यापक, निर्बाध उपयोग, आलसी लोडिंग और एओटी बनाते हैं। मेरा मानना ​​​​है कि "प्रगतिशील अनुप्रयोग" दृष्टि को लागू करने के लिए इन चीजों का उपयोग करने के लिए अधिकांश या लगभग सभी अनुप्रयोगों के लिए यह पूरी तरह से नियमित होगा, जहां बड़े जटिल अनुप्रयोगों के पास तत्काल प्रारंभिक लोड समय होता है और फिर आलसी लोड (या आशावादी रूप से आलसी प्रीलोड) कार्यक्षमता वे ज़रूरत। परिणाम वास्तव में काफी आश्चर्यजनक रूप से धीमा है, और व्यक्तिगत एप्लिकेशन डेवलपर के लिए उल्लेखनीय रूप से कम लागत पर हासिल किया गया है: NgModule मूल रूप से वह लागत है, और यह एक परेशान करने वाला संक्रमण है लेकिन फिर उपयोग करने के लिए चल रहे काम की केवल एक बहुत ही मामूली राशि है।

@kylecordes मुझे आशा है कि आप सही हैं और मुझे लगता है कि यह सही रवैया है।

@ iurii-kyrylenko यह बहुत सच है।

मुझे अपने जावास्क्रिप्ट को संकलित करने वाले कोणीय के साथ समस्या है क्योंकि यह टाइपस्क्रिप्ट को मेरी जावास्क्रिप्ट को संकलित करना है, लेकिन यह एक अलग मुद्दा है।

@kylecordes मुझे लगता है कि केवल संक्रमण की तुलना में विचार करने के लिए बहुत कुछ है। मॉड्यूल स्वयं के एप्लिकेशन में बग जोड़ने के लिए बहुत अधिक जटिलता और बहुत सी अतिरिक्त संभावनाएं पेश करते हैं। सबसे बड़ी समस्या निर्भरता का आक्षेप है। जो कोणीय 2 के साथ विकसित होने के अगले वर्षों में बहुत परेशानी का कारण बनेगा।

@aluanhaddad मेरा मानना ​​​​है कि कोणीय संकलन के लिए एक tsc आवरण का उपयोग करता है। यह अच्छा है क्योंकि आप इसे एक कार्य धावक वर्कफ़्लो में भी लागू कर सकते हैं, उदाहरण के लिए।

@ iurii-kyrylenko बूटस्ट्रैपिंग गति भी RC4 के आधार पर निर्धारित करना कठिन है। तब से लेकर अंतिम रिलीज तक बहुत सारे काम क्लीनअप और ऑप्टिमाइजेशन रहे हैं। मेरे अनुभव में कोणीय संकलित JIT वैसे भी RC4 की तुलना में तेज चलता है।

@DaSchTour क्या आप NgModule के साथ काम करते समय मिली बग के बारे में विस्तार से बता सकते हैं?

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

जरा सोचिए कि टाइपस्क्रिप्ट इस तरह से काम कर रहा है। मेरे पास मेरे मॉड्यूल के लिए एक आधार फ़ाइल है, आइए इसे _index.ts_ कहते हैं, यह इस तरह दिखता है।

import {foo} from bar;
import {StartComp} from start;

StartComp.boot();

हमारे पास start.ts नामक एक फ़ाइल है जो इस तरह दिखती है।

export class StartComp {
   public static boot() {
      foo()
   }
}

एंगुलर NgModules के साथ यही कर रहा है। कुछ जादू के साथ मैंने मॉड्यूल में कुछ आयात किया है और यह मेरे आवेदन के दूसरे छोर पर दिखाई देता है। आपको यह जानना होगा कि index.ts में foo आयात किया जाता है और StartComp को अनुक्रमणिका से चलाकर वहां के आयात का उपयोग घटक में किया जा सकता है।

निर्भरताएं छिपी हुई हैं और उन्हें खोजने के लिए अतिरिक्त जांच की आवश्यकता है।

@ एमिलियो-मार्टिनेज़

मेरे अनुभव में कोणीय संकलित JIT वैसे भी RC4 की तुलना में तेज चलता है।

मेरे पास एक मध्यम जटिलता परियोजना है , जो मीन स्टैक और एंगुलर 2 फाइनल पर आधारित है। मेरे Android डिवाइस पर JIT मोड में बूटस्ट्रैप को पूरा करने में लगभग 10 सेकंड का समय लगता है। मैं इसे एक महत्वपूर्ण देरी मानता हूं। वर्तमान में मैं अपने स्रोत कोड को संशोधित किए बिना एओटी संकलन का उपयोग नहीं कर सकता (निजी सदस्यों के साथ समस्याएं, एल्विस ऑपरेटर ...)

क्या किसी के पास वास्तविक जीवन परियोजनाओं के लिए प्रदर्शन एओटी+आलसी भार के बारे में कोई जानकारी है?

मेरा मानना ​​है कि कोणीय संकलन करने के लिए एक tsc आवरण का उपयोग करता है। यह अच्छा है क्योंकि आप इसे एक कार्य धावक वर्कफ़्लो में भी लागू कर सकते हैं, उदाहरण के लिए।

@ एमिलियो-मार्टिनेज यह वही है जो मैं नहीं चाहता। मैं टाइपस्क्रिप्ट के किसी भी संस्करण का उपयोग करके अपना कोड संकलित करना चाहता हूं, उदाहरण के लिए 2.1.0-देव जिसमें एसिंक/प्रतीक्षा के लिए डाउन लेवल एमिट है। मैं नहीं चाहता कि एंगुलर मेरी टाइपस्क्रिप्ट फाइलों को संकलित करने का प्रभारी हो, इसे एक ढांचे में नहीं सौंपा जाना चाहिए, यह एक भाषा की भूमिका है। विषय से आगे निकले बिना मैं दस फुट के पोल के साथ @Script को नहीं छूता, भगवान का शुक्र है कि यह मर चुका है।
वर्कफ़्लो के अनुसार, मैं JSPM और कभी-कभी वेबपैक का उपयोग करता हूं, पारंपरिक कार्य धावक नहीं, और मैं अपने IDE को अपने लिंटर्स को संभालने देता हूं।

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

@aluanhaddad यह समझना महत्वपूर्ण है कि AoT संकलन के दौरान दो अलग-अलग चरण होते हैं - पहला _new_ टाइपस्क्रिप्ट कोड उत्पन्न कर रहा है, दूसरा उस कोड को ES5/6 में स्थानांतरित कर रहा है। ngc दोनों सुविधा के रूप में करते हैं, लेकिन एओटी में कुछ भी निहित नहीं है जिसके लिए इसकी आवश्यकता है। Google के अंदर, हम दोनों करते हैं, और इसलिए मामला प्राथमिकता है। कोई भी किसी भी वातावरण में कोड पीढ़ी का समर्थन करने के लिए एक कंपाइलर होस्ट को लागू कर सकता है।

हम (अभी तक) एंगुलर बिल्ट इन डेकोरेटर्स के शीर्ष पर एब्सट्रैक्टिंग का समर्थन नहीं करते हैं, लेकिन अगर आप https://www.npmjs.com/package/core-decorators जैसी किसी चीज़ का उपयोग करना चाहते हैं, तो यह ठीक रहेगा।

@ iurii-kyrylenko का सुझाव है कि आप AngularConnect के पहले दिन को देखें, जहां LucidCharts ने AoT के साथ अपने अनुभव के बारे में बात की थी। देखें https://youtu.be/xQdV7q3e_2w?t=1411

IMHO - हर किसी का #1 लक्ष्य जल्द से जल्द AoT संकलन पर होना चाहिए। प्रदर्शन बस अपराजेय है।

@robwormald मैंने यह नहीं देखा है कि ngc पर कॉल करते समय कौन से विकल्प उपलब्ध हैं - इसलिए इसे पहले ही कवर किया जा सकता है। मुझे लगता है कि वे विकल्प यहां आवाज उठाई गई चिंताओं को कम कर सकते हैं, अगर वे यह स्पष्ट करते हैं कि एनजीसी पहले उद्देश्य को सुविधा/अनुकूलन के रूप में दूसरे उद्देश्य में मौजूद होने के मुख्य कारण के रूप में पूरा कर रहा है। यदि दस्तावेज़ या सहायता से पता चलता है कि जो लोग ऐसा करना पसंद करते हैं उनके लिए अलग से tsc कैसे चलाया जाता है, तो इससे चिंताओं को और कम किया जा सकता है?

@kylecordes मुझे नहीं लगता कि प्रलेखन किसी भी समय जल्द ही अपने स्वयं के कंपाइलर होस्ट को कार्यान्वित करने के तरीके को कवर करने जा रहा है। यह एक उन्नत उपयोग का मामला है, और इस प्रकार इसे लागू करने के लिए कुछ स्व-निर्देशित सीखने की आवश्यकता होगी। हमने यहां सीएलआई के लिए एक समान चीज लागू की है https://github.com/angular/angular-cli/tree/master/packages/webpack

@robwormald आह, मेरा मतलब यह नहीं है कि आप अपना खुद का कंपाइलर होस्ट लागू करें। मेरा मतलब सिर्फ दो-पंक्ति "बिल्ड प्रोसेस" से था - पहले ngc को कुछ जेनरेट टाइपस्क्रिप्ट को उत्सर्जित करने के लिए कॉल करना, फिर tsc को सभी टाइपस्क्रिप्ट (आपके स्रोत प्लस जेनरेट किए गए स्रोत) को संकलित करने के लिए स्वयं को कॉल करना जावास्क्रिप्ट। यह एक त्वरित आश्वासन प्रदान करता है कि टाइपस्क्रिप्ट कोड केवल JS को ऑफ-द-शेल्फ टाइपस्क्रिप्ट कंपाइलर द्वारा संकलित किया जा रहा है।

@robwormald आपके उत्तर के लिए धन्यवाद।
एनजीसी के संबंध में, मैं यह जानना चाहता हूं कि क्या मैं टाइपस्क्रिप्ट कंपाइलर संस्करण और सेटिंग्स को TS -> TS पास में नियंत्रित कर सकता हूं। क्या मैं एनजीसी को टाइपस्क्रिप्ट पास कर सकता हूं या क्या मुझे एक विशिष्ट संस्करण का उपयोग करना होगा जो एक विशिष्ट टाइपस्क्रिप्ट संस्करण को लपेटता है? वे कितने युग्मित हैं?

सज्जाकारों के संबंध में, क्या उपयोगकर्ता परिभाषित सज्जाकारों के लिए कोई समस्या ट्रैकिंग समर्थन है जो कोणीय सज्जाकारों पर सार है? https://www.npmjs.com/package/core-decorators डेकोरेटर्स का एक ऑर्थोगोनल सेट है, लेकिन मेरे पास डेकोरेटर हैं जो एंगुलर डेकोरेटर्स को लपेटकर मेरे एंगुलर ऐप में पैटर्न और कन्वेंशन लागू करते हैं। इसके लिए एक स्पष्ट उपयोग मामला पैकेज वाइड घटक नाम उपसर्गों को स्वचालित रूप से बनाना और लागू करना है, लेकिन अन्य भी हैं।

चूंकि एनजीसी इसका समर्थन नहीं करता है, यह कैसे पता चलता है कि कौन से डेकोरेटर कोणीय विशिष्ट हैं?
क्या यह नाम से कोणीय सज्जाकार से मेल खाता है?
मुझे उम्मीद नहीं है क्योंकि यह जावास्क्रिप्ट लेक्सिकल स्कोपिंग का उल्लंघन करेगा।
एक साधारण परिदृश्य
_विस्मयकारी-घटक-सज्जाकार.ts_

import { Component } from '@angular/core';
import template from './awesome-component.html';
import style from './awesome-component.less';

export const awesomeComponet = <T extends new (...args) => any>(target: T) =>
  Component({template, styles: [style], selector: snakeCase(target.name) })(target);

_उपभोक्ता.ts_

import { awesomeComponet } 'app/shared/awesome-component-decorators';

<strong i="19">@awesomeComponent</strong> 
export class AnAwesomeComponent { }

<strong i="20">@awesomeComponent</strong> 
export class AnotherAwesomeComponent { }

@jpsfs क्या आपने रूट एप्लिकेशन मॉड्यूल में घटक घोषणाओं को जोड़े बिना घटकों को गतिशील रूप से लोड करने का कोई समाधान पाया है? .

मैं कोणीय 1.X से कोणीय 4 माइग्रेशन प्रोजेक्ट का भी हिस्सा हूं। इस परियोजना में बड़ी संख्या में घटक हैं जो विभिन्न अनुप्रयोगों में पुन: उपयोग किए जाते हैं जो कि अनुप्रयोग संदर्भ के आधार पर आलसी लोड होते हैं।

कोणीय 4 . में मेरी समझ के अनुसार

हमें घटक निर्भरता को रूट @NgModule घोषणाओं में नीचे के रूप में जोड़ना होगा।

{platformBrowserDynamic} को "@angular/platform-browser-dynamic" से इंपोर्ट करें;
"@angular/core" से {घटक, NgModule} आयात करें;
...
...
@NgModule({
आयात: [ब्राउज़र मॉड्यूल], // आयात कोणीय के ब्राउज़र मॉड्यूल
बूटस्ट्रैप: [बूटस्ट्रैपकॉम्प], // बूटस्ट्रैप घटक को इंगित करें
घोषणाएं: [com1, COMP2, COMP5 ...... COMP n] // हमारे घटक को मॉड्यूल के साथ पंजीकृत करें
})
निर्यात वर्ग ऐपमॉड्यूल {}

platformBrowserDynamic().bootstrapModule(AppModule);

लेकिन हमारे मामले में हम संकलन समय में घटक निर्भरता के बारे में जानने के लिए NgModule को रूट नहीं करना चाहते हैं। बल्कि हम चाहते थे कि रन टाइम में घटकों को गतिशील रूप से लोड किया जाए।
क्या आपको कोई अच्छा समाधान मिला जो रूट NgModule घोषणाओं में सभी घटकों को जोड़े बिना एप्लिकेशन को बूटस्ट्रैप कर सकता है (और हम प्रत्येक घटक के लिए एक NgModule भी नहीं चाहते हैं :))

@DaSchTour

याद रखें कि आपका ऐप एंट्रीपॉइंट इस तरह कब दिखता था?

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

मैं कोणीय 2 में कुछ समान और आसान समाधान ढूंढ रहा हूं।

@समुद्रक यदि आप कोणीय एओटी समर्थन का उपयोग करना चाहते हैं तो आप केवल घटक को आलसी लोड नहीं कर सकते हैं। आपको प्रत्येक घटक के लिए आलसी मॉड्यूल सेट करना होगा और मॉड्यूल को आलसी लोड करना होगा। हम अपने आवेदन में समान दृष्टिकोण का उपयोग करते हैं ...

ईसीएमएस्क्रिप्ट में गतिशील आयात समर्थन के साथ और अब टाइपस्क्रिप्ट में (लोडिंग के लिए पूर्ण प्रकार की जांच ऑर्थोगोनल के साथ), आलसी लोडिंग उपयोग मामला काफी मनमाना है। निश्चित रूप से दृष्टि 20/20 है और यह जानने का कोई तरीका नहीं था कि ऐसा होगा।

निष्क्रियता के कारण यह समस्या अपने आप लॉक हो गई है।
यदि आप समान या संबंधित समस्या का सामना कर रहे हैं तो कृपया एक नया मुद्दा दर्ज करें।

हमारी स्वचालित वार्तालाप लॉकिंग नीति के बारे में और पढ़ें।

_{_यह क्रिया किसी बॉट द्वारा स्वचालित रूप से की गई है।_}