Vue: क्या vuejs2.0 को $प्रसारण, $प्रेषण ईवेंट एपीआई रखना चाहिए? 2.0 में अभिभावक-बाल संचार को संबोधित करने के लिए कोई अच्छा समाधान नहीं है

को निर्मित 1 सित॰ 2016 · 41टिप्पणियाँ · स्रोत: vuejs/vue

@yyx990803 ,
नमस्ते, वूज कोर टीम,
मैं vuejs2.0 के साथ मूल बाल घटकों के बीच बिंदु से बिंदु संचार के लिए एक अच्छा समाधान खोजने के लिए संघर्ष कर रहा हूं।
क्योंकि vuejs2.0 ने $broadcast,$dispatch api को हटा दिया है, मेरे लिए $broadcast का वैकल्पिक समाधान खोजना बहुत कठिन है,$डिस्पैच vuejs2.0 ईवेंट बस सुविधा प्रदान करता है।
मैंने यहां इस विषय के बारे में फ़ोरम में एक सूत्र लिखा

कृपया इसे तब तक बंद न करें जब तक कि vuejs2.0 पर कोई अच्छा विचार या समाधान न हो।

<pcom id=1>
    <soncoma></soncoma>
    <soncomb></soncomb>
</pcom>
<pcom id=2>
    <soncoma></soncoma>
    <soncomb></soncomb>
</pcom>

उपरोक्त कोड में, जब pcom1 का बच्चा, उदाहरण के लिए, सोनकोमा $ एक घटना का उत्सर्जन करता है, तो कहें,

bus.$emit('son-coma-event',somedata)

pcom पर, हम उस घटना को सुनते हैं

bus.$on('son-coma-event',function(){})

मैं केवल यह चाहता हूं कि pcom1 उस घटना को संभाल ले, लेकिन दुर्भाग्य से pcom2 भी इसे संभाल लेगा।
इस स्थिति से कैसे निपटें?

मेरे आवेदन में कामकाज में से एक इसका उपयोग करना है। $ माता-पिता घटना बस के रूप में
बच्चे में:

this.$parent.$emit('some-event',someData)

माता-पिता में:

{
   created(){
       this.$on('some-event',function(){})
}

उपरोक्त समाधान के लिए नकारात्मक बिंदु है:

हम माता-पिता-बच्चे के संबंध पर बहुत कुछ जोड़ते हैं;
माता-पिता-बच्चे के स्तर के अधिक गहन स्तर होने पर यह काम नहीं करता है;

कुछ अधिक जटिल परिस्थितियों में, कस्टम ईवेंट सिस्टम के लिए एक अच्छा समाधान खोजना अधिक कठिन होगा, उदाहरण के लिए, एक पुनरावर्ती घटक

 <pcom>
    <recursivechild>
             <recursivechild>
                          <recursivechild>
                          </recursivechild>
             </recursivechild>
    <recursivechild>
</pcom>

 <pcom>
    <recursivechild>
             <recursivechild>
                          <recursivechild>
                          </recursivechild>
             </recursivechild>
    <recursivechild>
</pcom>

रिकर्सिवचाइल्ड अपने प्रत्यक्ष pcom घटक से कैसे संवाद करता है?
कृपया इन विषयों पर अपना विचार या बिंदु दें।
धन्यवाद ~!

discussion

स्रोत

cnweibo

सबसे उपयोगी टिप्पणी

@rhyek मैं आपके द्वारा उठाए गए कुछ बिंदुओं के बारे में अपना 2ct देना चाहता हूं। चूंकि चर्चा पहले ही कई विषयों पर चर्चा कर चुकी है, इसलिए मैं इस बारे में बुनियादी बातों पर वापस जाना चाहूंगा कि हमने $diospatch और $broadcast का बहिष्कार क्यों किया:

1. निहित युग्मन।

यदि आपके माता-पिता और एक गहरा घोंसला वाला बच्चा है जो एक घटना भेजता है, तो कोड से इस संबंध का अनुमान लगाने का कोई तरीका नहीं है (और यह $broadcast भी सच है।)

यदि आप Vue 2.0 के साथ हमारे द्वारा पेश किए गए अन्य परिवर्तनों और बहिष्करणों को देखते हैं, तो आप महसूस कर सकते हैं कि स्पष्ट विकल्पों के पक्ष में निहित व्यवहार को हटाना एक सामान्य विषय है, और $dispatch पदावनत करना वहीं पर सही बैठता है।

उदाहरण:

// parent
events: {
  'some-event': function () { ... }
}

// deeply nested child:
$dispatch('some-event')

यह ठीक है जब माता-पिता के पास केवल एक सीधा बच्चा होता है - लेकिन उस स्थिति में, टेम्पलेट में श्रोता के साथ $emit() कोई वास्तविक अतिरिक्त काम नहीं है।

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

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

2. घटना के नाम

जब आप गहराई से नेस्टेड घटकों के साथ $dispatch उपयोग करते हैं, तो आपको अपनी घटनाओं को नाम देने में बहुत स्पष्ट होना होगा, क्योंकि अन्यथा, वे संघर्ष कर सकते हैं:

// parent
events: {
  'close': function () { ... }
}

// deeply nested child 1:
$dispatch('close')
// deeply nested child 2:
$dispatch('close')

..और अगर वे बच्चे थर्ड-पार्टी-लिबास हैं, तो आप अब खराब हो गए हैं। या बीच में किसी घटक में घटना को पकड़ना है, इससे पहले कि आप $dispatch() आगे माता-पिता तक इसका नाम बदलें। और इस पर टिप्पणी करना न भूलें, क्योंकि इस कोड को देखने वाला कोई व्यक्ति सोच सकता है कि आप किसी घटना का नाम बदलने के अलावा और कुछ क्यों नहीं करते हैं।

$emit और टेम्प्लेट श्रोताओं का उपयोग करने से यह समस्या नहीं होती है। आप हर जगह सरल, संक्षिप्त ईवेंट नामों का उपयोग कर सकते हैं, वे टकराएंगे नहीं क्योंकि प्रत्येक ईवेंट का अपना कॉलबैक टेम्प्लेट @close="callback में संलग्न होता है।

मैं वास्तव में बस यही चाहता हूं कि आपने किसी भी प्रतिमान का उपयोग करने के लिए *विकल्प * को नहीं लिया,

अगर हमने सोचा कि दोनों प्रतिमान समान रूप से अच्छी तरह से काम कर सकते हैं, तो हम उनके साथ समान व्यवहार करेंगे। लेकिन हम ऐसा नहीं सोचते, उपरोक्त कारणों से और बहुत कुछ।

इसलिए, हम "ग्लोबल बस" पद्धति के साथ इसे प्राप्त करने का एक रास्ता छोड़ते हुए, उपयोगकर्ताओं को उन समझौतों तक ले जाने का प्रयास करते हैं जो हमें सबसे अच्छा काम करते हैं।

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

हो सकता है कि आप एक उदाहरण प्रदान कर सकें जहां आपको लगता है कि $ प्रेषण और $ प्रसारण आपके लिए सबसे अच्छा काम करते हैं, और मैं आपको यह दिखाने की कोशिश करता हूं कि "हमारा" दृष्टिकोण स्थिति को कैसे सुधार सकता है?

LinusBorg 4 अक्तू॰ 2016

👍2

सभी 41 टिप्पणियाँ

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

cnweibo 1 सित॰ 2016

2.0 परिवर्तन पर इसे पहले ही उचित ठहराया जा चुका है

यहाँ एक प्रति है:

$dispatch और $broadcast के मूल्यह्रास से कैसे निपटें?
जिस कारण से हम $dispatch और $broadcast को हटा रहे हैं, वह यह है कि घटना प्रवाह जो कि घटकों के पेड़ की संरचना पर निर्भर करता है, यह तर्क करना कठिन हो सकता है कि घटक पेड़ कब बड़े हो जाते हैं (सीधे शब्दों में कहें तो: यह नहीं है बड़े ऐप्स में अच्छी तरह से स्केल करें और हम आपको बाद में दर्द के लिए सेट अप नहीं करना चाहते हैं)। $dispatch और $broadcast भी सहोदर घटकों के बीच संचार को हल नहीं करते हैं। इसके बजाय, आप Node.js में EventEmitter के समान पैटर्न का उपयोग कर सकते हैं: एक केंद्रीकृत ईवेंट हब जो घटकों को संचार करने की अनुमति देता है, चाहे वे घटक ट्री में कहीं भी हों। क्योंकि Vue इंस्टेंस इवेंट एमिटर इंटरफ़ेस को लागू करते हैं, आप वास्तव में उस उद्देश्य के लिए एक खाली Vue इंस्टेंस का उपयोग कर सकते हैं:
var bus = new Vue()
// in component A's method
bus.$emit('id-selected', 1)
// in component B's created hook
bus.$on('id-selected', function (id) {
 // ...
})
यह पैटर्न सरल परिदृश्यों में $dispatch और $broadcast प्रतिस्थापन के रूप में कार्य कर सकता है। लेकिन अधिक जटिल मामलों के लिए, Vuex का उपयोग करके एक समर्पित राज्य प्रबंधन परत पेश करने की अनुशंसा की जाती है।

अपग्रेड गाइड पर दिखाया गया उदाहरण वही है जिसके बारे में आप बात कर रहे हैं

पुनरावर्ती संचार के बारे में: कई घटक एक ही घटना को सुन सकते हैं। इस घटना को आम माता-पिता द्वारा मान्यता प्राप्त है ताकि हर बच्चा इसके बारे में जागरूक हो सके

posva 1 सित॰ 2016

@posva , आपकी जानकारी के लिए धन्यवाद। बस हब वास्तव में सरल एकल घटक बिंदु से एकल घटक बिंदु संचार में अच्छी तरह से काम करता है। यदि एक ही घटक प्रकार के कई घटक हैं, तो समस्या होगी, दुर्भाग्य से, यह एक सामान्य मामला है। कई मामलों में, मैं घटना का उपयोग करना चाहता हूं कि कुछ विशिष्ट घटक से संबंधित एक छोटा डेटा अपडेट करना है। वर्तमान घटना बस कार्यान्वयन गंतव्य या उत्पत्ति नोड के बारे में जानकारी नहीं देता है (मैंने प्रत्येक घटक के _uid को देखा है, शायद हम घटना तारों के लिए इस अद्वितीय _uid का उपयोग कर सकते हैं?), इसलिए vuejs2.0 वास्तव में बिंदु से बिंदु घटना संचार का समर्थन नहीं कर सकता है . सटीक होने के लिए, vuejs2.0 इवेंट बस घटक प्रकार संचार के लिए केवल घटक प्रकार का समर्थन करता है? क्या उस आवश्यकता को पूरा करने के लिए कोई आसान समाधान है: पेड़ में किसी घटना से ट्रिगर किया गया और अपना स्वयं का डेटा अपडेट किया गया
vuex एप्लिकेशन स्तर के वैश्विक स्थैतिक राज्य डेटा प्रबंधन के लिए बहुत अच्छा है, लेकिन जैसा कि मैं समझता हूं, यह विशिष्ट स्थानीय घटक डेटा प्रबंधन के लिए अच्छा नहीं हो सकता है?
इस मुद्दे पर अधिक विचार का स्वागत है।

cnweibo 1 सित॰ 2016

@cnweibo मैंने मंच पर एक उदाहरण के साथ आपके प्रश्न का उत्तर दिया है। मुझे लगता है कि यह उदाहरण आपकी जरूरतों को पूरा करेगा।
http://forum.vuejs.org/topic/4832/vue2-0-event-bus-issue-how-to-deliver-event-to-parent-when-the-same-multiple-parent-children-in- डोम/6

ktsn 1 सित॰ 2016

👍2

क्या उस आवश्यकता को पूरा करने का कोई सरल उपाय है: a . द्वारा ट्रिगर किया गया
पेड़ में घटना और अपने स्वयं के डेटा को अपडेट करें

यह एक जटिल घटना प्रणाली के बिना, केवल vuex द्वारा हल किया जाता है।

vuex अनुप्रयोग स्तर के वैश्विक स्थैतिक राज्य डेटा प्रबंधन के लिए बहुत अच्छा है,
लेकिन जैसा कि मैं समझता हूं, यह विशिष्ट स्थानीय घटक डेटा के लिए शायद अच्छा नहीं है
प्रबंध

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

यह पूरी 'घटनाओं बनाम साझा-राज्यों' की चर्चा महीनों से सुलझी है
पहले, और निष्कर्ष वैश्विक ईवेंट बस, या vuex का उपयोग करना है। तो मैं चाहता हूँ
आपको vuex और यह कैसे काम करता है, इसके बारे में अधिक पढ़ने की सलाह देते हैं।

गुरु, 1 सितं, 2016 पर 16:17 cnweibo [email protected] लिखा है:

@posva https://github.com/posva , आपकी जानकारी के लिए धन्यवाद। बस
हब वास्तव में सरल एकल घटक बिंदु से एकल घटक में अच्छी तरह से काम करता है
बिंदु संचार। यदि एक ही घटक के साथ कई घटक हैं
प्रकार, समस्या होगी, दुर्भाग्य से, यह एक सामान्य मामला है। बहुत
मामलों, जो मैं घटना का उपयोग करना चाहता हूं वह कुछ से संबंधित एक छोटा डेटा अपडेट करना है
विशिष्ट घटक। वर्तमान घटना बस कार्यान्वयन नहीं देता है
गंतव्य या उद्गम नोड के बारे में जानकारी (मैंने प्रत्येक का _uid देखा है
घटक, शायद हम घटना तारों के लिए इस अद्वितीय _uid का उपयोग कर सकते हैं? ), इसलिए
vuejs2.0 वास्तव में बिंदु से बिंदु घटना संचार का समर्थन नहीं कर सकता है। होने वाला
सटीक, vuejs2.0 इवेंट बस केवल घटक प्रकार से घटक प्रकार का समर्थन करती है
संचार? क्या उस आवश्यकता को पूरा करने का कोई सरल उपाय है:
ट्री में किसी घटना द्वारा ट्रिगर किया गया और _ITS का अपना डेटा_ अपडेट करें
vuex अनुप्रयोग स्तर के वैश्विक स्थैतिक राज्य डेटा प्रबंधन के लिए बहुत अच्छा है,
लेकिन जैसा कि मैं समझता हूं, यह विशिष्ट स्थानीय घटक डेटा के लिए शायद अच्छा नहीं है
प्रबंध?
इस मुद्दे पर अधिक विचार का स्वागत है।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/vuejs/vue/issues/3581#issuecomment -244008699, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFTLl1bjHqWTVDAkr8Fqbx0WiTuH16n2ks5qlooBgaJpZM4JyUfJ
.

fnlctrl 1 सित॰ 2016

👍1

मैं अब इस मुद्दे को बंद कर दूंगा, क्योंकि

समाधान प्रदान किए गए और
जीथब मुद्दे वैसे भी समर्थन मांगने के लिए सही जगह नहीं हैं (दिशानिर्देश देखें)

LinusBorg 1 सित॰ 2016

@ktsn , आपके डेमो
@fnlctrl , मैं तथाकथित मॉड्यूलर vuex राज्य प्रबंधन पर अधिक समय बिताऊंगा

फिर से धन्यवाद ~!

cnweibo 1 सित॰ 2016

😕1

मेरी राय में $ प्रसारण की जरूरत नहीं है, केवल गिरने वाले प्रॉप्स डेटा-फ्लो।
किसी भी $dispatch को सिंगल-लेवल v-on और $emit के रूप में इस तरह से फिर से लागू किया जा सकता है (Vue 1 में):
प्रत्येक शामिल घटक पर <child-component @select="$emit('select', $arguments[0])" />
किसी भी अन्य स्थिति में कस्टम इवेंट बसों का उपयोग किया जाना चाहिए

iagafonov 1 सित॰ 2016

वास्तव में, घटक पर कस्टम ईवेंट के लिए घटक टैग पर v-on स्वयं घटक से $emit के साथ भी काम करता है।

cnweibo 1 सित॰ 2016

@cnweibo रिकॉर्ड के लिए, ईवेंट डेटा पुनर्प्राप्त किया जा सकता है।

{
  template: `<foo @bar="dosomething">`,
  methods: {
    dosomething(params1, params2, ... and all the event data args) {}
  }
}

fnlctrl 1 सित॰ 2016

👍1

लेकिन घटना डेटा vuejs2.0 . में पुनर्प्राप्त नहीं किया जा सकता है

निश्चित रूप से यह हो सकता है, आपको अन्यथा क्या लगता है?

LinusBorg 1 सित॰ 2016

@fnlctrl
@LinusBorg
क्षमा करें, मुझे गलतफहमी है और मैं चीजों को स्पष्ट नहीं करता। @fnlctrl प्रदान किए गए पैटर्न में, वास्तव में इसके ईवेंट हैंडलर में भी सभी डेटा पुनर्प्राप्त कर सकते हैं

 <comp @some-event-emitted-by-comp-internal-template="someFuncInParentScope"></comp>

cnweibo 2 सित॰ 2016

मेरी अपनी टिप्पणी को किसी अन्य अंक से कॉपी/पेस्ट करना: https://github.com/vuejs/vue/issues/2760#issuecomment -250883407

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

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

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

इस सूत्र में अन्य प्रस्ताव मुझे याद दिलाते हैं कि एम्बरजेएस इसे कैसे करना चाहता है। पदानुक्रम के प्रत्येक स्तर के नीचे घटकों को गुण के रूप में बंद करने की क्रियाएं पास करना। इतना थकाऊ और अनावश्यक! Vuejs यही कारण था कि मैंने https://www.npmjs.com/package/ember-component-action-bubbling लिखा

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

rhyek 1 अक्तू॰ 2016

👎2 👍1

घटना बस प्रतिमान केवल एक ही काम करने के समाधान के रूप में प्रस्तावित किया गया था, जब एक घटना-आधारित वास्तुकला अक्सर एक घोषणात्मक, राज्य-आधारित वास्तुकला से कमतर होती है।

मान लीजिए, आपके पास एक ऐप है जहां उपयोगकर्ता लॉग इन कर सकता है। ईवेंट-आधारित समाधान के साथ:

एक लॉगिन घटना सुनें
घटना को बाद में उपयोगकर्ता नाम और पासवर्ड के साथ सक्रिय करें
जो भी घटक सुन रहे हैं उसी के अनुसार उक्त घटना का जवाब दें

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

तो आइए एक स्टेटफुल दृष्टिकोण का उपयोग करें:

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

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

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

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

itsMapleLeaf 1 अक्तू॰ 2016

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

दोनों प्रतिमानों को स्वच्छ तरीके से संभालने के तरीके हैं और यह आमतौर पर (और चाहिए) ढांचे के उपयोगकर्ता की जिम्मेदारी होगी।

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

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

या, हो सकता है कि आपके पास बटन 10 स्तर गहरा हो और आपको प्रत्येक स्तर पर v-on:login हैंडलर घोषित करना पड़े ताकि इरादा अपने भाग्य तक पहुंच जाए। पूरी तरह से अनावश्यक।

rhyek 1 अक्तू॰ 2016

वास्तव में, प्रत्येक स्तर पर v-on से आपके कोड को बनाए रखना कठिन हो जाता है।

rhyek 1 अक्तू॰ 2016

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

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

itsMapleLeaf 1 अक्तू॰ 2016

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

यह वांछनीय नहीं है, उदाहरण के लिए, लॉग इन बटन किसी तीसरे पक्ष के पुस्तकालय का हिस्सा था।

मैं वास्तव में चाहता हूं कि आपने किसी भी प्रतिमान का उपयोग करने के लिए *_choice *_ नहीं लिया, खासकर जब घटना बबलिंग व्यापक रूप से मान्यता प्राप्त है और इसलिए किसी प्रोजेक्ट पर नए योगदानकर्ताओं के लिए समझना आसान है।

rhyek 1 अक्तू॰ 2016

यह "कुछ यादृच्छिक घटक" से आपका क्या मतलब है, इस पर निर्भर करता है, क्योंकि राउटर व्यू घटक, उदाहरण के लिए, मेरी राय में स्टोर तक पहुंचने और प्रतिबद्ध होने का पूर्ण अधिकार है। हालांकि, यदि यह पुन: उपयोग के लिए एक छोटा घटक है, जैसे कि बटन, फॉर्म, या कुछ अन्य UI तत्व, 10 में से 9 बार, तो इसके लिए प्रॉप्स और ईवेंट का उपयोग करके स्टोर तक पहुंचने का कोई तार्किक कारण नहीं होना चाहिए।

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

हालांकि, यह ज्यादातर एक स्पर्शरेखा है। कई बार, समझने में आसान प्रतिमान वे होते हैं जो अंत में नरक के अंत तक दुर्व्यवहार करते हैं और बोझिल हो जाते हैं। एक राज्य-आधारित दृष्टिकोण बहुत अधिक सीधा है, जैसा कि हम में से अधिकांश द्वारा सहमति व्यक्त की गई है जो वर्तमान में 2.0 का उपयोग कर रहे हैं। यदि यह दृष्टिकोण आपकी प्राथमिकता नहीं है, तो आप 1.0 का उपयोग जारी रखने के लिए, या किसी अन्य ढांचे पर आगे बढ़ने के लिए स्वतंत्र हैं।

itsMapleLeaf 1 अक्तू॰ 2016

10 में से 9 बार, प्रॉप्स और इवेंट्स का उपयोग करके स्टोर तक पहुँचने का कोई तार्किक कारण नहीं होना चाहिए।

बिल्कुल मेरी बात।

डीप नेस्टिंग अपने आप में एक ऐसी समस्या है जिससे जितना हो सके बचा जाना चाहिए

कभी-कभी, यह विकल्प नहीं होता है।

घटनाओं को दो स्तरों पर प्रचारित करने के लिए इतना परेशान नहीं है

इतना सच नहीं है जब वे स्तर गहरे हो जाते हैं।

समझने के लिए आसान प्रतिमान वे हैं जो अंत में नरक के अंत तक दुर्व्यवहार करते हैं और बोझिल हो जाते हैं

यह आपके उपयोगकर्ताओं के अनुशासन पर निर्भर होना चाहिए।

यदि यह दृष्टिकोण आपकी प्राथमिकता नहीं है, तो आप 1.0 का उपयोग जारी रखने के लिए, या किसी अन्य ढांचे पर आगे बढ़ने के लिए स्वतंत्र हैं।

एमएमके

सादगी और सुविधा के कारण मैं एम्बर से वू पर स्विच करने पर विचार कर रहा था। $dispatch उन चीजों में से एक है जो मुझे Vue के बारे में पसंद आई और इसे हटाना मुझे बहुत मनमाना लगता है।

टीम ने 2.0 रिलीज़ के लिए बहुत सारी सुविधाएँ हटा दीं। मैं ईमानदारी से उन सभी से सहमत हूं। बस यही नहीं।

जवाब देने के लिए आपका धन्यवाद।

rhyek 1 अक्तू॰ 2016

@ktsn $broadcast और $dispatch के विकल्प बहुत सरल हैं, इस निष्कासन में सुधार आया है और बेहतर हुआ है।

vinicius73 1 अक्तू॰ 2016

1. निहित युग्मन।

उदाहरण:

// parent
events: {
  'some-event': function () { ... }
}

// deeply nested child:
$dispatch('some-event')

2. घटना के नाम

// parent
events: {
  'close': function () { ... }
}

// deeply nested child 1:
$dispatch('close')
// deeply nested child 2:
$dispatch('close')

मैं वास्तव में बस यही चाहता हूं कि आपने किसी भी प्रतिमान का उपयोग करने के लिए *विकल्प * को नहीं लिया,

LinusBorg 4 अक्तू॰ 2016

👍2

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

cnweibo 5 अक्तू॰ 2016

@cnweibo मुझे लगता है कि दोनों पक्षों में बहुत विस्तृत तर्क हैं, और ईमानदारी से मैं "अलग-अलग चीजों को संबोधित करने" के बारे में आपकी बात नहीं देखता। आगे तर्क करने के लिए स्वतंत्र महसूस करें, लेकिन मैं आपको निश्चित रूप से बता सकता हूं कि ऐसा नहीं होगा।

यदि आप वास्तव में इसे वास्तव में चाहते हैं, तो इसे स्वयं एक प्लगइन के रूप में लागू करना इतना कठिन नहीं है।

yyx990803 5 अक्तू॰ 2016

@LinusBorg मैं वास्तव में आपके उत्तर लिखने में

आप कहते हैं कि आपको $प्रेषण और $प्रसारण पसंद है

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

आपको अपनी घटनाओं को नाम देने में बहुत स्पष्ट होना होगा

मैं इससे सहमत हूं और वैसे भी मैं आमतौर पर यही करता हूं। यह वही है जो लोग jQuery पर करने के आदी हैं। इसके अलावा, कुछ प्लेटफ़ॉर्म केवल हैंडलर को तर्क के रूप में "स्रोत" ऑब्जेक्ट भेजते हैं और आप शायद उसके आधार पर संदर्भ फ़िल्टर कर सकते हैं (संकेत: instanceof )। उदाहरण के लिए, DOM ईवेंट में event.target उपलब्ध हैं। अन्य प्लेटफार्मों को स्थिर प्रकारों के साथ काम करने का लाभ होता है, इसलिए इस "संघर्ष" का सामना करना बहुत कठिन है (एक घटना एक वर्ग का एक उदाहरण है)।

किसी भी मामले में, मैं ईमानदारी से समझ नहीं पा रहा हूं कि यह VueJS टीम के लिए इतनी चिंता का विषय क्यों है। अगर लोग $dispatch का उपयोग करने के बारे में पर्याप्त सावधानी नहीं बरत सकते हैं, तो मुझे यकीन है कि आप अपनी लाइब्रेरी का उपयोग करके बहुत सी अन्य चीजें पा सकते हैं जो वे गलत कर रहे हैं। आप अपने उपयोगकर्ताओं को लापरवाह होने से "रक्षा" करने के लिए कितनी दूर जाएंगे?

यह ठीक है जब माता-पिता के पास केवल एक सीधा बच्चा होता है - लेकिन उस स्थिति में, टेम्पलेट में श्रोता के साथ $emit() कोई वास्तविक अतिरिक्त काम नहीं है, या तो ..

ईमानदार सवाल (जैसा कि मैं निश्चित रूप से Vue के लिए नया हूं), हर स्तर पर श्रोताओं को घोषित करने के अलावा, क्या आपको श्रृंखला के प्रत्येक घटक पर $emit घटना भी नहीं करनी है? यह बहुत कष्टप्रद लगता

अंत में, मैं नई परियोजनाओं (https://github.com/vuejs/vue-cli/issues/123#issuecomment-233071630) के लिए "आधिकारिक टेम्पलेट्स" शुरू करने के बारे में vue-cli पर किसी मुद्दे पर किसी ने कहा है:

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

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

यदि आप वास्तव में इसे वास्तव में चाहते हैं, तो इसे स्वयं एक प्लगइन के रूप में लागू करना इतना कठिन नहीं है।

@yyx990803 शायद यही _I'll_ अंत कर रहा है... शायद।

rhyek 5 अक्तू॰ 2016

@LinusBorg भी:

इसलिए, हम "ग्लोबल बस" पद्धति के साथ इसे प्राप्त करने का एक रास्ता छोड़ते हुए, उपयोगकर्ताओं को उन समझौतों तक ले जाने का प्रयास करते हैं जो हमें सबसे अच्छा काम करते हैं।

आप "चलाने की कोशिश" नहीं कर रहे हैं, आप मजबूर कर रहे हैं। :)

rhyek 5 अक्तू॰ 2016

क्या आपने एक ही सुविधा को dispatch और एक EventBus विधियों दोनों के साथ लागू करने का प्रयास किया है?
यह मदद कर सकता है

posva 5 अक्तू॰ 2016

@posva मैं योजना बना रहा हूं, लेकिन मेरा मतलब है, आप मूल रूप से किसी मॉड्यूल पर ईवेंट बस ऑब्जेक्ट घोषित करते हैं, और आप इसे कहीं और आयात करते हैं $emit , नहीं? मुझे यह पसंद नहीं है, टीबीएच। मैं निश्चित रूप से कुछ चीजों के लिए इसका उपयोग करूंगा, लेकिन मेरा दृढ़ विश्वास है कि यह वह नहीं है जो मैं हर बार करना चाहता हूं।

rhyek 5 अक्तू॰ 2016

किसी भी मामले में, मैं ईमानदारी से समझ नहीं पा रहा हूं कि यह VueJS टीम के लिए इतनी चिंता का विषय क्यों है। अगर लोग $dispatch का उपयोग करने के बारे में पर्याप्त सावधानी नहीं बरत सकते हैं,

खैर, मुद्दा यह है कि टीम में कोई भी $dispatch() लिए वास्तविक जीवन के उपयोग के मामले को इंगित नहीं कर सकता है जिसमें यह अन्य समाधानों के लिए बेहतर था (न केवल $emit() , बल्कि एक बस भी, या वैश्विक स्थिति), और हमने इसके बारे में अनगिनत फ़ोरम पोस्टों में से कोई भी नहीं देखा, जिसका हमने उत्तर दिया था।

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

इस बिंदु पर, मैं एक वास्तविक उदाहरण पर चर्चा करने के लिए अपने प्रस्ताव को नवीनीकृत करना चाहता हूं।

मुझे यकीन है कि आप अपनी लाइब्रेरी का उपयोग करके बहुत सी अन्य चीजें पा सकते हैं जो वे गलत कर रहे हैं। आप अपने उपयोगकर्ताओं को लापरवाह होने से "रक्षा" करने के लिए कितनी दूर जाएंगे?

यह निश्चित रूप से एक नाजुक सवाल है और खोजने के लिए एक कठिन संतुलन है। हमें केस-दर-मामले का न्याय करना होगा।

यह ठीक है जब माता-पिता के पास केवल एक सीधा बच्चा होता है - लेकिन उस स्थिति में, टेम्पलेट में श्रोता के साथ $emit() कोई वास्तविक अतिरिक्त काम नहीं है, या तो ..
ईमानदार सवाल (जैसा कि मैं निश्चित रूप से Vue के लिए नया हूं), हर स्तर पर श्रोताओं को घोषित करने के अलावा, क्या आपको श्रृंखला के प्रत्येक घटक पर $emit घटना भी नहीं करनी है? यह बहुत कष्टप्रद लगता है।

चूंकि मैं सीधे माता-पिता-बाल-रिलीजशिप के बारे में बात करता हूं, इसलिए आपको केवल एक बार $emit() करना होगा।

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

इसलिए, हम "ग्लोबल बस" पद्धति के साथ इसे प्राप्त करने का एक रास्ता छोड़ते हुए, उपयोगकर्ताओं को उन समझौतों तक ले जाने का प्रयास करते हैं जो हमें सबसे अच्छा काम करते हैं।
आप "चलाने की कोशिश" नहीं कर रहे हैं, आप मजबूर कर रहे हैं। :)

मैं कहूंगा कि हम आपके जीवन को थोड़ा कठिन बनाते हैं - आप कर सकते हैं

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

हम आपको $emit() का उपयोग करने के लिए मजबूर नहीं कर रहे हैं, हम बस इसके चारों ओर अपना रास्ता थोड़ा कठिन बना रहे हैं।

LinusBorg 5 अक्तू॰ 2016

मुझे लगता है कि आप इसे प्रत्येक Vue उदाहरण में भी जोड़ सकते हैं: Vue.prototype.$bus = new Vue()
कुछ पसंद नहीं करना बहुत रचनात्मक नहीं है...
मुझे आपके उदाहरणों की प्रतीक्षा रहेगी

posva 5 अक्तू॰ 2016

@posva

मुझे लगता है कि आप इसे हर Vue इंस्टेंस में भी जोड़ सकते हैं: Vue.prototype.$bus = new Vue()

मुझे वह पसंद है। बहुत चालाक।

कुछ पसंद नहीं करना बहुत रचनात्मक नहीं है

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

मुझे आपके उदाहरणों की प्रतीक्षा रहेगी

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

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

मुझे वास्तव में वू पसंद है। मैं बस इसे _प्यार_ करना चाहता हूं, तुम्हें पता है?

rhyek 5 अक्तू॰ 2016

क्या आपको प्रत्येक घटक पर $emit घटना भी नहीं करनी है

यदि आप ईवेंट बबलिंग के संदर्भ में सोचते हैं तो आप ऐसा करते हैं। और यदि आप घटक संरचना का उपयोग नहीं करते हैं।

जैसे:

<div>
  <a-button @click="modalShown = true">Open modal</a-button>
  <a-modal v-if="modalShown">
    <a-button @click="modalShown = false">Close modal</a-button>
  </a-modal>
</div>

a-modal घटक को a-button घटक की घटनाओं की परवाह करने की आवश्यकता नहीं है, क्योंकि दोनों a-modal और दो a-button उदाहरण एक ही उदाहरण के "प्रत्यक्ष तार्किक बच्चे" हैं , नेस्टिंग के साथ जटिल दृश्य पदानुक्रम होने के बावजूद।

simplesmiler 5 अक्तू॰ 2016

मुझे लगता है कि मैं इस समय खुद को दोहरा रहा हूं। मैं किसी तरह इस मुद्दे को हल कर दूंगा। यह मेरे लिए अजीब लगता है कि यह चर्चा कई कामकाज को कुछ मानक और व्यावहारिक बताते हुए घूमती है जो कि किसी भी कारण से मौजूद नहीं है।

@LinusBorg :

खैर, मुद्दा यह है कि टीम में कोई भी $ प्रेषण() के लिए वास्तविक जीवन उपयोगकेस को इंगित नहीं कर सकता है जिसमें यह अन्य समाधानों के लिए बेहतर था (न केवल $emit()

यह मुझे ऐसा लगता है जैसे कोई सिविल इंजीनियर मुझसे राजमार्ग से बाहर निकलने को बंद न करने का कारण पूछ रहा हो:

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

मैं कहता हूँ, "ठीक है, ज़रूर, आप इसे बंद कर सकते हैं, यह बढ़िया है। मुझे अगले ऑफ-रैंप के लिए बस 10 किमी आगे जाना होगा। मैं संभाल लूँगा।"

:) आपके उत्तरों के लिए सभी का धन्यवाद। मुझे खुशी है कि आप सभी चर्चा के लिए खुले हैं, कम से कम। एक अच्छी टीम लगती है।

rhyek 5 अक्तू॰ 2016

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

मैं अपना खराब रूपक भी जोड़ूंगा। :) मेरे विचार में यह अधिक पसंद है:

"यह सड़क लोगों को उनकी तुलना में तेज़ दौड़ने के लिए प्रोत्साहित करती है। गति सीमा पर शायद ही कभी ध्यान दिया जाता है। हमें लोगों को धीमा करने के लिए मजबूर करने के लिए कुछ बंपर जोड़ना चाहिए।"
"लेकिन मैं तेजी से अपने गंतव्य पर जल्दी पहुंचना पसंद करता हूं!"
"निश्चित रूप से, यह आपको कुछ बार अच्छी तरह से सर्वर कर सकता है, लेकिन हम सड़क के इस हिस्से को 1.5 वर्षों से लगातार देखते हैं, और दुर्घटनाओं की मात्रा और अगले ऑफ-रैंप को याद करने वाले लोगों की संख्या बस इसके लायक नहीं है, क्योंकि कई ड्राइवर हैं जिनके पास है उन समस्याओं में से एक ने प्रमाणित किया है।"
"लेकिन मुझे वे बंपर पसंद नहीं हैं!"
ठीक है, 99% गंतव्यों के लिए, यह दूसरी सड़क उतनी ही तेज़ है जितनी यह बंपर से पहले थी, बस इसे लें।
"लेकिन मुझे यह दूसरी सड़क पसंद नहीं है! दृश्य उतना अच्छा नहीं है!"
...

कुछ पसंद नहीं करना बहुत रचनात्मक नहीं है
मुझे लगता है कि कम से कम मेरे लिए कुछ का उपयोग करने या न करने के लिए यह एक बहुत ही वैध मानदंड है। किसी भी मामले में, मैंने कई बार कहा है कि मुझे क्यों लगता है कि ईवेंट बबलिंग का स्थान है।

मुझे लगता है कि @posva का मतलब था: "मुझे यह पसंद है" एक रचनात्मक तर्क नहीं है जब कुछ को रखने के लिए या उपयोगकर्ताओं की एक विस्तृत श्रृंखला के साथ पुस्तकालय में कुछ जोड़ने के लिए चर्चा की जाती है। इसलिए मैं व्यक्तिगत प्राथमिकताओं के बजाय चर्चा करने के लिए एक वैध, वास्तविक जीवन के उपयोग के मामले की मांग करता रहता हूं।

LinusBorg 5 अक्तू॰ 2016

हाँ, सिवाय इसके कि आपने पूरी तरह से अच्छे राजमार्ग को उड़ा दिया और रबरयुक्त डामर के साथ एक और बनाया क्योंकि आपने कहीं पढ़ा है कि यह बहुत साफ है। साथ ही, यह अतिरिक्त 10 किमी है। :)

उदाहरण के बारे में: मुझे लगता है कि रिकर्सिव घटकों के बारे में मूल प्रश्न पर पोस्ट किया गया एक ठीक है। ज़रा सोचिए कि जब कोई घटना पकड़ी जाती है तो आप हर स्तर पर कुछ करना चाहते हैं और आपके पास एक अच्छा उदाहरण है। $ प्रेषण के साथ ऐसा करना बहुत सीधा है।

rhyek 5 अक्तू॰ 2016

आप कोड देखना चाहते हैं?

जी कहिये

posva 5 अक्तू॰ 2016

@posva मैंने पिछली टिप्पणी पर एक उदाहरण दिया था। नोट: यदि आपको कुछ सेकंड से अधिक समय तक सोचना है कि बिना $ प्रेषण के इसे कैसे किया जाए, तो यह मेरी बात को साबित करता है।

rhyek 5 अक्तू॰ 2016

उदाहरण के बारे में: मुझे लगता है कि रिकर्सिव घटकों के बारे में मूल प्रश्न पर पोस्ट किया गया एक ठीक है। ज़रा सोचिए कि जब कोई घटना पकड़ी जाती है तो आप हर स्तर पर कुछ करना चाहते हैं और आपके पास एक अच्छा उदाहरण है। $ प्रेषण के साथ ऐसा करना बहुत सीधा है।

$dispatch()

// recursive-child
<template>
  <recursive-child></recursive-child>
  <button @click="dispatch">Do something</button>
<template>

<script>
  export default{
    methods: {
      dispatch() { this.$dispatch('do-something') }
    },
    events: {
      'do-something': function () { 
         // do something, or don't
         return true // nessessary to make the event bubble up further. Don't like the un-expressivness of this
       }
    }
  }
</script>

$emit()

// recursive-child
<template>
  <recursive-child @do-something="doSomething"></recursive-child>
  <button @click="doSometing">Do something</button>
<template>

<script>
  export default{
    methods: {
      doSomething() {
        // do someting, or don't
        this.$emit('do-something')
      }
    }
  }
</script>

क्या यह वाकई बदतर है?

एक और मिला? :)

LinusBorg 5 अक्तू॰ 2016

यकीनन ठीक। क्या होगा यदि वे पुनरावर्ती नहीं हैं फिर भी उस तरह नेस्टेड हैं?

ठीक है। यहाँ सुबह के 5 बज रहे हैं और मैं आपका धन्यवाद करने के लिए एक कठिन दिन बिताने जा रहा हूँ। अगर मैं बाद में कुछ बेहतर लेकर आता हूं तो मैं इसे पोस्ट करूंगा यदि नहीं, तो, या तो आप जीत गए हैं या मैंने रुचि खो दी है :)

rhyek 5 अक्तू॰ 2016

क्या होगा यदि वे पुनरावर्ती नहीं हैं फिर भी उस तरह नेस्टेड हैं?

आपको प्रत्येक टेम्पलेट में @event= श्रोता जोड़ना होगा $emit() , और $dispatch() लिए ऐसा नहीं है, यह इसके बारे में है।

यह अच्छा या बुरा देखा जा सकता है, इस पर निर्भर करता है कि आप क्रियात्मकता बनाम अभिव्यंजना पर जोर देते हैं।

और बीटीडब्ल्यू। यदि किसी स्थिति में आपको माता-पिता तक किसी घटना को श्रृंखलाबद्ध करना है तो ऐसा कुछ किया जा सकता है:

<child-comp @event="$emit('event', $arguments)>

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

वैसे भी, अच्छी चर्चा, अपनी अच्छी नींद का आनंद लें।

LinusBorg 5 अक्तू॰ 2016

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

यह भी ध्यान दें कि DOM इवेंट बबलिंग मूल रूप से क्रॉस-कंपोनेंट कम्युनिकेशन से अलग है। यह तर्क कि "ईवेंट बबलिंग व्यापक रूप से मान्यता प्राप्त है" का अर्थ यह नहीं है कि यह उस समस्या का एक अच्छा समाधान होना चाहिए जिसे हम हल करने का प्रयास कर रहे हैं।

मैंने इस धागे में टिप्पणी करना समाप्त कर दिया है क्योंकि मुझे "मुझे यह पसंद नहीं है" के साथ बहस करना मुश्किल लगता है।

yyx990803 5 अक्तू॰ 2016

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

सबसे उपयोगी टिप्पणी

1. निहित युग्मन।

2. घटना के नाम

सभी 41 टिप्पणियाँ

`$dispatch` और `$broadcast` के मूल्यह्रास से कैसे निपटें?

1. निहित युग्मन।

2. घटना के नाम

संबंधित मुद्दों

सबसे उपयोगी टिप्पणी

1. निहित युग्मन।

2. घटना के नाम

सभी 41 टिप्पणियाँ

$dispatch और $broadcast के मूल्यह्रास से कैसे निपटें?

1. निहित युग्मन।

2. घटना के नाम

संबंधित मुद्दों

`$dispatch` और `$broadcast` के मूल्यह्रास से कैसे निपटें?