कोणीय 2 +/4/5: स्मार्ट, गूंगा और गहराई से नेस्टेड घटक संचार

Question

नोट: सादगी के रूप में घटक गहराई पर विचार के लिए:

- Smart (grand)parent level 0 
    - dumb child level 1 
    .... 
    - dumb grandchild level 2 
     ....) 

वहाँ विभिन्न विकल्प और पर स्थितियां हैं कैसे स्मार्ट/भव्य/माता-पिता/बाल घटक संवाद करते हैं और एक बहु-स्तर (कम से कम 3 स्तर) श्रृंखला को ऊपर और नीचे डेटा पास करते हैं। हम अपने 'स्मार्ट' (ग्रैंड) पैरेंट घटक को एकमात्र घटक के रूप में रखना चाहते हैं जिसके पास हमारी डेटा सेवा (या परमाणु/अपरिवर्तनीय स्टोर) तक पहुंच है और यह 'गूंगा' (ग्रैंड) बच्चों के साथ जानकारी का आदान-प्रदान चलाएगा। हमारे द्वारा देखे जाने वाले विकल्प हैं:

1. एंटी-पैटर्न (?): @ इनपुट/@ आउटपुट बाइंडिंग के माध्यम से घटक श्रृंखला को नीचे और ऊपर डेटा पास करें। कुछ लोगों को 'अपर्याप्त गुण' या 'कस्टम इवेंट बबलिंग समस्या' समस्या के रूप में संदर्भित किया जाता है (उदाहरण: here और here।) समस्या। नही जाओ।
2. एंटी-पैटर्न: @ViewChildren या @ContentChilden के माध्यम से गूंगा (भव्य) बच्चों के लिए स्मार्ट घटक पहुंच। यह फिर से बच्चों को कड़ी मेहनत करता है और अभी भी (ग्रैंड) बच्चों को स्मार्ट घटक को डेटा यूपी पास करने के लिए एक स्वच्छ तंत्र नहीं बनाता है।
3. साझा संदेश सेवा angular.io रसोई की किताब here और एक उत्कृष्ट पोस्ट here में वर्णित है।
4. ?

अब '3' के मामले में, गूंगा (भव्य) बच्चों को संदेश सेवा इंजेक्शन होना चाहिए। जो मुझे अपने सवालों के लाता है:

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

Q1A: इसके अतिरिक्त, कैसे है इतना @ इनपुट/आउटपुट @ बाइंडिंग ऊपर और श्रृंखला के नीचे जोड़ने सभी घटकों को एक सेवा इंजेक्शन होगा अगर तुलना में बेहतर? (मुझे तर्क है कि 'गूंगा' घटक को जानकारी प्राप्त करने के लिए कुछ तरीके की आवश्यकता है)

प्रश्न 2: क्या होगा यदि 'स्मार्ट' ग्रैंड पेरेंट रेडक्स जैसी दुकान (हमारे लिए ngrx) से संचार कर रहा था? एक बार फिर 'गूंगा' घटकों के साथ संचार इंजेक्शन/समर्पित संदेश सेवा के माध्यम से सबसे अच्छा होता है या स्टोर को प्रत्येक 'गूंगा' घटक में इंजेक्ट करना सर्वोत्तम होता है ... या? नोट, अंतर-घटक संचार डेटा के अलावा 'क्रियाओं' (उदाहरण: फॉर्म सत्यापन, अक्षम बटन, आदि) का संयोजन है (यानी स्टोर या सेवा को अपडेट/अपडेट करें)।

विचारों की बहुत सराहना की!

Answer 1

तो सबसे अच्छा नीचे एक नेस्टेड घटक श्रृंखला संवाद और अप करने के लिए करने के लिए आगे इस की जांच कर रहे, जब यह आता है के बाद, वहाँ वास्तव में केवल दो विकल्प प्रतीत हो रहा है - के बीच एक Faustian सौदा:

• या तो पास @ इनपुट/आउटपुट @ बाइंडिंग ऊपर, नीचे, और नेस्टेड घटक श्रृंखला भर में

या

(यानी की समस्याओं 'कस्टम घटना बुदबुदाती' या 'बाहरी गुण' के साथ सौदा)
• घटकों के इस परिवार के बीच संवाद करने के लिए एक संदेश/सदस्यता सेवा का उपयोग करें (महान वर्णन here) और श्रृंखला में प्रत्येक घटक के लिए उस सेवा को इंजेक्ट करें।

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

यह देखते हुए, फ़ॉस्टियन सौदा, आईएमओ, आपके द्वारा लाए गए सभी उल्लिखित मुद्दों के साथ @ इनपुट/@ आउटपुट श्रृंखला का उपयोग करने की ओर झुकता है। उस ने कहा, मैं इस पर नजर रख रहा हूं और किसी को भी किसी के बारे में जानता है तो साफ और decoupled विकल्पों का स्वागत करते हैं।

Answer 2

# 1 विरोधी पैटर्न क्यों है? दादाजी घटक डेटा का मालिक है और इसे @ इनपुट पैरामीटर के माध्यम से बेवकूफ बाल घटकों तक भेज देता है। जब कोई घटना होती है तो गूंगा बच्चा घटक कॉलबैक का आह्वान करता है (@ ऑटपुट इवेंट उत्सर्जकों के माध्यम से), जिसके कारण दादाजी डेटा डेटा में हेरफेर कर सकता है। मुझे साफ लगता है।

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

// Parent component builds this object (or gets a service to do it) 

viewModelForChildComponent: { 

    property1NeededForChildComponent, 

    property2NeededForChildComponent, 

    viewModelForGrandChildComponent: { 
     property1NeededForGrandChildComponent, 

     property2NeededForGrandChildComponent, 

     viewModelForGrandGrandChildComponent: { 
      property1NeededForGrandGrandChildComponent, 

      submitHandlerNeededForGrandGrandChildComponent 
     } 
    } 
} 

Answer 3

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

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