Vue: هل يجب أن يحافظ vuejs2.0 على $ بث ، و $ dispatch event api؟ لا يوجد حل جيد لمعالجة النقطة لتوجيه الاتصال بين الوالدين والطفل في الإصدار 2.0

لأنه مناقشة عامة للمقترح ، لم أقم بصنع كمان بعد. إذا كان ذلك مطلوبًا ، فأنا أرغب في الإنشاء للتوضيح.
شكرا ~!

تم بالفعل تبرير هذا في 2.0 التغييرات

هذه نسخة:

كيف تتعامل مع إهمال $dispatch و $broadcast ؟

السبب وراء إهمالنا $dispatch و $broadcast هو أن تدفقات الأحداث التي تعتمد على بنية شجرة المكونات قد يكون من الصعب تفسيرها عندما تصبح شجرة المكونات كبيرة (ببساطة: لا مقياس جيد في التطبيقات الكبيرة ولا نريد أن نهيئك للألم لاحقًا). لا يحل $dispatch و $broadcast أيضًا الاتصال بين مكونات الأشقاء. بدلاً من ذلك ، يمكنك استخدام نمط مشابه لـ EventEmitter في Node.js : محور حدث مركزي يسمح للمكونات بالاتصال ، بغض النظر عن مكان

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 ، شكرًا على معلوماتك. يعمل محور الناقل حقًا بشكل جيد في نقطة مكونة واحدة بسيطة لاتصال نقطة مكون واحد. إذا كان هناك العديد من المكونات بنفس نوع المكون ، فستكون هناك مشكلة ، للأسف ، هذه حالة طبيعية. في كثير من الحالات ، ما أريد استخدام الحدث هو تحديث بيانات صغيرة تنتمي إلى بعض المكونات المحددة. لا يوفر تنفيذ ناقل الحدث الحالي معلومات عن الوجهة أو عقدة البداية (لقد رأيت _uid لكل مكون ، ربما يمكننا استخدام هذا _uid الفريد لأسلاك الحدث؟) ، لذلك لا يمكن لـ vuejs2.0 دعم اتصال حدث من نقطة إلى نقطة في الواقع . على وجه الدقة ، يدعم ناقل الحدث vuejs2.0 نوع المكون فقط للاتصال بنوع المكون؟ هل هناك حل بسيط لمعالجة هذا المطلب: يتم تشغيله بواسطة حدث في الشجرة وتحديث بياناته الخاصة
يعد vuex أمرًا رائعًا لإدارة بيانات الحالة الثابتة العالمية على مستوى التطبيق ، ولكن كما أفهم ، ربما لا يكون جيدًا لإدارة بيانات المكونات المحلية المحددة؟
المزيد من التفكير مرحب به في هذه القضية.

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

هل هناك حل بسيط لمعالجة هذا المطلب: يتم تشغيله بواسطة 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 OWN DATA_
يعد vuex أمرًا رائعًا لإدارة بيانات الحالة الثابتة العالمية على مستوى التطبيق ،
ولكن كما أفهم ، قد لا يكون ذلك جيدًا لبيانات مكون محلية محددة
إدارة؟

المزيد من التفكير مرحب به في هذه القضية.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/vuejs/vue/issues/3581#issuecomment -244008699 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFTLl1bjHqWTVDAkr8Fqbx0WiTuH16n2ks5qlooBgaJpZM4JyUfJ
.

سأغلق الآن هذه القضية ، لأن

1. تم توفير الحلول و
2. مشكلات Github ليست المكان المناسب لطلب الدعم على أي حال (راجع الإرشادات)

@ ktsn ، شكرًا على
fnlctrl ، سأقضي المزيد من الوقت في ما يسمى بإدارة حالة vuex المعيارية

شكرا مرة أخرى ~!

في رأيي ، ليست هناك حاجة إلى البث $ ، فقط تدفق بيانات الدعائم المتساقطة.
يمكن إعادة تنفيذ أي إرسال بالدولار باعتباره v-on أحادي المستوى و $ ينبعث مثل هذا (في Vue 1):
<child-component @select="$emit('select', $arguments[0])" /> لكل مكون معني
في أي حالة أخرى ، يجب استخدام حافلات الأحداث المخصصة

حقًا ، يعمل v-on على علامة المكون للحدث المخصص على المكون نفسه أيضًا مع $ emit من المكون نفسه.

cnweibo للتسجيل ، يمكن استرجاع بيانات الحدث.

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

لكن لا يمكن استرجاع بيانات الحدث في vuejs2.0

بالتأكيد ، ما الذي يجعلك تفكر بخلاف ذلك؟

تضمين التغريدة
تضمين التغريدة
آسف ، لدي سوء فهم وأجعل الأمور غير واضحة. في النمط fnlctrl المتوفر ، يمكن حقًا استرداد جميع البيانات الموجودة في معالج الحدث الخاص به حتى مع

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

نسخ / لصق تعليقي الخاص من مشكلة أخرى: https://github.com/vuejs/vue/issues/2760#issuecomment -250883407

أعتقد أن إزالة $ dispatch كانت فكرة سيئة. لم تكن هذه أول مكتبة / إطار عمل لواجهة المستخدم تنفذ مفهوم الإجراءات / الأحداث الفقاعية في الشجرة المرئية. إنها فكرة راسخة. لماذا تستبعد هذه الوظيفة على أساس أن "القدرة على إرسال حدث يسبب آثارًا جانبية في الشجرة الأم غير المعروفة يبدو وكأنه وصفة مشكلة بالنسبة لي"؟ أنت بحاجة إلى ترك هذه المسؤولية للمستخدمين. أنا متأكد من أن معظمهم لديهم الحس السليم لاستخدام هذه الميزة بشكل مناسب. إنه ليس بمفهوم جديد!

لا أستطيع حقًا رؤية فائدة هذا التغيير عندما تكون هذه المكتبة مبنية على تقنيات / مفاهيم الويب الراسخة منذ فترة طويلة مثل أحداث DOM و DOM التي تقوم في الواقع بظهور الشجرة المرئية وقد ظلت تفعل ذلك لسنوات بدون أحد يشكو. أليست فكرة المكونات شيئًا تم تبنيه مؤخرًا بفضل اقتراح W3C لمكونات الويب؟ في رأيي ، من المنطقي أن تتصرف مكونات Vue بشكل مشابه لعناصر DOM العادية فيما يتعلق بكيفية معالجة الحدث.

يبدو البديل المقترح لاستخدام حافلة الأحداث العالمية غير منطقي بالنسبة لي عندما يكون هناك شيء أكثر عملية وفعالية وأسهل للفهم (نظرًا لكونه مفهومًا راسخًا لسنوات).

تذكرني المقترحات الأخرى في هذا الموضوع كيف تريد EmberJS القيام بذلك. تمرير إجراءات الإغلاق كخصائص للمكونات أسفل كل مستوى من مستويات التسلسل الهرمي. مملة جدا وغير ضرورية! كان Vuejs هو السبب في أنني كتبت https://www.npmjs.com/package/ember-component-action-bubbling!

بصرف النظر عن هذا ، أنا حقًا أحب مكتبتك. لكن بجدية ، أعتقد أن هذا كان تغييرًا رهيبًا.

تم اقتراح نموذج ناقل الحدث فقط كحل للقيام بنفس الشيء بالضبط ، عندما تكون الهندسة القائمة على الحدث في كثير من الأحيان أقل شأنا من العمارة التصريحية القائمة على الدولة.

لنفترض أن لديك تطبيقًا حيث يمكن للمستخدم تسجيل الدخول. باستخدام حل قائم على الحدث:

1. استمع إلى حدث تسجيل الدخول
2. أطلق الحدث لاحقًا باستخدام اسم المستخدم وكلمة المرور
3. قم بالرد على الحدث المذكور وفقًا لذلك في أي مكونات تستمع إليها

هذا يأتي مع بعض المشاكل. يتمثل العامل الأكبر في أن المكونات التي لا يتم عرضها في DOM عند إطلاق الحدث لن تتلقى التغيير ، إلى جانب عدم معرفتك بأجزاء التطبيق التي ستتلقى الحدث على الإطلاق. بالإضافة إلى ذلك ، لا يمكن لمتلقي الحدث معرفة المكان الذي يأتي منه الحدث دون تقديم معلومات إضافية. عذرًا لغتي ، لكن هذا هو عنق الرحم الهائل الذي تعاملت معه ولا أهتم باستخدامه مرة أخرى.

لذلك دعونا نستخدم نهجًا مفعمًا بالحالة:

1. قم بإنشاء متغير حالة عالمي يمثل معلومات حساب المستخدم. إنه null عند تسجيل الخروج ، ويحتوي على معلومات تسجيل دخول المستخدم عند تسجيل الدخول.
2. عندما يقوم المستخدم بتسجيل الدخول ، قم بتعيين معلومات الحساب.

كل شيء في التطبيق يعتمد على متغير الحالة هذا يتم تحديثه وفقًا لذلك. لا توجد أحداث ، ولا يهم متى أو مكان إنشاء المكون ، لأنه سيعرض دائمًا المعلومات الصحيحة. يمكنك استخدام حدث لتحديث الحالة العالمية ، ولكن لماذا تفعل ذلك بينما يمكنك فقط ... تحديثها؟

يتيح لك الأسلوب التعريفي كتابة مكوناتك بطريقة تظهر دائمًا بنفس الطريقة اعتمادًا على الحالة المحلية / العالمية تمامًا بغض النظر عما يفعله المستخدم في التطبيق الخاص بك ، دون الحاجة إلى الاستماع إلى الأشياء التي تحدث. أعتقد أن هذا هو ما كان يقصده Vue طوال الوقت ، ولكن على غرار معظم الأشياء في تطوير البرمجيات ، فقد استغرقنا بعض الوقت لمعرفة ذلك. لكنني سعيد للغاية لأننا فعلنا ذلك.

تحرير: أوه ، ولا تنس أنه يمكنك مشاهدة المعلمات ، على سبيل المثال ، إرسال طلب AJAX ، أو القيام ببعض الإجراءات الأخرى عندما تتغير. على سبيل المثال ، بعد أن يقوم المستخدم بتسجيل الدخول ، شاهد متغير "loggedIn" ، عندما يكون صحيحًا ، قم بتحميل صور ملفه الشخصي ، أو شيء من هذا القبيل.

أنا أفهم ما تقوله ، لكن وجود بعض المكونات العشوائية يعدل الحالة العالمية ، على ما أعتقد ، هو نفس الشيء مثل وجود هذا المكون العشوائي في حدث يعرف الله أين. لا تزال تواجه نفس المخاطر المتمثلة في "تلوث" تدفق تطبيقك عن طريق الخطأ.

هناك طرق للتعامل مع كلا النموذجين بطريقة نظيفة وهذا عادة (ويجب) أن ينتهي به الأمر إلى كونه مسؤولية مستخدم إطار العمل.

ستكون هناك مواقف معينة تكون فيها إحدى الآليات أكثر منطقية من الأخرى. على سبيل المثال ، أوافق على أن حالة تسجيل الدخول يجب أن تكون شيئًا معروفًا للتطبيق بأكمله: الحالة العالمية منطقية. لكن الزر الذي ينقر عليه مستخدم التطبيق لن يتعامل عادةً مع المنطق الكامن وراء تسجيل دخول المستخدم فعليًا. سيكون هذا شيئًا يتم التعامل معه في أعلى السلسلة. قد يكون مكونًا ، قد يكون مسارًا. من المحتمل أن الزر سيحتاج فقط إلى إخطار شيء ما بقصد تسجيل الدخول. وبالتالي ، لا يحتاج الزر إلى تعديل حالتك العامة مباشرةً.

الآن ، مع إزالة $ dispatch ، تحتاج إلى مكون الزر للتعرف على بعض الكائنات العامة التي تدير جلسة مستخدم التطبيق وإخطارها مباشرة بالنية. هذا يجعل الزر مقترنًا بإحكام بالتطبيق بأكمله.

أو ، قد يكون لديك الزر متداخلاً بعمق 10 مستويات وعليك أن تعلن عن معالج v-on:login في كل مستوى حتى تصل النية إلى مصيرها. غير ضروري على الإطلاق.

في الواقع ، الاضطرار إلى القيام بـ v-on على كل مستوى يجعل الحفاظ على شفرتك أكثر صعوبة.

حسنًا ، من الواضح أن مجرد تغيير الحالة بشكل مباشر يمكن أن يكون مشكلة ، لكن Vuex يحل هذه المشكلة بالطفرات والأفعال. وصحيح أن بعض الحلول ستناسب القانون بشكل أفضل من غيرها ، لكنني لم أواجه موقفًا لم يكن فيه المنطق التصريحي هو الخيار الأفضل.

في حالتك المحددة ، ربما لا أقوم بإنشاء زر محدد لتسجيل الدخول ، هههه. في الإضافة ، إذا كان المكون المرتبط بتسجيل الدخول متداخلًا بهذا العمق لسبب ما ، فما عليك سوى تغيير حالته العالمية.

كان زر تسجيل الدخول مجرد مثال. ومتجر vuex هو ما كنت أشير إليه عندما ذكرت "بعض الأشياء العالمية". سأضطر إلى النظر في كيفية عمل vuex ، لكنني أتوقع أنك تقترن بإحكام بعض المكونات العشوائية ببقية حالة تطبيقك من خلال الاضطرار ببساطة إلى إدارة مرجع إلى المتجر.

هذا غير مرغوب فيه ، على سبيل المثال ، إذا كان زر تسجيل الدخول جزءًا من مكتبة تابعة لجهة خارجية.

أتمنى حقًا ألا تزيل * _اختيار * _ لاستخدام أي من النموذجين ، خاصةً عندما يتم التعرف على فقاعات الحدث على نطاق واسع وبالتالي يسهل فهمها للمساهمين الجدد في المشروع.

يعتمد ذلك على ما تقصده بـ "بعض المكونات العشوائية" ، لأن مكون عرض جهاز التوجيه ، على سبيل المثال ، له حقوق كاملة للوصول إلى المتجر والالتزام به في رأيي. ومع ذلك ، إذا كان مكونًا أصغر لإعادة استخدامه ، مثل زر أو نموذج أو بعض عناصر واجهة المستخدم الأخرى ، 9 مرات من أصل 10 ، فلا ينبغي أن يكون هناك أي سبب منطقي للوصول إلى المتجر ، أكثر من استخدام الخاصيات والأحداث.

نظرًا لأن البيانات في تطبيق Vue تكون من أعلى إلى أسفل ، فأنت تريد الاحتفاظ بأكبر قدر ممكن من دولتك المحلية على أعلى مستوى ممكن. التعشيش العميق في حد ذاته مشكلة يجب تجنبها قدر الإمكان. ليس من المثير للقلق نشر الأحداث على مستويين لأسفل ، ولكن هناك احتمالات ، قد تحتاج إلى إعادة التفكير في هيكل القالب الخاص بك إذا كان يتعمق أكثر من ذلك.

هذا في الغالب ظل. في كثير من الأحيان ، تكون النماذج التي يسهل فهمها هي تلك التي ينتهي بها الأمر بالتعرض للإساءة حتى نهاية الجحيم وتصبح غير عملية. النهج القائم على الدولة أكثر وضوحًا ، كما اتفق عليه معظمنا الذين يستخدمون حاليًا 2.0. أنت حر في الاستمرار في استخدام 1.0 ، أو الانتقال إلى إطار عمل آخر إذا لم يكن هذا النهج هو المفضل لديك.

9 مرات من أصل 10 ، لا ينبغي أن يكون هناك أي سبب منطقي لدخوله إلى المتجر ، باستخدام الدعائم والأحداث.

بالضبط وجهة نظري.

التعشيش العميق في حد ذاته مشكلة يجب تجنبها قدر الإمكان

في بعض الأحيان ، هذا ليس خيارًا.

ليس هناك الكثير من العناء لنشر الأحداث على مستويين

ليس صحيحًا عندما تتعمق هذه المستويات.

أسهل النماذج للفهم هي تلك التي ينتهي بها الأمر بالتعرض للإساءة حتى نهاية الجحيم وتصبح غير عملية

يجب أن يكون هذا الأمر متروكًا لانضباط المستخدمين لديك.

أنت حر في الاستمرار في استخدام 1.0 ، أو الانتقال إلى إطار عمل آخر إذا لم يكن هذا النهج هو المفضل لديك.

ممك.

البساطة والراحة هما السبب في أنني كنت أفكر في التبديل من Ember إلى Vue. $dispatch هو أحد الأشياء التي استمتعت بها حول Vue ويبدو أن إزالته تعسفية للغاية بالنسبة لي.

قام الفريق بإزالة الكثير من الميزات لإصدار 2.0. أنا بصراحة أتفق معهم جميعًا. فقط ليس هذا.

أشكركم على الردود الخاصة بك.

إن بدائل وتحسنت .

rhyek أود أن أعطي 2 بإثارتها . نظرًا لأن المناقشة قد تجاوزت بالفعل عددًا من الموضوعات ، أود العودة إلى الأساسيات حول سبب إهمالنا $ diospatch و $ broacast:

1. اقتران ضمني.

إذا كان لديك أحد الوالدين وطفل متداخل بعمق يرسل حدثًا ، فلا توجد طريقة لاستنتاج هذه العلاقة من الكود (وينطبق الشيء نفسه على $broadcast ، بشكل بيضوي).

إذا نظرت إلى التغييرات وعمليات الإهمال الأخرى التي قدمناها مع Vue 2.0 ، فقد تدرك أن إزالة السلوك الضمني لصالح البدائل الصريحة هو موضوع شائع ، وإيقاف $dispatch يناسب هناك.

مثال:

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

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

هذا على ما يرام عندما يكون الوالد لديها طفل واحد فقط مباشر - ولكن في هذه الحالة، $emit() مع المستمع في القالب هو أي عمل إضافي حقيقي، إما.

يصبح من الصعب متابعتها (خاصة في الفرق) بمجرد أن يكون لديك أطفال متداخلين (خاصة متداخلين بعمق) ، أو حتى أكثر من طفل مباشر - عليك إما النظر من خلال جميع الأطفال ، أو الاعتماد على تعليقات الكود لتوثيق الحدث الذي هو tiggered من أي مكون فرعي - وهو نموذج مرجعي إضافي أيضًا.

أنت تقول إنك تحب الإرسال و $ البث لأنك لست مضطرًا لتمريرهما عبر مكونات أخرى. ويمكنني أن أتفق على أنه أسهل - لكننا لم نواجه العديد من المواقف التي كان فيها هذا ضروريًا بالفعل ، أو بالأحرى: إذا كان هناك مثل هذه السلسلة من تفويت حدث ما ، فمن الأفضل تغيير البيانات / تم إلحاقه / خلال هذه الرحلة بواسطة مكون بينهما.

2. أسماء الأحداث

عندما تستخدم $dispatch مع مكونات متداخلة بشدة ، يجب أن تكون واضحًا جدًا في تحديد تباعد أسماء الأحداث الخاصة بك ، وإلا فقد تكون متضاربة:

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

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

.. وإذا كان هؤلاء الأطفال هم أطراف ثالثة ، فقد تم تفكيكهم الآن. أو تضطر إلى اللحاق بالحدث في بعض المكونات في المنتصف فقط لإعادة تسميته قبل أن تصل إلى الوالد $dispatch() . ولا تنس التعليق على هذا ، لأن شخصًا ما ينظر إلى هذا الرمز قد يفكر في سبب عدم قيامك بأي شيء آخر مع حدث غير إعادة تسميته.

لا توجد هذه المشكلة عند استخدام $ emit و template listeners. يمكنك استخدام أسماء أحداث بسيطة وقصيرة في كل مكان ، ولن تتعارض لأن كل حدث يحتوي على رد اتصال خاص به مرفق في القالب @close="callback ".

أتمنى حقًا ألا تلغي * الاختيار * لاستخدام أي من النموذجين ،

إذا اعتقدنا أن كلا النموذجين يمكن أن يعملان بشكل جيد ، فسنعاملهما على قدم المساواة. لكننا لا نعتقد ذلك ، للأسباب المذكورة أعلاه وأكثر.

لذلك ، نحاول توجيه المستخدمين نحو الاتفاقيات التي وجدنا أنها تعمل بشكل أفضل ، مع ترك طريقة للالتفاف حولها باستخدام طريقة "Global Bus".

أود أيضًا أن أتحدث عن مخاوفك بشأن الحالة العالمية ، لكني لست متأكدًا من أنني أفهم موقفك تمامًا حتى الآن.

ربما يمكنك تقديم مثال حيث تعتقد أن $ dispatch و $ البث يعملان بشكل أفضل بالنسبة لك ، وأحاول أن أوضح لك كيف يمكن لنهجنا "الخاص بنا" تحسين الموقف؟

أعتقد أن إرسال $ / $ بث وحافلة الحدث تعالج أشياء مختلفة. يمكنهم تسهيل الحفاظ على التعليمات البرمجية وفصلها في سيناريوهات مختلفة. إذا استطعنا الاحتفاظ بهما معًا ، فسيكون ذلك رائعًا.
من الصعب جدًا القول إن أحدًا أفضل من الآخر في كل حالة.

cnweibo أعتقد أنه كانت هناك حجج شاملة للغاية من كلا الجانبين ، وبصراحة لا أرى وجهة نظرك حول "معالجة أشياء مختلفة". لا تتردد في تقديم المزيد من الحجج ، لكن يمكنني أن أخبرك بالتأكيد أن هذا لن يحدث.

إذا كنت تريده حقًا ، فليس من الصعب تنفيذه بنفسك كمكوِّن إضافي.

LinusBorg أقدر حقًا الوقت الذي استغرقته لكتابة ردك وأتفهم حججك.

أنت تقول أنك تحب الإرسال و $ البث

أنا فقط أحب $dispatch ، بصراحة. بدا لي $broadcast غريبًا بالتأكيد. كما قلت ، $dispatch هو مجرد حدث فاضح وهو شيء موجود في كل مكان بين العديد من المنصات في هذه المرحلة. $broadcast ... ليس كثيرًا. الشيء الوحيد المشابه الذي واجهته هو أحداث "المعاينة" في WPF والتي تقترن بأحداث عادية. إنهم "ينفقون" أسفل الشجرة المرئية من أعلى عنصر إلى مصدر الحدث الأصلي ، لكن يتم إرسالهم فقط أسفل سلسلة العناصر ذات الصلة مباشرةً ولا ينتشرون في كل شيء.

يجب أن تكون واضحًا جدًا في تحديد تباعد أسماء الأحداث الخاصة بك

أنا أتفق مع ذلك وهو عادة ما أفعله على أي حال. إنه أيضًا ما اعتاد الناس فعله على jQuery. علاوة على ذلك ، ترسل بعض الأنظمة الأساسية كائن "مصدر" كوسيطة إلى المعالج ويمكنك ربما تصفية السياقات بناءً على ذلك (تلميح: instanceof ). أحداث DOM لديها event.target متاحًا ، على سبيل المثال. تتمتع الأنظمة الأساسية الأخرى بميزة العمل مع الأنواع الثابتة ، لذا من الصعب جدًا مواجهة هذا "الصدام" (الحدث هو مثيل لفئة).

على أي حال ، أنا بصراحة لا أفهم سبب قلق فريق VueJS بهذا القدر. إذا لم يستطع الأشخاص توخي الحذر الكافي بشأن استخدام $dispatch ، فأنا متأكد من أنه يمكنك العثور على الكثير من الأشياء الأخرى التي يفعلونها بشكل خاطئ باستخدام مكتبتك. إلى أي مدى ستذهب إلى "حماية" المستخدمين من الإهمال؟

هذا جيد عندما يكون للوالد طفل واحد مباشر فقط - ولكن في هذه الحالة ، لا يعد $ emit () مع المستمع في القالب عملاً إضافيًا حقيقيًا ، أيضًا ..

سؤال صادق (لأنني جديد تمامًا على Vue) ، بصرف النظر عن إعلان المستمعين على كل مستوى ، ألا يتعين عليك أيضًا أن تقوم بـ $emit الحدث على كل مكون في السلسلة؟ هذا يبدو مزعج جدا

في الختام ، اسمحوا لي أن أقتبس شيئًا قاله أحدهم حول مشكلة على vue-cli حول تقديم "قوالب رسمية" للمشاريع الجديدة (https://github.com/vuejs/vue-cli/issues/123#issuecomment-233071630):

كما تعلم على الأرجح أنك لست مقيدًا بالقوالب الرسمية. يمنحك هذا الحرية ولكن في نفس الوقت يتسبب في أنك بحاجة إلى اتخاذ المزيد من القرارات بنفسك.

أعتقد أن كل شيء في النهاية مجرد متر من التوازن. كم عدد هذه القرارات التي يمكننا اتخاذها مقدمًا لجميع (معظم) مستخدمينا وكم عدد أو أي منها يريد المستخدمون القيام به بمفردهم.

أتفق مع هذه الفلسفة ، لكنها ليست نفس الموقف الذي واجهته بشأن هذه المسألة ، بشكل غريب. التناقض الذي أراه بين هذا التعليق والتعليقات هنا يتلخص في الحرية. أنت تستبعد الخيارات التي تستند إلى النوايا المعيبة في النهاية ، على الرغم من أنها جيدة.

إذا كنت تريده حقًا ، فليس من الصعب تنفيذه بنفسك كمكوِّن إضافي.

@ yyx990803 ربما هذا ما سأقوم به في نهاية المطاف ... ربما.

LinusBorg أيضا:

لذلك ، نحاول توجيه المستخدمين نحو الاتفاقيات التي وجدنا أنها تعمل بشكل أفضل ، مع ترك طريقة للالتفاف حولها باستخدام طريقة "Global Bus".

أنت لا تحاول التوجيه ، أنت تجبر. :)

هل حاولت تطبيق نفس الميزة مع كل من الطريقتين dispatch و EventBus؟
قد يساعد

posva أخطط لذلك ، لكن أعني ، أنك تعلن أساسًا عن كائن ناقل الحدث في بعض الوحدات ، وتقوم باستيراده في أي مكان آخر تريده إلى $emit ، أليس كذلك؟ أنا لا أحب ذلك ، tbh. سأستخدمه بالتأكيد لبعض الأشياء ، لكنني أعتقد بشدة أن هذا ليس ما أريد القيام به في كل مرة.

على أي حال ، أنا بصراحة لا أفهم سبب قلق فريق VueJS بهذا القدر. إذا لم يستطع الأشخاص توخي الحذر الكافي بشأن استخدام $dispatch ،

حسنًا ، النقطة المهمة هي أنه لا يمكن لأي شخص في الفريق أن يشير إلى حالة استخدام واقعية مقابل $dispatch() حيث كانت مفضلة على الحلول الأخرى (ليس فقط $emit() ، ولكن أيضًا حافلة ، أو global state) ، ولم نر أي مشاركات في المنتدى التي لا حصر لها والتي أجبنا عليها أيضًا.

قد تكون هذه وجهة نظر ذاتية ، ولكن ربما يمكنك أن تفهم أنه إذا كان الفريق بأكمله يعتقد أن "هذا ، في تجربتنا ، دائمًا حل أدنى" ، فإننا نتخلى عنه من الجوهر.

في هذه المرحلة ، أريد تجديد عرضي لمناقشة مثال حقيقي.

أنا متأكد من أنه يمكنك العثور على الكثير من الأشياء الأخرى التي يفعلونها بشكل خاطئ باستخدام مكتبتك. إلى أي مدى ستذهب إلى "حماية" المستخدمين من الإهمال؟

هذا بالطبع سؤال دقيق ويصعب إيجاد توازن. سيتعين علينا أن نحكم في القضية من خلال القضية.

هذا جيد عندما يكون للوالد طفل واحد مباشر فقط - ولكن في هذه الحالة ، لا يعد $ emit () مع المستمع في القالب عملاً إضافيًا حقيقيًا ، أيضًا ..

سؤال صادق (لأنني جديد تمامًا على Vue) ، بصرف النظر عن إعلان المستمعين على كل مستوى ، ألا يتعين عليك أيضًا إرسال الحدث على كل مكون في السلسلة؟ هذا يبدو مزعج جدا

نظرًا لأنني أتحدث عن الارتباطات المباشرة بين الوالدين والطفل ، فسيتعين عليك فقط إصدار $ () مرة واحدة.

إذا كان لديك أطفال متداخلين بعمق ، فعليك بالطبع إعادة الإرسال على كل مستوى ، ولكن لأكرر نفسي: لم نجد ولم يتم عرض المواقف التي تم إرسالها عبر العديد من الأطفال المتداخلين ، فهي ضرورية حقًا أو مفضلة على الحلول الأخرى.

لذلك ، نحاول توجيه المستخدمين نحو الاتفاقيات التي وجدنا أنها تعمل بشكل أفضل ، مع ترك طريقة للالتفاف حولها باستخدام طريقة "Global Bus".

أنت لا تحاول التوجيه ، أنت تجبر. :)

أود أن أقول إننا نجعل حياتك أصعب قليلاً - يمكنك ذلك

• استخدم الحافلة ، وهي ليست نفس الشيء ولكن يمكن أن تحقق سلوكًا مشابهًا في معظم الحالات.
• إعادة تنفيذ هذا كمكوِّن إضافي بسهولة تامة.

نحن لا نجبرك على استخدام $emit() ، نحن فقط نجعل طريقك أكثر صعوبة.

أعتقد أنه يمكنك أيضًا إضافته إلى كل مثيل Vue: Vue.prototype.$bus = new Vue()
عدم الإعجاب بشيء ليس بناء للغاية ...
سأكون في انتظار الأمثلة الخاصة بك 😄

posva

أعتقد أنه يمكنك أيضًا إضافته إلى كل مثيل Vue: Vue.prototype. $ bus = new Vue ()

أحب ذلك. ذكي جدا.

عدم الإعجاب بشيء ليس بناء للغاية

أعتقد أن هذه معايير صالحة جدًا لاختيار استخدام شيء ما أم لا ، على الأقل بالنسبة لي. على أي حال ، لقد ذكرت عدة مرات لماذا أعتقد أن فقاعة الحدث لها مكانها.

سأكون في انتظار الأمثلة الخاصة بك 😄

أعني ، هل أنا حقا بحاجة إلى ذلك؟ لقد قدمت أمثلة حول المواقف التي لا أحب فيها فكرة استخدام حافلة الحدث أو إعلان المستمعين في كل مستوى. تريد أن ترى رمز؟ ربما يمكنني أن أتوصل إلى شيء ما لتوضيح وجهة نظري قليلاً ، لكنني أشعر بأن حدث فقاعات هو أمر قياسي يمكن لمعظم الناس تقديره باعتباره شيئًا مفيدًا ، كما أن حافلات الأحداث أو مديري الدولة ، على الأقل بالنسبة لي ، نوع من نقلة نوعية تبدو وكأنها منطقة هيبستر ، على الرغم من عدم صعوبة فهمها بأي شكل من الأشكال. 😄

أنا بالطبع أمزح بشأن هذا التعليق الأخير. كما ذكرت من قبل ، أرى استخداماتهم وسوف أجد بالتأكيد مشكلة لحلها. في الواقع ، في بعض المشاريع التي عملت عليها باستخدام Ember ، أميل إلى كتابة "خدمة" تعمل تمامًا مثل مدير دولة عالمي. أؤكد لك ، أنا لا أحاول أن أكون عنيدًا بشأن هذا عن قصد.

أنا حقا أحب Vue. أنا فقط أريد أن _أحب ذلك ، هل تعلم؟

لا يتعين عليك أيضًا إرسال الحدث على كل مكون

أنت تفعل إذا كنت تفكر من حيث فقاعات الحدث. وأنت لا تفعل ذلك إذا كنت تستخدم تكوين المكون.

على سبيل المثال:

<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 عبارة عن "توابع منطقية مباشرة" لمثيل واحد ، على الرغم من وجود عرض هرمي معقد مع التداخل.

أعتقد أنني أكرر نفسي في هذه المرحلة. سأنتهي في العمل على حل هذه المشكلة ، بطريقة أو بأخرى. يبدو الأمر غريبًا بالنسبة لي أن هذه المناقشة تدور حول ذكر العديد من الحلول لشيء معياري وعملي إلى حد ما لم يعد موجودًا بعد الآن لأي سبب من الأسباب.

LinusBorg :

حسنًا ، النقطة المهمة هي أنه لا يمكن لأي شخص في الفريق أن يشير إلى حالة استخدام واقعية لـ $ dispatch () حيث كانت مفضلة على الحلول الأخرى (ليس فقط ينبعث من $ ()

هذا يبدو لي وكأن مهندسًا مدنيًا يطلب مني سببًا لعدم إغلاق مخرج الطريق السريع:

يقول شيئًا مثل ، "يؤدي هذا المنحدر إلى تقاطع حيث يشعر الناس بالارتباك بشأن ما إذا كانوا سيتجهون إلى اليسار أو اليمين. يعرف معظم الناس الطريق لأنهم عاشوا هنا منذ سنوات ، ولكن غالبًا ما يضيع المواطنون الجدد لبضع دقائق ونريد تجنب ذلك ".

أقول ، "حسنًا ، بالتأكيد ، يمكنك إغلاقها ، هذا رائع. سأضطر فقط إلى السفر مسافة 10 كيلومترات أبعد من المنحدر التالي. سأتمكن من ذلك."

:) شكرا لكم جميعا على الردود الخاصة بك. أنا سعيد لأنكم جميعًا منفتحون على المناقشة ، على الأقل. يبدو وكأنه فريق جيد.

هذا يبدو لي وكأن مهندسًا مدنيًا يطلب مني سببًا لعدم إغلاق مخرج الطريق السريع:

يقول شيئًا مثل ، "يؤدي هذا المنحدر إلى تقاطع حيث يشعر الناس بالارتباك بشأن ما إذا كانوا سيتجهون إلى اليسار أو اليمين. يعرف معظم الناس الطريق لأنهم عاشوا هنا منذ سنوات ، ولكن غالبًا ما يضيع المواطنون الجدد لبضع دقائق ونريد تجنب ذلك ".

سأضيف أيضًا الطريقة السيئة الخاصة بي. :) من وجهة نظري ، فإن الأمر أشبه بما يلي:

• "هذا الطريق يشجع الناس على التسابق بشكل أسرع مما ينبغي. ونادرًا ما يتم الاهتمام بحدود السرعة. يجب أن نضيف بعض المصدات لإجبار الناس على الإبطاء."
• "لكني أحب أن أصل إلى وجهتي بسرعة عن طريق السرعة!"
• "بالتأكيد ، قد يخدمك جيدًا عدة مرات ، لكننا نلاحظ هذا الجزء من الطريق باستمرار لأكثر من 1.5 عام ، ومقدار الحوادث والأشخاص الذين يفقدون المنحدر التالي لا يستحق كل هذا العناء ، كما فعل العديد من السائقين وقد شهد على واحدة من تلك المشاكل ".
• "لكني لا أحب تلك المصدات!"
• حسنًا ، بالنسبة لـ 99٪ من الوجهات ، يكون هذا الطريق الآخر بنفس السرعة التي كان عليها قبل المصدات ، فقط اسلك هذا الطريق.
• "لكنني لا أحب هذا الطريق الآخر! المنظر ليس لطيفًا!"
• ...

عدم الإعجاب بشيء ليس بناء للغاية

أعتقد أن هذه معايير صالحة جدًا لاختيار استخدام شيء ما أم لا ، على الأقل بالنسبة لي. على أي حال ، لقد ذكرت عدة مرات لماذا أعتقد أن فقاعة الحدث لها مكانها.

أعتقد أن posva تعني: "أحب هذا" ليس حجة بناءة عند مناقشة إما الاحتفاظ بشيء ما ، أو إضافة شيء إلى المكتبة مع مجموعة واسعة من المستخدمين. لهذا السبب أستمر في طلب حالة استخدام صالحة وواقعية للمناقشة بدلاً من التفضيلات الشخصية.

نعم ، إلا أنك فجرت الطريق السريع الجيد تمامًا وبنيت آخرًا بإسفلت مطاطي لأنك تقرأ في مكان ما إنه أنيق جدًا. أيضا ، إنها 10 كم إضافية. :)

حول المثال: أعتقد أن السؤال المنشور على السؤال الأصلي حول المكونات العودية جيد. فقط تخيل أنك تريد أن تفعل شيئًا ما على كل مستوى بالتسلسل عند اكتشاف حدث ولديك مثال جيد تمامًا. القيام بذلك باستخدام $ إيفاد هو أمر بسيط جدًا.

تريد أن ترى رمز؟

نعم من فضلك

posva لقد أعطيت مثالاً على التعليق السابق. ملاحظة: إذا كان عليك التفكير لأكثر من بضع ثوانٍ في كيفية القيام بذلك دون إرسال $ ، فهذا يثبت وجهة نظري.

حول المثال: أعتقد أن السؤال المنشور على السؤال الأصلي حول المكونات العودية جيد. فقط تخيل أنك تريد أن تفعل شيئًا ما على كل مستوى بالتسلسل عند اكتشاف حدث ولديك مثال جيد تمامًا. القيام بذلك باستخدام $ إيفاد هو أمر بسيط جدًا.

بـ $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>

هل هذا حقا أسوأ؟

هل لديك واحدة أخرى؟ :)

حسنا بالتأكيد. ماذا لو لم تكن متكررة ولكنها لا تزال متداخلة هكذا؟

على ما يرام. إنها الخامسة صباحًا هنا وسأحظى بيوم عصيب شكرًا لك. إذا توصلت إلى شيء أفضل لاحقًا ، فسأنشره إذا لم يكن كذلك ، فإما أنك ربحت أو فقدت الاهتمام :)

ماذا لو لم تكن متكررة ولكنها لا تزال متداخلة هكذا؟

يجب عليك إضافة مستمع @event= في كل قالب مقابل $emit() ، وليس كذلك لـ $dispatch() ، هذا كل ما في الأمر.

يمكن رؤية هذا جيدًا أو سيئًا ، اعتمادًا على إما أن تشدد على الإسهاب مقابل التعبير.

و راجع للشغل. إذا اضطررت في موقف ما إلى ربط حدث ما حتى يمكن للوالد القيام بشيء مثل:

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

• سوف تحزن على "الاقتران" الذي يحدث بين المكونات.
• سأثني على التعبير
• بخلاف ذلك ، فإن الكتابة أكثر قليلاً ولكنها ليست مشكلة كبيرة.
• وما زلت أدعي ، مع مثال حقيقي لحالة الاستخدام ، أنه من المحتمل أن يكون هناك تحسين مختلف متاح ، مثل متجر عالمي - لكن هذا يعتمد على السيناريو الفردي ويصعب الجدال مع مثال الكود.

على أي حال ، مناقشة لطيفة ، استمتع بنومك الذي تستحقه.

rhyek يبدو وكأنه حلول $dispatch في المقام الأول ، لكن هذا ليس الهدف. الهدف هو السماح للمكونات بالتواصل مع بعضها البعض مع إمكانية الصيانة اللائقة. عند تحقيق هذا الهدف ، فإن $dispatch هو الحل الأدنى عندما تقوم بإدراج جميع الإيجابيات والسلبيات العملية ، باستثناء التفضيلات ، لذلك قمنا بإسقاطها.

لاحظ أيضًا أن حدث DOM الفقاعي يختلف اختلافًا جوهريًا عن الاتصال عبر المكونات. الحجة القائلة بأن "فقاعة الحدث معترف بها على نطاق واسع" لا تعني أنه يجب أن يكون حلاً جيدًا للمشكلة التي نحاول حلها.

لقد انتهيت من التعليق في هذا الموضوع لأنني أجد صعوبة في الجدال مع "أنا فقط لا أحب ذلك".