Vue: async घटक जीवनचक्र हुक की प्रतीक्षा करें

इसलिए आप यह चाहते हैं

created () {
    return new Promise(resolve => {
        setTimeout(() => {
            console.log('created')
            resolve()
        })
    })
},
mounted () {
    console.log('mounted')
}

प्रदर्शित करने के लिए

mounted

?

सुविधा अनुरोध बनाते समय, अनुरोध को क्रियान्वित करने योग्य बनाने के लिए कृपया एक वास्तविक-विश्व उपयोग का मामला जोड़ें।

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

अभी के लिए बंद, लेकिन अधिक ठोस तर्क/उपयोग के मामलों/निहितार्थों के साथ अनुवर्ती कार्रवाई करने के लिए स्वतंत्र महसूस करें।

@posva समझ गया - मैं क्षमा चाहता हूँ। मेरे वास्तविक उपयोग के मामले में से एक है जहां मैं एक है UserPage घटक है कि एक प्राप्त करता है user_id (के माध्यम से पेज मार्ग मापदंडों से this.$route.params ), तो डेटाबेस से वास्तविक उपयोगकर्ता डेटा को हासिल करेगा जैसे कमांड का उपयोग कर सर्वर पर:
this.user = await client.get({type: 'user', id: this.$route.params.id})
जहां this.user UserPage घटक के data भाग में user फ़ील्ड को संदर्भित करता है।

आदर्श रूप से, मैं चाहता हूं कि घटक बनने के बाद कोड की उस पंक्ति को निष्पादित किया जाए (ताकि this.$route.params उपलब्ध हो) लेकिन इससे पहले कि घटक वास्तव में आरोहित हो ताकि मेरे टेम्पलेट में मैं सुरक्षित रूप से user उपयोग कर सकूं अपरिभाषित मूल्यों के बारे में कोई त्रुटि प्राप्त किए बिना

@yyx990803
मैं यहां एक नोब हो सकता हूं, लेकिन क्या Vue भूमि में जीवनचक्र हुक जैसे mounted , आदि के लिए कॉल से पहले await कीवर्ड जोड़ना एकमात्र परिवर्तन नहीं होना चाहिए?

यह वास्तविक कोड है जिसका मैं इंतजार करना चाहता हूं:

  beforeMount: async function() {
       this.user = await client.get({type: 'user', id: this.$route.params.id});
    }

जो UserPage घटक का हिस्सा होगा।

कोई चिंता नहीं! मैं उस उपयोग के मामले की कल्पना कर रहा था। इसे संभालना बेहतर है जैसा कि vue-router डॉक्स में वर्णित है क्योंकि यह लोडिंग स्थिति प्रदर्शित करने के विभिन्न तरीकों को खोलता है। घटक बीटीडब्ल्यू को प्रस्तुत करने से पहले आप डेटा के वहां होने की प्रतीक्षा कर सकते हैं।

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

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

आपके पास इसे करने के कई तरीके हैं। सबसे सरल एक वेरिएबल का उपयोग कर रहा है जो शून्य के रूप में शुरू होता है, डेटा प्राप्त करता है और इसे सेट करता है, वास्तविक घटक को टॉगल करता है (v-if की वजह से)। एक अधिक आकर्षक संस्करण एक ऐसा फ़ंक्शन होगा जो घटक को हल करता है और <component :is="myDynamicComp"/> उपयोग करता है
लेकिन कृपया, इस मुद्दे को किसी प्रश्न के रूप में हाईजैक न करें 😉 उसके लिए फ़ोरम या कलह का उपयोग करें

नहीं, मैं वास्तव में कोड के साथ मदद नहीं चाहता! असल में मैं पहले से ही समाधान बहुत अपने सुझाव के लिए इसी तरह लागू किया है। मैं जो कहना चाह रहा हूं वह यह है कि केवल JS async सुविधाओं का उपयोग करना अधिक सहज है।

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

मेरे पास यहां कुछ उपयोग का मामला है और मैं कुछ सुझाव और कामकाज विधि प्राप्त करना चाहता हूं।

MainPage.vue मेरा मुख्य कंटेनर है। मैं उपयोगकर्ता जानकारी प्राप्त करने के लिए beforeCreate पर AJAX "/init" को कॉल करता हूं और फिर Vuex.store को प्रतिबद्ध करता हूं।
Content.vue अंदर का बच्चा है MainPage.vue । मैं उपयोगकर्ता की भूमिका के अनुसार mounted स्टेज पर अलग-अलग एपीआई कॉल करना चाहता हूं जो Vuex.store से आती हैं।

यदि जीवनचक्र async/प्रतीक्षा प्रवाह में कॉल करता है, तो यह आदेश का पालन करेगा
पेरेंट बिफोरक्रिएट -> पेरेंट क्रिएट -> चाइल्ड बिफोर क्रिएट -> चाइल्ड क्रिएट -> चाइल्ड माउंटेड .... (अगर मैं कंपोनेंट लाइफसाइकल के बारे में सही ढंग से समझूं)।

लेकिन वर्तमान में मुझे Content.vue पर उपयोगकर्ता की जानकारी नहीं मिल रही है, अब मैं वर्कअराउंड कैसे प्राप्त कर सकता हूं?
मैं "/ init" एपीआई को MainPage.vue अंदर रखना चाहता हूं क्योंकि इसका उपयोग कई पृष्ठों (वू-राउटर में कंटेनर) में किया जाता है।

स्टैक ओवरफ्लो पर प्रश्न पोस्ट किया गया

धन्यवाद

जो लायक है उसके लिए एक हैकिश वर्कअराउंड:

{
  created: function(){
    this.waitData = asyncCall();
  },
  mounted: function(){
    this.waitData.then(function(data) { ... })
  }
}

एक संभावित अधिक "फ्लैट" समाधान:

{
    async created () {
        let createdResolve = null
        let createdReject = null
        this.createdPromise = new Promise(function(resolve, reject){
            createdResolve = resolve
            createdReject = reject
        })
        await asyncCall1()
        await asyncCall2()
        ...
        createdResolve(someResult)
    }
    async mounted () {
        let result = await this.createdPromise
        ...
    }
    data () {
        return {
            createdPromise: null
        }
    }
}

क्या यह अभी बात नहीं है?

data() {
 ...
},
async created() {
  const something = await exampleMethod();
  console.log(something);
}

मेरे लिए काम कर रहा है (जैसा कि @fifman उल्लेख करता है)।

@breadams हाँ, बिल्कुल। फ़ंक्शन _inside_ created विधि की प्रतीक्षा की जाएगी - हालांकि created या mounted फ़ंक्शन स्वयं नहीं है।

तो Vue उदाहरण कॉल करेंगे created और तुरंत mounted में लंबे चल प्रक्रियाओं का कोई भी पहले created कार्य पूरा हो जाएगा

आह , मेरा बुरा @ डैरेन-देव - मेरी तरफ से अलग-अलग उपयोग के मामले, लेकिन मैं अब इस मुद्दे को देखता हूं स्पष्टीकरण के लिए धन्यवाद।

@breadadams कोई समस्या नहीं - हम सब यहाँ अपने मामलों के लिए हैं, खुशी है कि मैं स्पष्ट कर सकता हूँ!

अगले प्रमुख संस्करण में Async जीवनचक्र हुक एक अच्छा कार्यान्वयन हो सकता है

मुझे लगता है कि जीवनचक्र विधियों के लिए async समर्थन की अनुमति देना डिफ़ॉल्ट रूप से खराब UX प्रथाओं को प्रोत्साहित करेगा। कैसे? Async फ़ंक्शंस का उपयोग उन अनुरोधों के लिए किया जाता है जिन्हें तुरंत पूरा नहीं किया जा सकता (उदाहरण के लिए लंबे समय तक चलने वाला या नेटवर्क अनुरोध)। Vue को आपके नेटवर्क अनुरोध या लंबे समय तक चलने वाली एसिंक्रोनस प्रक्रिया पर प्रतीक्षा करने के लिए निर्माण या माउंटिंग या किसी अन्य जीवनचक्र विधियों में देरी करने के लिए मजबूर करना उपयोगकर्ता को ध्यान देने योग्य तरीकों से प्रभावित करेगा। कल्पना कीजिए कि एक उपयोगकर्ता आपकी साइट पर आ रहा है और फिर एक खाली स्क्रीन के साथ 4 सेकंड तक इंतजार करना पड़ता है, जबकि घटक आपके नेटवर्क अनुरोध को पूरा करने के लिए उपयोगकर्ता के स्पॉटी सेल कनेक्शन की प्रतीक्षा करता है। और यह न केवल उपयोगकर्ता को नकारात्मक रूप से प्रभावित करता है, बल्कि आप स्थिति पर अपने नियंत्रण का त्याग भी कर रहे हैं - ऐसा कुछ भी नहीं है जो आप एक डेवलपर के रूप में कर सकते हैं ताकि उपयोगकर्ताओं को लोड समय को जल्दी समझा जा सके, या निर्धारित या अनिश्चित प्रगति संकेतक दिखा सकें। तो इस क्षमता को Vue में बनाकर आप वेब को एक बेहतर जगह नहीं बना रहे हैं; आप खराब प्रथाओं को सक्षम कर रहे हैं।

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

@seanfisher आप एक वैध बिंदु उठाते हैं। वास्तुकला की दृष्टि से, घटनाओं के एक अतुल्यकालिक सेट के आसपास डिजाइनिंग को डेवलपर द्वारा नियंत्रित किया जाना चाहिए - क्योंकि संदेश को सही ढंग से चित्रित करने का यही एकमात्र तरीका है।

अस्वीकरण : निम्नलिखित पृष्ठ निर्माण के विचार को ध्यान में रखकर लिखा गया है। निश्चित रूप से वैध उपयोग-मामले हैं जहां मेरा तर्क अमान्य है।

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

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

याद रखें, मेरा तर्क यह है कि Vue को मुझे यह नहीं बताना चाहिए कि मैं गलत विकास कर रहा हूँ। इसे केवल वांछित कार्यक्षमता प्रदान करनी चाहिए।

हालाँकि, किसी डेवलपर के डिज़ाइन पैटर्न को निर्धारित करना आपके द्वारा उपयोग किए जा रहे ढांचे तक नहीं छोड़ा जाना चाहिए।

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

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

स्कॉट

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

लेकिन आपने बनाई और माउंट की गई घटनाओं को एसिंक्स बनाने के _actual_ तर्क पर छुआ नहीं है - आपने मेरी राय पर अपनी राय (जो गलत नहीं है) जोड़ दी है, जो आम तौर पर एक बड़ी पटरी से उतरती है।

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

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

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

स्कॉट

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

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

इस राय के लिए कि उपयोगकर्ता को async created या अन्य जीवनचक्र हुक के लिए एक संकेतक के बिना प्रतीक्षा करने के लिए यह एक बुरा अभ्यास है कि कुछ हो रहा है, तर्क दिया जा सकता है कि Vue, async हुक का समर्थन करता है, अब हो सकता है कुछ ऐसा प्रदान करता है जिसे "फेज टेम्प्लेट" कहा जा सकता है जो समस्या को भी हल करेगा (और जिसे लागू करना आसान हो सकता है)।

इस राय के लिए कि उपयोगकर्ता को एक एसिंक निर्मित या अन्य जीवनचक्र हुक की प्रतीक्षा करने के लिए एक संकेतक के बिना यह एक बुरा अभ्यास है कि कुछ हो रहा है,

क्या यह वास्तव में समस्या भी है?

स्कॉट

यहां मेरी समस्या है - और शायद कोई सुझाव दे सकता है कि मुझे यह कैसे करना चाहिए क्योंकि यह समस्याग्रस्त प्रतीत होता है।

हमारा Vue एप्लिकेशन (बल्कि बड़ा) Vuex का व्यापक रूप से उपयोग करता है। create() जीवनचक्र में हमारे कुछ Vue घटकों में हम store.dispatch() के माध्यम से स्टोर में कुछ आइटम सेट करते हैं (जाहिर है)। हालांकि, जैसा कि मेरे ध्यान में आया है - store.dispatch() हमेशा एक वादा देता है .. भले ही अंतर्निहित तर्क और कार्य async नहीं है। इसलिए मैंने async create() {प्रतीक्षा store.dispatch('foo/action') } डाल दिया, लेकिन जैसा कि ध्यान दिया गया है कि वास्तव में विफल रहता है ..

मैं टाइपस्क्रिप्ट का भी उपयोग कर रहा हूं और जब मैं प्रतीक्षा नहीं करता / तो यह कड़वाहट से शिकायत करता है। फिर store.dispatch() कॉल .. "फ्लोटिंग" वादे वाले ..

तो जीवनचक्र में Vuex store.dispatch() का उपयोग करने का सबसे अच्छा तरीका क्या है जब हम उन्हें async नहीं कर सकते हैं?

चीयर्स !!

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

मैं ऊपर @fifman के "अधिक फ्लैट" समाधान को देख रहा हूं, और मुझे यकीन नहीं है कि यह मेरे लिए समस्या हल करता है, जो यह सुनिश्चित कर रहा है कि मैंने mounted() रिटर्न के समय तक अपना एक्सएचआर लोड कर लिया है। उस समाधान में, created() और mounted() दोनों ही async हैं, इसलिए Vue उनमें से प्रत्येक को कॉल करेगा और वे कमोबेश तुरंत वापस आ जाएंगे, जिसमें async सामग्री पृष्ठभूमि में चल रही होगी। वास्तव में मुझे यकीन नहीं है कि यह सिर्फ createdPromise को खत्म करने और created() या mounted() में से सभी async काम करने से बेहतर कैसे है, जैसे:

async mounted() {
  let response = await fetch(my_url)
  let data = await response.text()
  my_data_member = data
}

किसी भी मामले में, my_data_member "बाद में" भर जाएगा जब एक्सएचआर पूरा हो जाता है, लंबे समय बाद mounted() अपना वादा वापस कर देता है, है ना?

आप रूट घटक <div id="app"/> पर v-if का उपयोग करने का भी प्रयास कर सकते हैं और जब आपका डेटा लोड हो रहा हो तो इसे ट्रिगर कर सकते हैं। उदाहरण के लिए, मैं इसे रीफ्रेश टोकन के लिए उपयोग करता हूं।

यह बहुत सारे उपयोग के मामलों के लिए एक अच्छी सुविधा है। मेरे उपयोगकेस के लिए मुझे घटक के वास्तविक रेंडर से पहले विशिष्ट एपीआई गुणों को लोड करने की आवश्यकता है। हालाँकि, मुझे नहीं लगता कि जीवन चक्र हुक में async एक आदर्श समाधान है।

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

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

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

@cederron विशुद्ध रूप से ब्याज से बाहर, आप मूल घटक में डेटा डाउनलोड क्यों नहीं कर सकते हैं और इसे एक प्रोप के रूप में पास कर सकते हैं? डेटा लोड होने पर लोडिंग संकेतक दिखाने के लिए v-if का उपयोग करें और जब डेटा दिखाई देता है, तो आप घटक दिखा सकते हैं, और जब इसे बनाया जाता है, तो इसमें आवश्यक सभी डेटा होगा।

घटक के दो अलग-अलग असंबंधित राज्यों का प्रतिनिधित्व करने से बचा जाता है ('कोई डेटा लोड नहीं, प्रतीक्षा' और 'डेटा लोड किया गया है, आप इसे हेरफेर कर सकते हैं')

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

@ReinisV मुझे लगता है कि मैंने अपने मामले को बहुत सरल कर दिया है, घटक मिक्सिन माउंटेड हुक द्वारा प्राप्त डेटा से नया डेटा बनाता है, और घटक दृश्य इस नए डेटा से जुड़ा होता है।
इसलिए, मिक्सिन को डेटाबेस से डेटा प्राप्त करना होता है > घटक इससे डेटा बनाता है > अब घटक दिखाया गया है

AFAIK यह काम नहीं करेगा:

export const MyMixin = {
    data: function () {
        return {
            dbData: null
        }
    },
   mounted:  async function () {
      this.dbData = await asyncFetchDataFromDB()
   }
}


export const MyComponent = {
    mixins: [MyMixin],
    data: function () {
        return {
            newData: null
        }
    },
   mounted:  function () {
      this.newData = handleDBData(this.dbData)
   }
}

घटक माउंट हुक में dbData शून्य हो जाएगा।

वर्तमान में जब मैं मिश्रण डेटा प्राप्त करता हूं तो मैं कॉलबैक निष्पादित करता हूं लेकिन माउंट फ़ंक्शन को एसिंक बनाने के लिए सुंदर होगा।

vuex के बारे में ज्यादा कुछ नहीं कह सकता क्योंकि मैं इसका उपयोग नहीं कर रहा हूँ

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

लेकिन मैं वास्तव में निराश होऊंगा कि मेरे हर एक जीवनचक्र के हुक को अवरुद्ध करने से बचने के लिए फिर से लिखा जाए, async/await बहुत साफ है, इसलिए हम वादों का उपयोग नहीं करते हैं। इसे गैर-पिछड़े संगत तरीके से बदलने से विफलता के गड्ढे के लिए सफलता का गड्ढा (अप्रतीक्षित घटक जीवनचक्र) बदल जाता है।

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

@seanfisher धन्यवाद, यह बहुत मददगार है!

इसके बजाय एक एसिंक्रोनस घटक का उपयोग क्यों नहीं किया जाता है, जिसे केवल तभी प्रस्तुत किया जाएगा जब एसिंक्रोनस कॉल वापस आ जाएंगे?
एपीआई पर अधिक जानकारी यहाँ
https://vuejs.org/v2/guide/components-dynamic-async.html#Async -Components

new Vue({
  components: {
    root: () => ({ // Aync component
      // The component to load (should be a Promise)
      component: new Promise(async function (resolve) {
        await FetchMyVariables()
        resolve(MyComponent) // MyComponent will be rendered only when FetchMyVariables has returned
      }),
      // A component to use while the async component is loading
      loading: { render: (h) => h('div', 'loading') }, 
    })
  },
  render: h => h('root')
})

जबकि इनमें से अधिकांश समाधान ठीक लगते हैं, मुझे लगता है कि यह Vue के उन प्रमुख लापता टुकड़ों में से एक है जो इसे इतना सहज बनाते हैं। मुझे लगता है कि Vue 3 को इसे लागू करने की आवश्यकता है क्योंकि हम उस बिंदु पर आ गए हैं जहां async Wait का उपयोग करना अब एक रोजमर्रा की बात है। तो कृपया @ yyx990803 आप, इसे Vue 3 में रखते हैं। PLEEEEEEEASE। पूरा VUE आर्किटेक्चर इन मामलों की धारणा के बिना बनाया गया था और ज्यादातर चीजें जो लोग यहां पोस्ट कर रहे हैं, वे सिर्फ वर्कअराउंड और हैकिश हैं। मुझे लगता है कि हुक को वास्तव में एसिंक फ़ंक्शंस का सम्मान करना चाहिए और वापसी मूल्यों की भी अपेक्षा करनी चाहिए जो कि अगले हुक फ़ंक्शन पर पास हो जाएं।

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

मुझे लगता है कि जीवनचक्र विधियों के लिए async समर्थन की अनुमति देना डिफ़ॉल्ट रूप से खराब UX प्रथाओं को प्रोत्साहित करेगा। कैसे? Async फ़ंक्शंस का उपयोग उन अनुरोधों के लिए किया जाता है जिन्हें तुरंत पूरा नहीं किया जा सकता (उदाहरण के लिए लंबे समय तक चलने वाला या नेटवर्क अनुरोध)। Vue को आपके नेटवर्क अनुरोध या लंबे समय तक चलने वाली एसिंक्रोनस प्रक्रिया पर प्रतीक्षा करने के लिए निर्माण या माउंटिंग या किसी अन्य जीवनचक्र विधियों में देरी करने के लिए मजबूर करना उपयोगकर्ता को ध्यान देने योग्य तरीकों से प्रभावित करेगा। कल्पना कीजिए कि एक उपयोगकर्ता आपकी साइट पर आ रहा है और फिर एक खाली स्क्रीन के साथ 4 सेकंड तक इंतजार करना पड़ता है, जबकि घटक आपके नेटवर्क अनुरोध को पूरा करने के लिए उपयोगकर्ता के स्पॉटी सेल कनेक्शन की प्रतीक्षा करता है। और यह न केवल उपयोगकर्ता को नकारात्मक रूप से प्रभावित करता है, बल्कि आप स्थिति पर अपने नियंत्रण का त्याग भी कर रहे हैं - ऐसा कुछ भी नहीं है जो आप एक डेवलपर के रूप में कर सकते हैं ताकि उपयोगकर्ताओं को लोड समय को जल्दी समझा जा सके, या निर्धारित या अनिश्चित प्रगति संकेतक दिखा सकें। तो इस क्षमता को Vue में बनाकर आप वेब को एक बेहतर जगह नहीं बना रहे हैं; आप खराब प्रथाओं को सक्षम कर रहे हैं।

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

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

यदि कोई ढांचा डेवलपर से लड़ता है तो डेवलपर को दूसरा ढांचा मिल जाएगा।

@robob4him

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

यदि कोई ढांचा डेवलपर से लड़ता है तो डेवलपर को दूसरा ढांचा मिल जाएगा

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

@wparad , यह बिल्कुल डराने वाली रणनीति है, लेकिन यह किसी को कुछ भी करने के लिए मजबूर नहीं करने वाला है। तर्क देना कि एक विशेषता बुरी आदतों या विरोधी पैटर्न का समर्थन करती है या डेवलपर्स के बड़े समुदाय को नष्ट कर देगी, उतनी ही डरावनी रणनीति है।

वस्तुतः किसी भी ढांचे/भाषा की आधी विशेषताएं एक डेवलपर के लिए खतरनाक होती हैं; सार्वजनिक तरीकों को बढ़ाया जा सकता है, Vue तत्व ($ el), आदि तक पहुंच को प्रोत्साहित करता है। फ्रेमवर्क ये चीजें प्रदान करते हैं क्योंकि दिन के अंत में डेवलपर को काम पूरा करने की आवश्यकता होती है।

यह सुविधा अनुरोध एक वर्ष पुराना है। लोगों को समझना चाहिए कि इसका कारण वास्तव में यह नहीं है कि इससे बुरे व्यवहार होंगे और न ही उन्हें देरी से प्रतिपादन को एक बुरा अभ्यास समझना चाहिए।

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

मुझे लगता है कि जीवनचक्र विधियों के लिए async समर्थन की अनुमति देना डिफ़ॉल्ट रूप से खराब UX प्रथाओं को प्रोत्साहित करेगा। कैसे? Async फ़ंक्शंस का उपयोग उन अनुरोधों के लिए किया जाता है जिन्हें तुरंत पूरा नहीं किया जा सकता (उदाहरण के लिए लंबे समय तक चलने वाला या नेटवर्क अनुरोध)। Vue को आपके नेटवर्क अनुरोध या लंबे समय तक चलने वाली एसिंक्रोनस प्रक्रिया पर प्रतीक्षा करने के लिए निर्माण या माउंटिंग या किसी अन्य जीवनचक्र विधियों में देरी करने के लिए मजबूर करना उपयोगकर्ता को ध्यान देने योग्य तरीकों से प्रभावित करेगा। कल्पना कीजिए कि एक उपयोगकर्ता आपकी साइट पर आ रहा है और फिर एक खाली स्क्रीन के साथ 4 सेकंड तक इंतजार करना पड़ता है, जबकि घटक आपके नेटवर्क अनुरोध को पूरा करने के लिए उपयोगकर्ता के स्पॉटी सेल कनेक्शन की प्रतीक्षा करता है। और यह न केवल उपयोगकर्ता को नकारात्मक रूप से प्रभावित करता है, बल्कि आप स्थिति पर अपने नियंत्रण का त्याग भी कर रहे हैं - ऐसा कुछ भी नहीं है जो आप एक डेवलपर के रूप में कर सकते हैं ताकि उपयोगकर्ताओं को लोड समय को जल्दी समझा जा सके, या निर्धारित या अनिश्चित प्रगति संकेतक दिखा सकें। तो इस क्षमता को Vue में बनाकर आप वेब को एक बेहतर जगह नहीं बना रहे हैं; आप खराब प्रथाओं को सक्षम कर रहे हैं।

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

आप जो कह रहे हैं वह यह है कि v-if/v-clock/v-show सुविधाओं को जोड़ने से खराब प्रथाओं को बढ़ावा मिलेगा इसलिए हम उन सुविधाओं को हटाकर ढांचे को बेहतर तरीके से साबित करते हैं। फिर ऐसा करने के लिए कुछ जटिल दृष्टिकोण का उपयोग करें ताकि उन 3 निर्देशों को न डालने के लिए Vue छोटा हो। पहले डेवलपर्स बेवकूफ नहीं हैं। दूसरा मूर्ख-प्रूफिंग ढांचा बदले में इसकी उपयोगिता को सीमित करता है क्योंकि आप सीमित कर रहे हैं जो स्पष्ट "मूर्खों" के आधार पर किया जा सकता है। पूरी स्क्रीन को खाली छोड़कर async संचालन के माध्यम से इसे अवरुद्ध करने के लिए कोई अपनी पूरी वेबसाइट के लिए v-if क्यों लगाएगा?

मुझे लगता है कि आप इस तथ्य की अनदेखी कर रहे हैं कि अधिकांश उपयोग के मामले एक खाली पृष्ठ के साथ भी नहीं हो सकते हैं। उन्हें एक कारण के लिए घटक कहा जाता है। ऐसे मामले जहां मैं व्यक्तिगत रूप से इसका उपयोग करना चाहता हूं, जहां कुछ पहले से ही स्क्रीन पर कुछ और कर रहा है। यह उदाहरण के लिए v-if द्वारा अवरुद्ध एक घटक हो सकता है और जब कुछ बदलता है तो ट्रिगर होता है। हालांकि, पहली बार इसे प्रस्तुत करने की प्रक्रिया में, async functions आदि को घटक बूट के रूप में सम्मानित करने की आवश्यकता है। मैंने इसकी तलाश में पूरे Vue दस्तावेज़ों को देखा और अंत में इसे हैकिश उदाहरणों की तरह एक बहुत ही सुंदर कामकाज के साथ नहीं किया।

मुझे क्या चिंता है कोई/बाद में भी मुझे कोड बनाए रखना है। यह प्रॉमिस कॉलबैक हेल बनाम एसिंक्स की तरह है ... प्रतीक्षित।

वास्तव में मैं इसे आसानी से फॉलोअप फैशन में ढांचे के लचीलेपन और नियंत्रणीयता को बढ़ाता हुआ देखता हूं। मेरा क्या मतलब है यह देखने के लिए बस ऊपर दिए गए हैक्स पर एक नज़र डालें। उदाहरण के लिए, डेवलपर्स एक साधारण async mounted () { await... } स्टेटमेंट के अंतर को भरने के लिए यह सब कर रहे हैं। यदि आप उन सुविधाओं का उपयोग नहीं करना चाहते हैं, तो आप फ़ंक्शन को async रूप में परिभाषित नहीं करते हैं या यहां तक ​​कि await उपयोग भी नहीं करते हैं।

वास्तव में कोई व्यक्ति जो वास्तव में async mounted जीवनचक्र हुक का उपयोग करेगा, वह सबसे अधिक संभावना समझेगा कि वे क्या कर रहे हैं और वे ऐसा क्यों कर रहे हैं, और सबसे अधिक संभावना है कि वे उन बुरी प्रथाओं को नहीं बनाएंगे जिनके बारे में आप चिंतित हैं।

@emahuni , मुझे नहीं लगता कि कोई भी आपके द्वारा साझा की जा रही अपेक्षा से असहमत होगा, लेकिन मैं सोच रहा हूं कि एक अति सूक्ष्म अंतर है, जिसे छोड़ा जा रहा है। आइए मान लें कि async mounted या async created घटक को रेंडर होने में देरी करता है। इस मामले में माता-पिता क्या करते हैं? क्या यह:

• ब्लॉक भी
• मान लें कि घटक को लोड होने तक DOM v-if को हटा दिया जाना है
• मान लें कि घटक पूर्ण लोड होने तक छुपाए जाने के लिए है
• इसके स्थान पर एक अस्थायी तत्व दिखाएँ?

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

इसके अलावा, मैं पूरी तरह से आपके तर्क का पालन नहीं कर रहा हूं:

आप जो कह रहे हैं वह वी-इफ/वी-घड़ी/वी-शो सुविधाओं को जोड़ने जैसा है, जो खराब प्रथाओं को प्रोत्साहित करेगा, इसलिए हम उन सुविधाओं को हटाकर ढांचे को बेहतर तरीके से प्रमाणित करते हैं

हालांकि इस मामले में, हम स्पष्ट रूप से देख सकते हैं कि शुरू async घटकों माउंट का इंतजार कर या बनाई गई गलत व्यवहारों का कारण होगा, यह है कि इस करता है स्पष्ट नहीं है। दूसरा, यह सवाल भीख माँग रहा है, भले ही वे बुरी प्रथाओं का कारण बनते हों, हमें उन्हें ठीक करने का विकल्प चुनना चाहिए, न कि उन्हें नई बुरी प्रथाओं को बनाने के लिए एक औचित्य के रूप में उपयोग करना चाहिए। यदि आप v-if , आदि द्वारा बनाई जा रही खराब प्रथाओं के बारे में जानते हैं ... मैं आपको स्पष्ट रूप से साझा करने के लिए आमंत्रित करता हूं (निश्चित रूप से एक अन्य अंक में) कि उनके साथ समस्या क्या है, इसे औचित्य के रूप में उपयोग करने का प्रयास करने के बजाय एक अलग चर्चा के लिए।

@emahuni , मुझे नहीं लगता कि कोई भी आपके द्वारा साझा की जा रही अपेक्षा से असहमत होगा, लेकिन मैं सोच रहा हूं कि एक अति सूक्ष्म अंतर है, जिसे छोड़ा जा रहा है। आइए मान लें कि async mounted या async created घटक को रेंडर होने में देरी करता है। इस मामले में माता-पिता क्या करते हैं? क्या यह:

• ब्लॉक भी

माता-पिता बच्चे की प्रतीक्षा किए बिना भी आगे बढ़ सकते हैं और प्रस्तुत कर सकते हैं, ऐसा क्यों होना चाहिए? यह ठीक आगे बढ़ सकता है और बच्चे द्वारा प्रस्तुत किए जाने के बाद updated चला सकता है।

• मान लें कि घटक को लोड होने तक DOM v-if को हटा दिया जाना है

मुझे यकीन नहीं है कि मुझे यह मिल गया है ... लेकिन उत्तर नहीं है, हम यह नहीं मानते हैं कि इसे हटा दिया जाएगा, इसे केवल माउंटेड के दौरान कुछ करने की आवश्यकता है जिसे उस दौरान माउंटेड को ब्लॉक करना है। उसके लिए ऊपर पढ़े गए बहुत सारे उपयोग के मामले हैं।

• मान लें कि घटक पूर्ण लोड होने तक छुपाए जाने के लिए है

यह डेवलपर पर निर्भर करता है कि वे उस मामले के लिए माउंटेड या किसी अन्य हुक को एसिंकिंग क्यों कर रहे हैं।

• इसके स्थान पर एक अस्थायी तत्व दिखाएँ?

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

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

FYI करें: आप सहमत हैं कि इसे लागू करने की आवश्यकता है, हालाँकि, यह उन जटिलताओं का परिचय देगा जिनके बारे में आप रो रहे हैं और उन्हें लगता है कि यह बाद में किया जा सकता है जब Vue 3 के बजाय ब्रेकिंग परिवर्तन पेश किए जाते हैं। मुद्दा यह है कि उन्हें लगता है कि इसकी आवश्यकता है। .

इसके अलावा, मैं पूरी तरह से आपके तर्क का पालन नहीं कर रहा हूं:

आप जो कह रहे हैं वह वी-इफ/वी-घड़ी/वी-शो सुविधाओं को जोड़ने जैसा है, जो खराब प्रथाओं को प्रोत्साहित करेगा, इसलिए हम उन सुविधाओं को हटाकर ढांचे को बेहतर तरीके से प्रमाणित करते हैं

हालांकि इस मामले में, हम स्पष्ट रूप से देख सकते हैं कि शुरू async घटकों माउंट का इंतजार कर या बनाई गई गलत व्यवहारों का कारण होगा, यह है कि इस करता है स्पष्ट नहीं है। दूसरा, यह सवाल भीख माँग रहा है, भले ही वे बुरी प्रथाओं का कारण बनते हों, हमें उन्हें ठीक करने का विकल्प चुनना चाहिए, न कि उन्हें नई बुरी प्रथाओं को बनाने के लिए एक औचित्य के रूप में उपयोग करना चाहिए। यदि आप v-if , आदि द्वारा बनाई जा रही खराब प्रथाओं के बारे में जानते हैं ... मैं आपको स्पष्ट रूप से साझा करने के लिए आमंत्रित करता हूं (पाठ्यक्रम के एक अन्य अंक में) उन्हें औचित्य के रूप में उपयोग करने की कोशिश करने के बजाय समस्या क्या है एक अलग चर्चा के लिए।

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

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

किसी ने यह https://github.com/vuejs/vue/issues/7209#issuecomment -424349370 ऊपर पूछा और जहां तक ​​मैंने देखा किसी ने उसका उत्तर नहीं दिया। यह अब तक वास्तव में दिखा रहा है कि Vue इस हिस्से में पीछे चल रहा है। आर्किटेक्चर का यह हिस्सा तब डिज़ाइन किया गया था जब async अभी तक कोई चीज़ नहीं थी। तो आधुनिक वास्तुकला के लिए आधुनिक आवश्यकताओं को पूरा करने के लिए इसे अद्यतन करना निश्चित रूप से एक अच्छा विचार है। अन्यथा बाकी हैकिश और वर्कअराउंड हैं जिन्हें उद्योग में जो हो रहा है उसे करने के बजाय इसे करने के विशिष्ट तरीकों की आवश्यकता है।

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

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

उस बिंदु को कभी नहीं बनाया, मैं यह मुद्दा बना रहा हूं कि मैं घटक को प्रतिपादन से अवरुद्ध किए बिना डिफ़ॉल्ट रूप से एसिंक क्रियाएं करना चाहता हूं। यह सहज नहीं है कि async क्रियाओं को mounted या created ब्लॉक में करने से घटक के प्रतिपादन में देरी होगी। मान लीजिए कि यह मामला था, मैं इसके बजाय जटिलता को देखूंगा कि उपभोक्ता, जो वर्तमान कार्यक्षमता चाहता है, आगे बढ़ेगा। अभी तक तर्क यह नहीं है कि जो मांगा जा रहा है, किया नहीं जा सकता, वह यह है कि जो मांगा जा रहा है वह डिफॉल्ट होना चाहिए। आप v-if="loaded" आधार पर प्रदर्शित टेम्पलेट को स्विच करके अपने घटक के प्रतिपादन को पहले ही अवरुद्ध कर सकते हैं।

कोड को अवरुद्ध किए बिना प्रस्तुत करने के लिए अभी इस तरह दिखता है:
अभी वह कोड है:

<template>
  <div>  
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  async created() { 
    await this.loadData();
    this.loaded = true;
  }
</script>

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

<template>
  <div>  
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  created() { 
    this.loadData().then(() => this.loaded = true);
  }
</script>

और बस हमारे द्वारा लिखी गई स्क्रीन पर घटक को प्रस्तुत करने की उपेक्षा करें

<template>
  <div>  
    <div>
      ....
    </div>
</template>

<script>
  async created() { 
    await this.loadData();
  }
</script>

रेंडरिंग वारंट मेकिंग को ब्लॉक करने के लिए इस सरलीकरण को जोड़ने से किस लाभ के लिए ब्लॉक करना अधिक जटिल नहीं है? मैं बस इसे नहीं देख रहा हूँ।

घटकों के लिए निर्भरता प्रबंधन

@ yyx990803 कृपया इसे देखें, यह सही नहीं है, लेकिन फिर भी एक जटिल उपयोग केस स्केनेरियो है।

ठीक है यहाँ एक उपयोग का मामला है जिसे जीवनचक्र के हुक में async होने पर सुरुचिपूर्ण ढंग से संभाला जा सकता था ... प्रतीक्षा करें:
_मैं वास्तव में इसे एक ऐप में करना चाहता था और इसे प्राप्त करने के लिए बदसूरत कोड मिला। यह coz_ का एक बहुत ही काल्पनिक उदाहरण है

मुझे घटक ए की आवश्यकता है ताकि घटक बी && सी के mounted हुक को स्वयं माउंट करने से पहले आग लगने की प्रतीक्षा की जा सके। तो घटक ए के mounted को अपने created हुक का इंतजार करना पड़ता है, जिसने घटक बी && सी के बढ़ते ट्रिगर को ट्रिगर किया _(जो वास्तव में प्रतीक्षा करने से पहले कुछ कर सकता है)_। बात यह है कि यह इस तरह से आसान है और बहुत साफ और सहज ज्ञान युक्त है क्योंकि संबंधित घटक के लिए सब कुछ एक ही स्थान पर रहता है।

A एक ट्रिगर ईवेंट का उत्सर्जन करता है और B और C से प्रतिक्रियाओं के लिए सुनता B और C जारी रखने से पहले A के सिग्नल की प्रतीक्षा करते हैं, फिर एक बार माउंट किए गए ईवेंट का उत्सर्जन करते हैं)_ जारी रखने से पहले, सरल। यह राज्य प्रबंधन के लिए कहीं और बिना किसी बाहरी डेटा के

मुख्य होस्टिंग घटक , सभी घटकों को एक साथ लोड किया जाता है, लेकिन घटनाओं और async का उपयोग करके सही लोगों की प्रतीक्षा करें ... प्रतीक्षा करें। यह कम परवाह करता है कि ये बच्चे क्या करते हैं, वे खुद आदेश देते हैं।

<template>
  <div>
     ...
     <component-A/>
     <component-B/>
     <component-C/>
     ... other conent
  </div>
</template>
<script>
  import ComponentA...
  ...
  export default {
      components: { ComponentA... }
  }
</script>

घटक ए निर्भरता के रूप में बी और सी के बढ़ते नियंत्रण को नियंत्रित करता है। ट्रिगरिंग बाद में अन्य हुक में या समान घटकों के यूएक्स ईवेंट के माध्यम से भी किया जा सकता है। निम्नलिखित यहाँ सिर्फ विचार दिखाने के लिए है।

<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here before mounting thrusters, even await it
         this.root.$emit('mount-thrusters');
         await Promise.all([
            this.wasMounted('thruster-1-mounted'), 
            this.wasMounted('thruster-2-mounted')
         ]); 
      },
      mounted() {
        // will only run after components B and C have mounted
        ...
      },

     methods: {
       wasMounted(compEvent) {
          return new Promise( (resolve)=>this.root.$once(compEvent, ()=>resolve()));
       }
    }
  }
</script>

घटक बी

<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here, even await it, but happens at the same time as all components
         await new Promise( (resolve)=>this.root.$once('mount-thrusters', ()=>resolve()));
      },
     mounted() {
       this.root.$emit('thruster-1-mounted');
    }
  }
</script>

घटक सी

<template>
  ...
</template>
<script>
  export default {
      async created() {
          // ...do something here, even await it, but happens at the same time as all components
         await new Promise( (resolve)=>this.root.$once('mount-thrusters', ()=>resolve()));
      },
     mounted() {
       this.root.$emit('thruster-2-mounted');
    }
  }
</script>

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

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

यह स्पष्ट रूप से अनावश्यक रूप से जटिल और अचूक कोड से छुटकारा दिलाता है।

अब एक बड़े ऐप में इसकी कल्पना करें, जिसमें 32 थ्रस्टर घटक अलग-अलग व्यवहार करते हैं। आपके दिमाग में केवल 3 बिंदु होंगे, जो मिश्रित होने पर भी 2 तक कम हो जाते हैं।

चीजों को ताजा रखना

coz की यह केवल घुड़सवार और निर्मित तक ही सीमित नहीं है, बल्कि वास्तव में अन्य सभी जीवनचक्र हुक के साथ काम करना चाहिए। कल्पना कीजिए कि यह एक चमकदार नए beforeActivate / beforeUpdate हुक में है। हम घटक को _activation/update_ और केवल _active/update_ की प्रतीक्षा कर सकते हैं जब घटक _सक्रिय/अपडेट_ होने पर हर बार रिफ्रेशमेंट किया जाता है; सुनिश्चित करें कि चीजें ताजा रहें।

इसे लागू करने के बाद सूची अंतहीन है।

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

उस बिंदु को कभी नहीं बनाया, मैं यह मुद्दा बना रहा हूं कि मैं घटक को प्रतिपादन से अवरुद्ध किए बिना डिफ़ॉल्ट रूप से एसिंक क्रियाएं करना चाहता हूं। यह सहज नहीं है कि async क्रियाओं को mounted या created ब्लॉक में करने से घटक के प्रतिपादन में देरी होगी। मान लीजिए कि यह मामला था, मैं इसके बजाय जटिलता को देखूंगा कि उपभोक्ता, जो वर्तमान कार्यक्षमता चाहता है, आगे बढ़ेगा। अभी तक तर्क यह नहीं है कि जो मांगा जा रहा है, किया नहीं जा सकता, वह यह है कि जो मांगा जा रहा है वह डिफॉल्ट होना चाहिए। आप v-if="loaded" आधार पर प्रदर्शित टेम्पलेट को स्विच करके अपने घटक के प्रतिपादन को पहले ही अवरुद्ध कर सकते हैं।

कोड को अवरुद्ध किए बिना प्रस्तुत करने के लिए अभी इस तरह दिखता है:
अभी वह कोड है:

<template>
  <div>  
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  async created() { 
    await this.loadData();
    this.loaded = true;
  }
</script>

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

<template>
  <div>  
    <spinner v-if="!loaded">
    <div v-else>
      ....
    </div>
</template>

<script>
  created() { 
    this.loadData().then(() => this.loaded = true);
  }
</script>

और बस हमारे द्वारा लिखी गई स्क्रीन पर घटक को प्रस्तुत करने की उपेक्षा करें

<template>
  <div>  
    <div>
      ....
    </div>
</template>

<script>
  async created() { 
    await this.loadData();
  }
</script>

रेंडरिंग वारंट मेकिंग को ब्लॉक करने के लिए इस सरलीकरण को जोड़ने से किस लाभ के लिए ब्लॉक करना अधिक जटिल नहीं है? मैं बस इसे नहीं देख रहा हूँ।

यह Vue 101 बूटकैंप है और इसमें कुछ भी नया नहीं है... उदाहरण के लिए उपरोक्त मामलों को कवर करना पर्याप्त नहीं है। यहां विचार उपयोगकर्तालैंड में जटिलता को कम करने के लिए है जहां वास्तव में Vue का उपयोग किया जाता है और कोड के बारे में तर्क करने में आसान होता है।

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

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

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

  <template>
    <a-component @rendered="showBandC = true" />
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>

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

अगले हुक फ़ंक्शन पर जाने से पहले Vue को आंतरिक रूप से async का सम्मान करने का विचार है।

निश्चित रूप से वह हिस्सा समझ में आता है, लेकिन मुझे यकीन नहीं है कि उदाहरण को जटिल करने की आवश्यकता क्यों है, इस उपयोगकर्ता कहानी की तरह कुछ क्यों न कहें:

मेरे घटक में async beforeMount और async mounted , लेकिन mounted में कोड beforeMount में कोड पूरा होने से पहले सक्रिय हो रहा है। beforeMount पूरा होने से पहले हम mounted को फायरिंग से कैसे रोक सकते हैं?

मूल अनुरोध किस प्रकार का था, इसलिए मुझे लगता है कि दूसरी प्रतिक्रिया में जो प्रश्न सामने आया था वह अभी भी प्रासंगिक है: https://github.com/vuejs/vue/issues/7209#issuecomment -350284784

अभी के लिए बंद, लेकिन अधिक ठोस तर्क/उपयोग के मामलों/निहितार्थों के साथ अनुवर्ती कार्रवाई करने के लिए स्वतंत्र महसूस करें।

क्या वास्तव में पहले से निष्पादित जीवनचक्र हुक पर ब्लॉक करने की आवश्यकता के लिए एक वैध उपयोग का मामला है, या यह जीवनचक्र के हुक के लिए सिंक्रोनस के लिए सही है। अब तक चर्चा प्रकृति में दार्शनिक रही है (जैसा कि अच्छी वास्तुकला चर्चाएं होती हैं), लेकिन वास्तव में सवाल यह है कि ऐसा करने का एक वास्तविक अच्छा कारण रहा है। मुझे एक सेकंड के लिए संदेह नहीं है कि ढांचे के लिए एसिंक कोड का इंतजार करना उचित है। मुझे एन अन्य पुस्तकालयों में सटीक समस्या थी जिसने ऐसा नहीं किया या कॉलबैक पास नहीं किया (या कॉलबैक पास करें लेकिन कॉलबैक पर कॉलबैक पास न करें)। हालांकि, एसिंक्स लाइफसाइकिल हुक रखना वास्तव में उचित है या कुछ ऐसा करने की कोशिश करने के परिणाम के कारण हैं जो "नहीं किया जाना चाहिए"?

यानी क्या होता है जब आप unmount एक ऐसे घटक का प्रयास करते हैं जो समाप्त नहीं हुआ है created , वाह, यह अभी भी प्रतीक्षा करने के लिए बुरा होगा। या destroying एक जो समाप्त नहीं हुआ है mounted , मैं उस कार्यक्षमता के कार्यान्वयनकर्ता से ईर्ष्या नहीं करता।

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

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

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

यह अब घटकों को बहुत अधिक जोड़ रहा है। हम चाहते हैं कि ये A को छोड़कर दूसरे के बिना काम करें।

घटकों को सीधे एक साथ जोड़ना अप्रत्याशित निर्भरता पेड़ बनाता है जो घटकों को पुन: प्रयोज्य होने से रोकता है और वीयू को उन्हें सही ढंग से पुन: प्रस्तुत करने की इजाजत देता है।

वास्तव में आप बिंदु को याद कर रहे हैं, ये शिथिल रूप से उस विस्तार से जुड़े हुए हैं कि प्रत्येक का उपयोग किया जा सकता है और दूसरे को प्रभावित किए बिना बनाए रखा जा सकता है। वास्तव में आप <component-x /> , नहीं v-if , vuex से बाहर अपने राज्य का प्रबंधन करने के लिए माता-पिता में कोई और कोड लिखे बिना उनमें से किसी को भी कई बार कहीं भी छोड़ सकते हैं और न ही कुछ और।

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

 this.$root.$emit('thruster-mounted') // in B and C
// instead of 
 this.$root.$emit('thruster-1-mounted') // for B and 2 for C

// then count the responses and resolve once they are >= 2 in component A

वैसे भी, इसीलिए मैंने कहा कि कंपोनेंट्स डिपेंडेंसी हैंडलिंग, यह वांछित और अपेक्षित है, लेकिन जितना संभव हो उतना कम जटिलता में किया जाना चाहिए क्योंकि यह जितना अधिक जटिल होता जाता है उतना ही भ्रमित होता जाता है।

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

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

  <template>
    <a-component @rendered="showBandC = true" />
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>

ए के बारे में यह क्या है कि इस मामले में हमें वास्तव में बी और सी प्रस्तुत करने से पहले प्रस्तुत करना होगा।

हम चाहते हैं कि प्रत्येक घटक माउंट होने से पहले अद्वितीय कार्य करे। लेकिन सभी घटक तभी प्रस्तुत होंगे जब हर दूसरे घटक ने वह काम करना समाप्त कर दिया हो। यहीं कहानी है।
राज्य प्रबंधन के साथ अच्छा भाग्य और v-if बस इसे नियंत्रित करने के लिए वास्तविक डेटा का उल्लेख नहीं करना है जो शायद vuex store में उत्पन्न होगा। जहां भी घटक का उपयोग किया जाता है, वहां आपके पास बहुत सारे डुप्लिकेट कोड लिखे होंगे। मान लीजिए कि आपके पास एक और घटक है जो केवल ए और सी को होस्ट करता है और एक अलग कॉन्फ़िगरेशन में है? उस काम को करने के लिए आपको उन v-if s, vuex State Management को लिखना होगा। क्या आप समस्या को देखते हैं? मुझे समझाने दो:

  // component Z totally different from foo, so we can't make this a component for reuse
  <template>
    <a-component @rendered="showBandC = true" />
    <c-component v-if="showBandC" />
  </template>
 ...
computed: {
showBandB() { ...vuex ...,
showBandC() { ...vuex ...,
}

  // component Foo totally unique, probably has other things it does
  <template>
    <b-component v-if="showBandC" />
    <c-component v-if="showBandC" />
  </template>
 ...
computed: {
// ok you could mixin this, fair, but complex nevertheless
showBandB() { ...vuex ...,
showBandC() { ...vuex ...,
}

..... और आगे

माता-पिता में कभी भी कुछ भी किए बिना घटकों का उपयोग करने के बजाय:

  // component Z
  <template>
    <a-component />
    <b-component />
  </template>

  // component Foo
  <template>
    <b-component  />
    <c-component />
  </template>

... इत्यादि

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

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

अगले हुक फ़ंक्शन पर जाने से पहले Vue को आंतरिक रूप से async का सम्मान करने का विचार है।

निश्चित रूप से वह हिस्सा समझ में आता है, लेकिन मुझे यकीन नहीं है कि उदाहरण को जटिल करने की आवश्यकता क्यों है, इस उपयोगकर्ता कहानी की तरह कुछ क्यों न कहें:

मेरे घटक में async beforeMount और async mounted , लेकिन mounted में कोड beforeMount में कोड पूरा होने से पहले सक्रिय हो रहा है। beforeMount पूरा होने से पहले हम mounted को फायरिंग से कैसे रोक सकते हैं?

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

क्या आप देखते हैं कि आपने इस सरल सेटअप में कितनी जटिल चीजें पेश कीं, जिन्हें उस छोटे से async द्वारा हल किया गया था ... जीवनचक्र में प्रतीक्षा सुविधा?

@wparad

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

यह कहाँ है:

... को प्राप्त करने के लिए आर्किटेक्चर के मौलिक पुनर्विचार/पुनर्लेखन की आवश्यकता है, और संभावित रूप से बहुत सारे तर्क तोड़ सकते हैं जो जीवन चक्र हुक की तुल्यकालिक प्रकृति पर निर्भर करता है ...

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

उन सभी मामलों में मैं प्रतीक्षा को जांचने या निरस्त करने के लिए टाइमआउट का उपयोग करता हूं, जो कि अधिकांश एसिंक ऑपरेशंस की तरह विफल हो सकता है।

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