Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Vue

Vue.js कॉम्पोनेंट के बीच कम्युनिकेशन के लिए डिजाइन पेटर्न

by
Difficulty:AdvancedLength:LongLanguages:

Hindi (हिंदी) translation by Ashish Rampal (you can also view the original English article)

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

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

प्रॉपर कॉम्पोनेंट्स कम्युनिकेशन महत्वपूर्ण क्यों है?

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

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

Vue.js कॉम्पोनेंट्स कम्युनिकेशन का ओवरव्यू

Vue.js में कॉम्पोनेंट्स के बीच दो मुख्य प्रकार के कम्युनिकेशन होते हैं:

  1. सीधे पैरंट-चाइल्ड कम्युनिकेशन, स्ट्रिक्ट पैरंट-टू-चाइल्ड और चाइल्ड-टू-पैरंट रिलेशन पर आधारित।
  2. क्रॉस कॉम्पोनेंट्स कम्युनिकेशन, जिसमें एक कॉम्पोनेंट अपने रिलेशन की परवाह किए बिना किसी अन्य से “बात” कर सकता है।

निम्नलिखित सेक्शन में, हम उपयुक्त उदाहरणों के साथ दोनों प्रकारों का पता लगाएंगे:

डायरेक्ट पैरंट-चाइल्ड कम्युनिकेशन

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

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

निम्नलिखित सेक्शन में, हम ऊपर दिए गए डायग्राम से कॉम्पोनेंट्स खोलेंगे और उन्हें प्रैक्टिकल उदाहरण की एक सीरीज में इंप्लीमेंट करेंगे।

पेरेंट-टू-चाइल्ड कम्युनिकेशन

यहाँ यह मान ले कि हमारे पास मौजूद कॉम्पोनेंट एक गेम का हिस्सा है। अधिकांश गेम अपने इंटरफ़ेस में कहीं ना कहीं गेम का स्कोर प्रदर्शित करती हैं। कल्पना करें कि हमारे पास Parent A कॉम्पोनेंट में score नामक एक वेरिएबल डिक्लेयर्ड है, और इसे Child A कॉम्पोनेंट में प्रदर्शित करना चाहते हैं। तो हम ऐसा कैसे कर सकते हैं?

पेरेंट्स से उनके चाइल्ड के लिए डाटा भेजने के लिए Vue.js props का प्रयोग करता है। एक प्रॉपर्टी को पास करने के लिए तीन आवश्यक कदम है:

  1. चाइल्ड में प्रॉपर्टी को रजिस्टर करना, कुछ इस प्रकार props:[“score”]
  2. चाइल्ड के टेंपलेट में रजिस्टर की गई प्रॉपर्टी का प्रयोग करना, कुछ इस प्रकार से <span>Score: {{ score }}</span>
  3. score वेरिएबल में प्रॉपर्टी कोबाइंड करना (पेरेंट के टेंपलेट में), कुछ इस प्रकार से <child-a :score=”score”/>

आइए वास्तव में क्या होता है, इससे बेहतर ढंग से समझने के लिए पूरा उदाहरण देखें:

CodePen से उदाहरण

प्रॉप्स को वैलिडेट करना

ब्रैविटी (brevity) और क्लेरिटी के लिए, मैंने उनके शॉर्ट हैंड वैरीअंट का उपयोग करके प्रॉप्स को रजिस्टर किया। लेकिन वास्तविक डेवलपमेंट के दौरान यह प्रॉप्स को वैलिडेट करना रिकमेंड किया जाता है। यह आश्वासन देगा कि प्रॉप को सही टाइप की वैल्यू प्राप्त होगी। उदाहरण के लिए, हमारी score प्रॉपर्टी इस तरह से वैलिडेट की जा सकती है:

प्रॉप्स का उपयोग करते समय, कृपया सुनिश्चित करें कि आप उनके लिटरल और डायनेमिक वैरीअंट के बीच के अंतर को समझते हैं। जब हम इसे किसी वेरिएबल (उदाहरण के लिए, v-bind:score=”score” या उसके शॉर्ट हैंड :score=”score”) पर बाइंड करते हैं, और इस प्रकार, परिवर्तन की वैल्यू वेरिएबल की वैल्यू के आधार पर अलग अलग होगी। यदि हम केवल बाइंड के बिना कुछ वैल्यू रखते हैं, तो उस वैल्यू की शाब्दिक व्याख्या की जाएगी और रिजल्ट स्टैटिक होगा। हमारे मामले में, अगर हम इसे score=”score” लिखते हैं, तो 100 के बजाय score प्रदर्शित करेगा। यह एक लिटरल प्रॉप है। आपको इस सूक्ष्म अंतर से सावधान रहना चाहिए।

एक चाइल्ड प्रोप को अपडेट करना

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

हमने एक changeScore() मेथड बनाया, जिसे Change Score बटन दबाने के बाद स्कोर अपडेट करना चाहिए। जब हम ऐसा करते हैं, तो ऐसा लगता है कि इसको ठीक से अपडेट किया गया है, लेकिन हमें कंसोल में निम्नलिखित चेतावनी दी गई होती है:

[Vue warn]: जब भी पैरंट कॉम्पोनेंट फिर से रेंडर करता है, तो वैल्यू को ओवरराइट कर दिया जाएगा तो सीधे एक प्रॉप को बदलने से बचें। इसके बजाय, प्रॉप की वैल्यू के आधार पर डाटा या कंप्यूट की गई प्रॉपर्टी का उपयोग करें, प्रोफ को म्यूटेट किया जा रहा है: “score”

जैसा कि आप देख सकते हैं, Vue हमें बताता है कि अगर पैरंट फिर से रेंडर होते हैं, तो प्रॉप ओवरराइट कर दिया जाएगा। आइए, इस व्यवहार को बिल्ट-इन $forceUpdate() मेथड से जोड़कर देखें:

CodePen से उदाहरण

अब, जब हम को बदलते हैं और फिर Rerender Parent बटन दबाते हैं, तो हम देख सकते हैं कि कोर पेरेंट्स ए अपने इनिशियल वैल्यू पर वापस जाता है। तो Vue सच कह रहा है!

हालांकि ध्यान रखें कि ऐरे और ऑब्जेक्ट अपने पैरंट्स को प्रभावित करेंगे, क्योंकि वे कॉपी नहीं किए गए हैं, लेकिन रेफरेंस द्वारा पास किए गए हैं।

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

एक लोकल डाटा प्रॉपर्टी के साथ प्रोफ को म्यूटेट करना

पहले तरीका है कि score प्रॉप को एक लोकल डाटा प्रॉपर्टी (localScore) में बदल दिया जाए, जिसका उपयोग changeScore() मैथर्ड और टेंप्लेट में किया जाता है:

CodePen से उदाहरण

अब, यदि हम को बदलने के बाद फिर से Rerender Parent बटन को दबाते हैं, तो हम देखेंगे कि इस बार स्कोर वही रहेगा।

एक कंप्यूटेड प्रॉपर्टी के साथ प्रॉप को म्यूटेट करना

दूसरा मेथड यह है कि कंप्यूट की गई प्रॉपर्टी में score प्रॉप का उपयोग करें, जहां इसे एक नई वैल्यू में बदल दिया जाएगा।

CodePen से उदाहरण

यहां, हमने कंप्यूटेड doubleScore() बनाया, जो पेरेंट्स के score को 2 से गुणा करता है और फिर, रिजल्ट को टेंप्लेट में प्रदर्शित करता है। जाहिर है, Rerender Parent बटन से कोई साइड इफेक्ट नहीं होगा।

चाइल्ड-टू-पैरंट कम्युनिकेशन

अब, आइए देखें कि कॉम्पोनेंट विपरीत तरीके से कैसे कम्युनिकेट कर सकते हैं।

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

यहां प्रिंसिपल यह है कि हम उस बदलाव के लिए पैरंट को नोटिफाई करते हैं जो हम करना चाहते हैं, पैरंट उस परिवर्तन को करते हैं, और यह परिवर्तन पास किए गए प्रॉप के माध्यम से रिफ्लेक्ट होता है। इस ऑपरेशन के लिए आवश्यक कदम इस प्रकार हैं:

  1. चाइल्ड में, हम एक इवेंट को एमिट करते हैं जो उस परिवर्तन को डिस्क्राइब करता है जिसे हम परफॉर्म करना चाहते हैं, कुछ इस प्रकार से this.$emit(‘updatingScore’, 200)
  2. पैरंट में, हम एमिटेड इवेंट के लिए एक इवेंट लिस्टनर को रजिस्टर करते हैं, कुछ इस तरह @updatingScore=”updateScore”
  3. जब इवेंट को एमिट किया जाता है, तो असाइन किया गया तरीका प्रॉप को अपडेट करेगा, कुछ इस प्रकार से this.score = newValue

आइए बेहतर तरीके से समझने के लिए कि यह कैसा होता है इस पूरे उदाहरण को एक्सप्लोर करें:

CodePen से उदाहरण

हम एक इवेंट को एमिट करने के लिए बेल्ट-इन $emit() मेथड का उपयोग करते हैं। यह मेथड दो अरगुमेंट्स को लेता है। पहला अरगुमेंट वह इवेंट होता है जिसे हम एमिट करना चाहते हैं, और दूसरा नई वैल्यू होता है।

.sync मोडीफायर

Vue एक .sync मोडीफायर प्रदान करता है जो उसी प्रकार से काम करता है और कुछ मामलों में हम शॉर्टकट के रूप में इसका उपयोग करना चाहते हैं। ऐसे मामले में, हम $emit() मेथड का थोड़ा अलग तरीके से उपयोग करते हैं। इवेंट अरगुमेंट के रूप में हम update:score को डालते हैं कुछ इस प्रकार से this.$emit(‘update:score’, 200), और फिर, जब हम score प्रॉप को बाइंड करते हैं, तो हम .sync मॉडिफाइड को जोड़ते हैं कुछ इस प्रकार से <child-a :score.sync=”score”/>Parent A कॉम्पोनेंट में, हम updateScore() मेथड और इवेंट रजिस्ट्रेशन (@updatingScore=”updateScore”) को हटा देते हैं क्योंकि हमें अब और इनकी आवश्यकता नहीं है।

CodePen से उदाहरण

क्यों नहीं this.$parent और this.children का प्रयोग डायरेक्ट पैरंट-चाइल्ड कम्युनिकेशन के लिए करते?

Vue दो API मेथड्स प्रदान करता है जो हमें पैरंट और चाइल्ड के कॉम्पोनेंट्स तक सीधे एक्सेस प्रदान करता है: this.$parent और this.$children। सबसे पहले यह उन्हें प्रॉप्स और इवेंट्स के एक तेज और आसान अल्टरनेट के रूप में इस्तेमाल करने के लिए निभा सकता है, लेकिन हमें ऐसा नहीं करना चाहिए। यह एक बुरा अभ्यास या एंटी-पैटर्न माना जाता है, क्योंकि यह पैरंट और चाइल्ड के कॉम्पोनेंट्स के बीच टाइट कपलिंग बनाता है। लेटर इनफ्लेक्सिबल और कॉम्पोनेंट्स को तोड़ने के लिए आसान होता है, जो कि डिबग करना कठिन होता है और इसका कारण होता है। इन API मेथड का उपयोग शायद ही कभी किया जाता है, और थंब ऑफ रूल के रूप में, हमें उनसे बचना चाहिए या सावधानी के साथ उनका उपयोग करना चाहिए।

टू-वे कंपोनेंट कम्युनिकेशन

प्रॉप्स और इवेंट्स यूनिडायरेक्शनल है। प्रॉप्स नीचे जाता है, इवेंट ऊपर जाते हैं। लेकिन एक साथ प्रॉप्स और इवेंट्स का उपयोग करके, हम कॉम्पोनेंट ट्री को प्रभावी ढंग से ऊपर और नीचे कम्युनिकेट कर सकते हैं, जिसके परिणाम स्वरूप दो तरफा डाटा बाइंडिंग होता है। यह वास्तव में वही है जो v-model डायरेक्टिव्स आंतरिक रुप से करता है।

क्रॉस-कॉम्पोनेंट्स कम्युनिकेशन

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

आइए नीचे दिए गए डायग्राम पर एक नजर डालें:

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

निम्नलिखित सेक्शंस में, हम क्रॉस-कॉम्पोनेंट्स कम्युनिकेशन के सबसे सामान्य इंप्लीमेंटेशन का पता लगाएंगे।

ग्लोबल इवेंट बस

एक ग्लोबल इवेंट बस Vue का एक इंस्टेंस है, जिसका उपयोग हम इवेंट्स के लिए एमिट करने और सुनने के लिए करते हैं। आइए इसे प्रैक्टिस में देखें।

CodePen से उदाहरण

यहां एक इवेंट बस बनाने और उसका उपयोग करने के स्टेप्स दिए गए हैं:

  1. हमारे इवेंट बस को एक नए Vue इंस्टेंस के रूप में डिक्लेअर करना, कुछ इस प्रकार से const eventBus = new Vue ()
  2. सोर्स कॉम्पोनेंट से इवेंट इवेंट को एमिट करना, कुछ इस प्रकार से eventBus.$emit(‘updatingScore’, 200)
  3. टारगेट कॉम्पोनेंट में एमिट इवेंट को सुनना, कुछ इस प्रकार से eventBus.$on(‘updatingScore’, this.updateScore)

ऊपर दिए कोड के उदाहरण में, हम चाइल्ड से @updatingScore=”updateScore” को हटाते हैं, और हम इसके बदले created() लाइफसाइकिल हुक का प्रयोग करते हैं, ताकि हम updatingScore इवेंट को सुन सके। जब इवेंट एमिट किया जाता है, updateScore() मेथड एक्जिक्यूट किया जाएगा। हम अपडेट करने वाले मेथड को एक एनोनिमस फंक्शन की तरह भी पास कर सकते हैं।

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

Vuex

Vuex एक स्टेट मैनेजमेंट लाइब्रेरी है जो मुश्किल और स्केलेबल Vue.js एप्लीकेशंस के निर्माण के लिए बनाई गई है। Vuex के साथ लिखे कोड अधिक वरबोस (verbose) हैं, लेकिन यह लंबे समय में भुगतान कर सकते हैं। यह एक एप्लीकेशन में सभी कॉम्पोनेंट्स के लिए एक सेंट्रलाइज्ड स्टोर का उपयोग करता है, जिससे हमारे एप्स अधिक संगठित, पारदर्शी और ट्रैक करने में और डिबग करने में आसान होते हैं। तो पूरी तरह से रिएक्टिव है, इसलिए हम जो बदलाव करते हैं वह तुरंत रिफ्लेक्ट होता है।

यहां, मैं आपको एक संक्षिप्त विवरण देता हूं कि Vuex क्या है, साथ ही एक प्रासंगिक (contextual) उदाहरण भी। यदि आप Vuex में और गहराई में जाना चाहते हैं, तो मेरा सुझाव है कि आप Vuex के मुश्किल एप्लीकेशन के निर्माण के बारे में मेरे डेडीकेटेड ट्यूटोरियल पर एक नजर डालें

आइए अब निम्नलिखित डायग्राम को एक्सप्लोर करें:

जैसा कि आप देख सकते हैं, एक Vuex ऐप चार विशिष्ट भागों से बनी है:

  • State वह जगह है जहां हम अपनी एप्लीकेशन का डाटा रखते हैं।
  • Getters स्टोर किये गए स्टेट को एक्सेस करने वाले मेथड्स है और यह इन्हें कॉम्पोनेंट्स में रेंडर करता है।
  • Mutations वास्तविक और सिर्फ इकलौते मेथड है जिन्हें स्टेट को बदलने की अनुमति है।
  • Actions एसिंक्रोनस कोड को एग्जीक्यूट करने वाले मेथड्स हैं और यह म्यूटेशन को ट्रिगर करते हैं।

आइए एक सिंपल सा स्टोर बनाते हैं और देखते हैं कि यह सब कुछ एक्शन में कैसे कार्य करते है।

CodePen से उदाहरण

स्टोर में, हमारे पास निम्नलिखित है:

  • एक score वेरिएबल जो स्टेट ऑब्जेक्ट में सेट है।
  • एक incrementScore() म्यूटेशन, जो दी गई वैल्यू के साथ स्कोर को बढ़ाएगा।
  • एक score() गेटर, जो स्टेट से score वेरिएबल में एक्सेस करेगा और इसे कॉम्पोनेंट्स में रेंडर करेगा।
  • एक incrementScoreAsync() एक्शन, जो incrementScore() म्यूटेशन का प्रयोग स्कोर को दिए गए समय के बाद बढ़ाने के लिए करेगा।

Vue के इंस्टेंस में, प्रॉप्स के बजाय हम कंप्यूटेड प्रॉपर्टीज का उपयोग करते हैं ताकि हम स्कोर वैल्यू को गेटर के माध्यम से प्राप्त कर सकें। इसके बाद, स्कोर को बदलने के लिए, Child A कॉम्पोनेंट में हम store.commit(‘incrementScore’, 100) म्यूटेशन का प्रयोग करते हैं। Parent B कॉम्पोनेंट में हम एक्शन store.dispatch(‘incrementScoreAsync’, 3000) का उपयोग करते हैं।

डिपेंडेंसी इंजेक्शन

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

डिपेंडेंसी इंजेक्शन हमें provide प्रॉपर्टी के माध्यम से एक सर्विस को परिभाषित करने की अनुमति देता है, जो एक ऑब्जेक्ट या एक फंक्शन होना चाहिए जोकि ऑब्जेक्ट को रिटर्न करता है, और इसे कॉम्पोनेंट के सभी वंशज (descendant) को उपलब्ध कराता है, ना कि केवल इसके डायरेक्ट चिल्ड्रन को। फिर, हम उस सर्विस को inject प्रॉपर्टी के माध्यम से कंज्यूम कर सकते हैं।

आइए इसे एक्शन में देखें:

CodePen से उदाहरण

Grand Parent कॉम्पोनेंट में provide ऑप्शन का उपयोग करके, हमने score वेरिएबल को इसके सभी वंशजो के लिए उपलब्ध कराया। उनमें से हर एक को inject:[‘score’] डिक्लेयर करके इसकी पहुंच प्राप्त होती है। और, जैसा कि आप देख सकते हैं, को सभी कॉम्पोनेंट्स में प्रदर्शित किया जाता है।

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

क्रॉस-कॉम्पोनेंट्स के लिए this.$root का प्रयोग क्यों ना करें?

this.$root का प्रयोग ना करने के पीछे का कारण उसी के समान है जिसके लिए this.$parent और this.children मैं पहले बताया गया है-यह बहुत अधिक डिपेंडेंसीज विश्वास पैदा करता है। कॉम्पोनेंट कम्युनिकेशन के लिए इनमें से किसी भी तरीके पर भरोसा करने से बचना चाहिए।

सही पैटर्न कैसे चुने?

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

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

  • simple apps में प्रॉप्स और इवेंट्स आपकी जरूरत के अनुसार होंगे।
  • Middle-range apps को कम्युनिकेशन के अधिक फ्लैक्सिबल तरीकों की आवश्यकता होगी, जैसे कि इवेंट बस और डिपेंडेंसी इंजेक्शन।
  • complex, large-scale apps के लिए आपको निश्चित रूप से फुल-फीचर्ड स्टेट मैनेजमेंट सिस्टम के रूप में Vuex की शक्ति की आवश्यकता होगी।

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

निष्कर्ष

इस ट्यूटोरियल में। हमने सबसे सामान्य Vue.js कॉम्पोनेंट कम्युनिकेशन पैटर्न सीखा। हमने देखा कि उन्हें प्रैक्टिस में कैसे इंप्लीमेंट किया जाए और सही वाले को कैसे चुना जाए, जो हमारे प्रोजेक्ट के लिए सबसे उपयुक्त हो। यह सुनिश्चित करेगा कि हमने जो ऐप बनाया है, वह उचित प्रकार के कॉम्पोनेंट्स के कम्युनिकेशन का उपयोग करता है जो इसे पूरी तरह से काम करने योग्य, टेस्ट करने योग्य और स्केलेबल बनाता है।

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.