Vue: sollte vuejs2.0 die $broadcast, $dispatch Event-API beibehalten? Keine gute Lösung für die Punkt-zu-Punkt-Eltern-Kind-Kommunikation in 2.0

Da es sich um eine allgemeine Vorschlagsdiskussion handelt, habe ich noch keine Fiddle erstellt. Wenn es erforderlich ist, würde ich gerne erstellen, um zu demonstrieren.
danke~!

Dies wurde bereits bei den 2.0 Änderungen begründet

Hier ist eine Kopie:

Wie gehe ich mit der Einstellung von $dispatch und $broadcast ?

Der Grund, warum wir $dispatch und $broadcast liegt darin, dass Ereignisflüsse, die von der Struktur des Komponentenbaums abhängen, schwer nachvollziehbar sein können, wenn der Komponentenbaum groß wird (einfach ausgedrückt: Er ist nicht in großen Apps gut skalieren und wir möchten Sie später nicht auf Schmerzen einstellen). $dispatch und $broadcast lösen auch nicht die Kommunikation zwischen Geschwisterkomponenten. Stattdessen können Sie ein Muster ähnlich dem EventEmitter in Node.js verwenden : ein zentralisierter Event Hub, der es Komponenten ermöglicht, zu kommunizieren, unabhängig davon, wo sie sich in der Komponentenstruktur befinden. Da Vue-Instanzen die Ereignis-Emitter-Schnittstelle implementieren, können Sie zu diesem Zweck tatsächlich eine leere Vue-Instanz verwenden:

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) {
 // ...
})

Dieses Muster kann in einfachen Szenarien als Ersatz für $dispatch und $broadcast . Für komplexere Fälle wird jedoch empfohlen, mit Vuex eine dedizierte

Das in der Upgrade-Anleitung gezeigte Beispiel ist das gleiche, über das Sie sprechen

Über rekursive Kommunikation: Mehrere Komponenten können auf dasselbe Ereignis hören. Dieses Ereignis wird von den gemeinsamen Eltern erkannt, damit jedes Kind sich dessen bewusst sein kann

@posva , danke für deine Informationen. Der Bus-Hub funktioniert wirklich gut bei der einfachen Punkt-zu-Einzelkomponenten-Punktkommunikation. Wenn es mehrere Komponenten mit demselben Komponententyp gibt, gibt es Probleme, dies ist leider ein Normalfall. In vielen Fällen möchte ich ein Ereignis verwenden, um kleine Daten zu aktualisieren, die zu einer bestimmten Komponente gehören. Die aktuelle Event-Bus-Implementierung gibt keine Informationen zum Ziel- oder Ursprungsknoten (ich habe die _uid jeder Komponente gesehen, vielleicht können wir diese einzigartige _uid für die Ereignisverkabelung verwenden?), daher kann vuejs2.0 die Punkt-zu-Punkt-Ereigniskommunikation tatsächlich nicht unterstützen . Um genau zu sein, unterstützt der vuejs2.0-Ereignisbus nur die Kommunikation von Komponententyp zu Komponententyp? Gibt es eine einfache Lösung, um diese Anforderung zu erfüllen: durch ein Ereignis im Baum ausgelöst und SEINE EIGENEN DATEN aktualisieren
vuex ist großartig für das globale statische Datenmanagement auf Anwendungsebene, aber wie ich verstehe, ist es möglicherweise nicht gut für das Datenmanagement bestimmter lokaler Komponenten?
Weitere Überlegungen zu diesem Thema sind willkommen.

@cnweibo Ich habe Ihre Frage mit einem Beispiel im Forum beantwortet. Ich denke, dieses Beispiel wird Ihre Anforderungen erfüllen.
http://forum.vuejs.org/topic/4832/vue2-0-event-bus-issue-how-to-deliver-event-to-parent-when-the-same-multiple-parent-children-in- dom/6

Gibt es eine einfache Lösung, um diese Anforderung zu erfüllen: ausgelöst durch a
Ereignis im Baum und aktualisieren SEINE EIGENEN DATEN

Dies wird durch einfach vuex gelöst, ohne ein kompliziertes Ereignissystem.

vuex eignet sich hervorragend für das globale statische Datenmanagement auf Anwendungsebene.
aber wie ich verstehe, ist es für bestimmte lokale Komponentendaten möglicherweise nicht gut
Verwaltung

„lokal“ bedeutet nur eine einzelne Komponente. Ihr Anwendungsfall verwaltet den Zustand übergreifend
mehrere Komponenten, also global.
Und vuex kann Module (Zustandsunterbäume) haben, also ist es keine 'globale Variable'
irgendwie "global". Sie können Komponentengruppen mit ihren eigenen vuex ansteuern
Module.

Diese ganze Diskussion "Ereignisse vs. geteilte Staaten" ist seit Monaten beigelegt
vor, und die Schlussfolgerung ist, entweder den globalen Ereignisbus oder vuex zu verwenden. Also würde ich
empfehlen Ihnen, mehr über vuex und seine Funktionsweise zu lesen.

Am Do, 1. September 2016, 16:17 Uhr schrieb cnweibo [email protected] :

@posva https://github.com/posva , danke für deine Informationen. der Bus
Hub funktioniert wirklich gut in einfachen Einzelkomponenten-Punkten zu Einzelkomponenten
Punkt Kommunikation. Wenn mehrere Komponenten mit derselben Komponente vorhanden sind
geben, wird es ein Problem geben, das ist leider ein Normalfall. Viele
In Fällen möchte ich ein Ereignis verwenden, um kleine Daten zu aktualisieren, die zu einigen gehören
spezifische Komponente. Die aktuelle Event-Bus-Implementierung gibt nicht an
Informationen zum Ziel- oder Ursprungsknoten (ich habe _uid von jedem gesehen
Komponente, vielleicht können wir diese einzigartige _uid für die Ereignisverkabelung verwenden? ), so
vuejs2.0 kann die Punkt-zu-Punkt-Ereigniskommunikation tatsächlich nicht unterstützen. Zu sein
exakt, vuejs2.0 Event Bus unterstützt nur Komponententyp zu Komponententyp
Kommunikation? Gibt es eine einfache Lösung für diese Anforderung:
ausgelöst durch ein Ereignis im Baum und aktualisiere _ITS EIGENE DATEN_
vuex eignet sich hervorragend für das globale statische Datenmanagement auf Anwendungsebene.
aber wie ich verstehe, ist es für bestimmte lokale Komponentendaten möglicherweise nicht gut
Verwaltung?

Weitere Überlegungen zu diesem Thema sind willkommen.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/vuejs/vue/issues/3581#issuecomment -244008699 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFTLl1bjHqWTVDAkr8Fqbx0WiTuH16n2ks5qlooBgaJpZM4JyUfJ
.

Ich werde dieses Thema jetzt schließen, denn

1. Lösungen wurden bereitgestellt und
2. Github-Probleme sind sowieso nicht der richtige Ort, um um Support zu bitten (siehe Richtlinien)

@ktsn , danke für deine Demo-Geige. Genau das möchte ich eine einfache Lösung!
@fnlctrl , ich werde mehr Zeit mit dem sogenannten modularen Vuex-Zustandsmanagement verbringen

danke nochmal~!

Meiner Meinung nach wird $broadcast nicht benötigt, nur fallende Requisiten des Datenflusses.
Jeder $dispatch kann wie folgt als einstufiges v-on und $emit implementiert werden (in Vue 1):
<child-component @select="$emit('select', $arguments[0])" /> für jede beteiligte Komponente
In allen anderen Situationen sollten benutzerdefinierte Ereignisbusse verwendet werden

Wirklich, das v-on auf dem Komponenten-Tag für benutzerdefinierte Ereignisse auf der Komponente selbst funktioniert auch mit $emit von der Komponente selbst.

@cnweibo Für die Aufzeichnung können die Ereignisdaten abgerufen werden.

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

Aber die Ereignisdaten können in vuejs2.0 nicht abgerufen werden

Klar kann es das, was lässt Sie anders denken?

@fnlctrl
@LinusBorg
Entschuldigung, ich habe ein Missverständnis und mache die Dinge nicht klar. im bereitgestellten Muster @fnlctrl , kann wirklich alle Daten in seinem Event-Handler abrufen, sogar mit

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

Kopieren/Einfügen meines eigenen Kommentars aus einer anderen Ausgabe: https://github.com/vuejs/vue/issues/2760#issuecomment -250883407

Ich denke, das Entfernen von $dispatch war eine schreckliche Idee. Dies war nicht das erste UI-Framework/die erste Bibliothek, die das Konzept der sprudelnden Aktionen/Ereignisse in einem visuellen Baum implementiert hat. Es ist eine gut etablierte Idee. Warum diese Funktionalität unter der Prämisse wegnehmen, dass "in der Lage zu sein, ein Ereignis auszulösen, das Nebenwirkungen in seinem unbekannten Stammbaum verursacht, klingt für mich wie ein Rezept für Ärger"? Diese Verantwortung müssen Sie den Benutzern überlassen. Ich bin sicher, die meisten haben den gesunden Menschenverstand, diese Funktion angemessen zu verwenden. Es ist kein neues Konzept!

Ich kann den Nutzen dieser Änderung wirklich nicht sehen, wenn diese Bibliothek auf langjährig etablierten Webtechnologien / -konzepten wie den DOM- und DOM-Ereignissen aufbaut, die tatsächlich im visuellen Baum sprudeln und dies seit Jahren ohne jemanden tun Jammern. Ist die Idee von Komponenten nicht etwas, das dank des W3C-Vorschlags für Webkomponenten in letzter Zeit aufgegriffen wurde? Meiner Meinung nach macht es nur Sinn, dass sich Vue-Komponenten in Bezug auf die Ereignisbehandlung ähnlich wie normale DOM-Elemente verhalten.

Die vorgeschlagene Alternative, einen globalen Ereignisbus zu verwenden, erscheint mir unlogisch, als es bereits etwas Praktischeres, Effektives und leichter Verständliches (da es sich um ein seit Jahren etabliertes Konzept handelt) gab.

Andere Vorschläge in diesem Thread erinnern mich daran, wie EmberJS es tun möchte. Übergeben von Abschlussaktionen als Eigenschaften an die Komponenten auf jeder Hierarchieebene. So langweilig und unnötig! Vuejs war der Grund, warum ich https://www.npmjs.com/package/ember-component-action-bubbling geschrieben habe!

Abgesehen davon gefällt mir deine Bibliothek sehr gut. Aber im Ernst, ich denke, das war eine schreckliche Veränderung.

Das Event-Bus-Paradigma wurde nur als Lösung vorgeschlagen, um genau dasselbe zu tun, wenn eine ereignisbasierte Architektur einer deklarativen, zustandsbasierten Architektur oft unterlegen ist.

Angenommen, Sie haben eine App, in die sich der Benutzer einloggen kann. Mit einer ereignisbasierten Lösung:

1. Ein Login-Ereignis anhören
2. Feuern Sie das Ereignis später mit dem Benutzernamen und dem Passwort ab
3. Reagieren Sie entsprechend auf das Ereignis in allen Komponenten, die zuhören

Dies ist jedoch mit einigen Problemen verbunden. Der größte Nachteil besteht darin, dass Komponenten, die beim Auslösen des Ereignisses nicht im DOM gerendert werden, die Änderung nicht erhalten, und Sie nicht wissen, welche Teile der Anwendung das Ereignis überhaupt erhalten. Außerdem können Empfänger des Ereignisses ohne zusätzliche Informationen unmöglich wissen, woher das Ereignis kommt. Entschuldigen Sie meine Sprache, aber das ist ein massiver Clusterfuck, mit dem ich zu tun hatte und den ich nicht wieder verwenden möchte.

Verwenden wir also einen zustandsbehafteten Ansatz:

1. Erstellen Sie eine globale Statusvariable, die Benutzerkontoinformationen darstellt. Es ist null wenn es abgemeldet ist, und enthält die Anmeldeinformationen des Benutzers, wenn es angemeldet ist.
2. Wenn sich der Benutzer anmeldet, legen Sie die Kontoinformationen fest.

Alles in der App, das auf diese Zustandsvariable angewiesen ist, wird entsprechend aktualisiert. Keine Ereignisse, und es spielt keine Rolle, wann oder wo die Komponente erstellt wird, da immer die richtigen Informationen angezeigt werden. Sie könnten ein Ereignis verwenden, um den globalen Status zu aktualisieren, aber warum tun Sie dies, wenn Sie es einfach ... aktualisieren können?

Ein deklarativer Ansatz ermöglicht es Ihnen, Ihre Komponenten so zu schreiben, dass sie abhängig vom lokalen/globalen Status immer gleich aussehen, unabhängig davon, was der Benutzer in Ihrer Anwendung tut, ohne auf die Vorgänge zu hören. Ich glaube, dafür war Vue die ganze Zeit gedacht, aber wie bei den meisten Dingen in der Softwareentwicklung haben wir eine Weile gebraucht, um das herauszufinden. Aber ich bin verdammt froh, dass wir das gemacht haben.

BEARBEITEN: Oh, und vergessen Sie nicht, dass Sie auf Parameter achten und beispielsweise eine AJAX-Anfrage senden oder eine andere Aktion ausführen können, wenn sie sich ändert. zB, nachdem sich ein Benutzer angemeldet hat, beobachten Sie die Variable 'loggedIn', wenn sie wahr ist, laden Sie ihre Profilbilder oder ähnliches.

Ich verstehe, was Sie sagen, aber eine zufällige Komponente, die den globalen Zustand verändert, ist meiner Meinung nach dasselbe, als wenn diese zufällige Komponente ein Ereignis an Gott weiß wohin hochbläst. Sie gehen immer noch das gleiche Risiko ein, dass der Fluss Ihrer Anwendung versehentlich "verschmutzt" wird.

Es gibt Möglichkeiten, beide Paradigmen sauber zu handhaben, und das wird (und sollte) normalerweise in der Verantwortung des Benutzers des Frameworks liegen.

Es wird bestimmte Situationen geben, in denen ein Mechanismus sinnvoller ist als der andere. Zum Beispiel stimme ich zu, dass ein eingeloggter Status Ihrer gesamten Anwendung bekannt sein sollte: globaler Status ist sinnvoll. Aber die Schaltfläche, auf die der Anwendungsbenutzer klickt, wird normalerweise nicht die Logik hinter der tatsächlichen Anmeldung des Benutzers verarbeiten. Das wird etwas höher in der Kette behandelt. Es kann eine Komponente sein, könnte eine Route sein. Die Schaltfläche muss wahrscheinlich nur etwas über die Absicht zur Anmeldung informieren. Die Schaltfläche muss daher Ihren globalen Status nicht direkt ändern.

Mit der Entfernung von $dispatch müssen Sie jetzt also die Schaltflächenkomponente über ein globales Objekt wissen, das die Benutzersitzung der Anwendung verwaltet, und sie direkt über die Absicht benachrichtigen. Dadurch ist die Schaltfläche eng mit Ihrer gesamten Anwendung verbunden.

Oder Sie haben die Schaltfläche 10 Ebenen tief verschachtelt und müssen auf jeder Ebene einen v-on:login Handler deklarieren, damit die Absicht ihr Ziel erreicht. Völlig unnötig.

Tatsächlich macht es Ihren Code nur schwieriger zu verwalten, wenn Sie v-on auf jeder Ebene ausführen müssen.

Nun, offensichtlich kann es problematisch sein, nur den Zustand direkt zu ändern, aber Vuex löst dieses Problem mit Mutationen und Aktionen. Und es stimmt, dass einige Lösungen besser passen als andere, aber ich habe noch nie eine Situation erlebt, in der deklarative Logik nicht die bessere Option war.

In deinem speziellen Fall würde ich wahrscheinlich einfach keine Schaltfläche speziell für das Anmelden erstellen, heh. Wenn eine anmeldungsbezogene Komponente aus irgendeinem Grund so tief verschachtelt ist, lassen Sie sie einfach den globalen Zustand mutieren.

Der Login-Button war nur ein Beispiel. Und einen Vuex-Store meinte ich, als ich "ein globales Objekt" erwähnte. Ich müsste mir die Funktionsweise von vuex ansehen, aber ich gehe davon aus, dass Sie eine zufällige Komponente eng mit dem Rest des Status Ihrer App koppeln, indem Sie einfach einen Verweis auf den Store verwalten müssen.

Dies ist nicht wünschenswert, wenn beispielsweise die Anmeldeschaltfläche Teil einer Bibliothek eines Drittanbieters war.

Ich wünschte wirklich nur, du würdest dir nicht die *_Entscheidung *_ nehmen, eines der beiden Paradigmen zu verwenden, besonders wenn Event-Bubbling weithin anerkannt und daher für neue Mitwirkende an einem Projekt leicht zu verstehen ist.

Es hängt davon ab, was Sie mit "irgendein zufällige Komponente" meinen, da beispielsweise eine Router-View-Komponente meiner Meinung nach volle Zugriffs- und Zugriffsrechte auf den Store hat. Wenn es sich jedoch um eine kleinere Komponente zur Wiederverwendung handelt, z.

Da Daten in einer Vue-Anwendung von oben nach unten gespeichert werden, möchten Sie so viel wie möglich von Ihrem lokalen Bundesstaat auf oberster Ebene behalten. Tiefe Verschachtelung an sich ist ein Problem, das so weit wie möglich vermieden werden sollte. Es ist nicht _so_ viel Mühe, Ereignisse zwei Ebenen tiefer zu propagieren, aber wahrscheinlich müssen Sie Ihre Vorlagenstruktur überdenken, wenn sie tiefer geht.

Das ist aber meistens eine Tangente. Oftmals sind die am einfachsten zu verstehenden Paradigmen diejenigen, die bis zum Ende der Hölle missbraucht werden und unhandlich werden. Ein zustandsbasierter Ansatz ist viel unkomplizierter, wie die meisten von uns, die derzeit 2.0 verwenden, zustimmen. Es steht Ihnen frei, 1.0 weiterhin zu verwenden oder zu einem anderen Framework zu wechseln, wenn dieser Ansatz nicht Ihren Wünschen entspricht.

In 9 von 10 Fällen sollte es keinen logischen Grund geben, auf den Store zuzugreifen, anstatt Requisiten und Ereignisse zu verwenden.

Genau mein Standpunkt.

Tiefe Verschachtelung an sich ist ein Problem, das so weit wie möglich vermieden werden sollte

Manchmal ist dies keine Option.

Es ist nicht so schwierig, Ereignisse zwei Ebenen tiefer zu propagieren

Nicht so wahr, wenn diese Ebenen tiefer gehen.

die leichter zu verstehenden Paradigmen sind diejenigen, die bis zum Ende der Hölle missbraucht werden und unhandlich werden

Dies sollte der Disziplin Ihrer Benutzer überlassen bleiben.

Es steht Ihnen frei, 1.0 weiterhin zu verwenden oder zu einem anderen Framework zu wechseln, wenn dieser Ansatz nicht Ihren Wünschen entspricht.

Mmk.

Einfachheit und Bequemlichkeit sind der Grund, warum ich überlegte, von Ember zu Vue zu wechseln. $dispatch ist eines der Dinge, die mir an Vue gefallen haben, und es scheint mir so willkürlich, es zu entfernen.

Das Team hat viele Funktionen für die Version 2.0 entfernt. Ich stimme allen ehrlich zu. Nur nicht dieser.

Vielen Dank für Ihre Antworten.

@ktsn Alternativen zu $broadcast und $dispatch sind sehr einfach, diese Entfernung hat sich verbessert und verbessert.

@rhyek Ich möchte meine 2ct über ein paar Punkte geben, die Sie angesprochen haben. Da die Diskussion bereits eine Reihe von Themen behandelt hat, möchte ich auf die Grundlagen zurückkommen, warum wir $diospatch und $broacast eingestellt haben:

1. implizite Kopplung.

Wenn Sie ein Elternteil und ein tief verschachteltes Kind haben, das ein Ereignis auslöst, gibt es keine Möglichkeit, diese Beziehung aus dem Code abzuleiten (und das gilt natürlich auch für $broadcast ).

Wenn Sie sich die anderen Änderungen und Verwerfungen ansehen, die wir mit Vue 2.0 eingeführt haben, werden Sie vielleicht feststellen, dass das Entfernen von implizitem Verhalten zugunsten expliziter Alternativen ein gängiges Thema ist und die Veraltung von $dispatch genau dort passt.

Beispiel:

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

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

Dies ist in Ordnung, wenn das Elternteil nur ein direktes Kind hat - aber in diesem Fall ist $emit() mit einem Listener in der Vorlage auch keine wirkliche zusätzliche Arbeit.

Es wird schwer (besonders in Teams) zu folgen, sobald Sie verschachtelte Kinder (besonders tief verschachtelte) oder sogar mehr als ein direktes Kind haben - Sie müssen entweder alle Kinder durchsehen oder sich auf Codekommentare verlassen, um zu dokumentieren, welches Ereignis es ist getriggert von welcher untergeordneten Komponente - das ist auch eine zusätzliche Boilerplate.

Sie sagen, dass Sie $dispatch und $broadcast mögen, weil Sie sie nicht durch andere Komponenten weiterleiten müssen. Und ich stimme zu, dass es einfacher ist - aber wir haben nicht viele Situationen erlebt, in denen dies tatsächlich notwendig war, oder besser gesagt: wenn es eine solche Kette des Überlassens eines Ereignisses gäbe, würden die Daten eher geändert / angehängt/während dieser Fahrt durch Komponente dazwischen.

2. Ereignisnamen

Wenn Sie $dispatch mit tief verschachtelten Komponenten verwenden, müssen Sie die Namensräume Ihrer Ereignisse sehr explizit angeben, da sie sonst kollidieren könnten:

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

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

..und wenn diese Kinder Bibliotheken von Drittanbietern sind, sind Sie jetzt am Arsch. oder Sie müssen das Ereignis in einer Komponente in der Mitte abfangen, nur um es umzubenennen, bevor Sie $dispatch() weiter zum übergeordneten Element gelangen. Und vergessen Sie nicht, dies zu kommentieren, denn jemand, der sich diesen Code ansieht, könnte denken, warum Sie mit einem Ereignis nichts anderes tun, als es umzubenennen.

Bei Verwendung von $emit- und Template-Listenern tritt dieses Problem nicht auf. Sie können überall einfache, kurze Ereignisnamen verwenden, sie kollidieren nicht, da jedes Ereignis seinen eigenen Rückruf hat, der in der Vorlage @close="callback " angehängt ist.

Ich wünschte wirklich nur, du hättest dir nicht die *Wahl* genommen, eines der beiden Paradigmen zu verwenden,

Wenn wir dachten, dass beide Paradigmen gleich gut funktionieren können, würden wir sie gleich behandeln. Aber das glauben wir nicht, aus den oben genannten Gründen und mehr.

Daher versuchen wir, die Benutzer zu den Verhaltensweisen zu führen, die unserer Meinung nach am besten funktionieren, und lassen gleichzeitig einen Weg, dies mit der "Global Bus"-Methode zu umgehen.

Ich möchte auch über Ihre Sorgen um den Weltstaat sprechen, bin mir aber nicht sicher, ob ich Ihre Position noch vollständig verstehe.

Vielleicht können Sie ein Beispiel nennen, bei dem $dispatch und $broadcast Ihrer Meinung nach am besten für Sie geeignet sind, und ich versuche Ihnen zu zeigen, wie "unser" Ansatz die Situation verbessern könnte?

Ich denke, dass $dispatch/$broadcast und Event Bus unterschiedliche Dinge ansprechen. Sie können Code leicht zu warten und in verschiedenen Szenarien entkoppeln. Wenn wir sie beide behalten können, wird es großartig.
Es ist sehr schwer zu sagen, dass einer in jedem Fall besser ist als der andere.

@cnweibo Ich denke, es gab auf beiden Seiten ziemlich erschöpfende Argumente, und ehrlich gesagt verstehe ich Ihren Standpunkt nicht, "unterschiedliche Dinge anzusprechen". Fühlen Sie sich frei, weitere Argumente vorzubringen, aber ich kann Ihnen mit Sicherheit sagen, dass dies nicht passieren wird.

Wenn Sie es wirklich wollen, ist es nicht so schwer, es selbst als Plugin zu implementieren.

@LinusBorg Ich schätze die Zeit, die Sie sich genommen haben, um Ihre Antwort zu schreiben, und ich verstehe Ihre Argumente.

Sie sagen, dass Sie $dispatch und $broadcast mögen

Ich mag nur $dispatch , ehrlich. $broadcast mir definitiv seltsam vor. Wie ich schon sagte, $dispatch ist nur Event-Blubbern, was derzeit auf vielen Plattformen allgegenwärtig ist. $broadcast ... nicht so sehr. Das einzige, was mir je begegnet ist, sind "Vorschau"-Ereignisse in WPF, die mit normalen Ereignissen gepaart sind. Sie "tunneln" den visuellen Baum vom obersten Element bis zur Quelle des ursprünglichen Ereignisses, aber sie werden nur direkt die Kette der verwandten Elemente hinuntergesendet und _verbreiten_ sich nicht auf alles.

Sie müssten bei der Namensgebung Ihrer Ereignisse sehr explizit sein

Dem stimme ich zu, und normalerweise tue ich es sowieso. Es ist auch das, was die Leute bei jQuery gewohnt sind. Darüber hinaus senden einige Plattformen einfach ein "Quell"-Objekt als Argument an den Handler und Sie könnten darauf basierend Kontexte filtern (Hinweis: instanceof ). DOM-Ereignisse haben beispielsweise event.target Verfügung. Andere Plattformen haben den Vorteil, dass sie mit statischen Typen arbeiten, so dass dieser "Zusammenstoß" ziemlich schwer zu treffen ist (ein Ereignis ist eine Instanz einer Klasse).

Auf jeden Fall verstehe ich ehrlich gesagt nicht, warum dies dem VueJS-Team so wichtig ist. Wenn die Leute bei der Verwendung von $dispatch nicht vorsichtig genug sein können, können Sie sicher noch viele andere Dinge finden, die sie bei der Verwendung Ihrer Bibliothek falsch machen. Wie weit werden Sie gehen, um Ihre Benutzer vor Nachlässigkeit zu "schützen"?

Dies ist in Ordnung, wenn das Elternteil nur ein direktes Kind hat - aber in diesem Fall ist $emit() mit einem Listener im Template auch keine wirkliche zusätzliche Arbeit.

Ehrliche Frage (da ich absolut neu bei Vue bin), abgesehen davon, dass Sie Zuhörer auf allen Ebenen deklarieren, müssen Sie nicht auch das Ereignis für jede Komponente in der Kette $emit ? Das scheint so nervig zu sein.

Lassen Sie mich abschließend etwas zitieren, was jemand zu einem Thema auf vue-cli über die Einführung von "offiziellen Vorlagen" für neue Projekte gesagt hat (https://github.com/vuejs/vue-cli/issues/123#issuecomment-233071630):

Wie Sie wahrscheinlich wissen, sind Sie nicht an offizielle Vorlagen gebunden. Dies gibt Ihnen Freiheit, führt aber gleichzeitig dazu, dass Sie mehr Entscheidungen selbst treffen müssen.

Ich denke, am Ende ist alles nur ein Meter Balance. Wie viele dieser Entscheidungen können wir für alle (die meisten) unserer Benutzer im Voraus treffen und wie viele oder welche möchten die Benutzer selbst treffen.

Ich stimme dieser Philosophie zu, aber es ist seltsamerweise nicht die gleiche Einstellung, die ich zu diesem Thema kennengelernt habe. Der Kontrast, den ich zwischen diesem Kommentar und den Kommentaren hier sehe, läuft auf Freiheit hinaus. Sie nehmen Entscheidungen weg, die auf zwar guten, aber letztendlich fehlerhaften Absichten basieren.

Wenn Sie es wirklich wollen, ist es nicht so schwer, es selbst als Plugin zu implementieren.

@ yyx990803 Das ist wahrscheinlich das, was _ich_ am Ende tun werde ... wahrscheinlich.

@ LinusBorg auch:

Daher versuchen wir, die Benutzer zu den Verhaltensweisen zu führen, die unserer Meinung nach am besten funktionieren, und lassen gleichzeitig einen Weg, dies mit der "Global Bus"-Methode zu umgehen.

Du "versuchst nicht zu lenken", du erzwingst. :)

Haben Sie versucht, dieselbe Funktion sowohl mit dispatch als auch mit einer EventBus-Methode zu implementieren?
Es kann helfen

@posva Ich habe vor, aber ich meine, Sie deklarieren das Ereignisbusobjekt im Grunde auf einem Modul und importieren es, wo immer Sie möchten, in $emit , nein? Ich mag das nicht, tbh. Ich werde es definitiv für einige Dinge verwenden, aber ich glaube fest daran, dass es nicht das ist, was ich jedes Mal tun möchte.

Auf jeden Fall verstehe ich ehrlich gesagt nicht, warum dies dem VueJS-Team so wichtig ist. Wenn die Leute bei der Verwendung von $dispatch nicht vorsichtig genug sein können,

Nun, der Punkt ist, dass niemand im Team einen realen Anwendungsfall für $dispatch() aufzeigen konnte, in dem es anderen Lösungen vorzuziehen war (nicht nur $emit() , sondern auch ein Bus, oder global state), und wir haben auch keine in den unzähligen Forenbeiträgen gesehen, die wir dazu beantwortet haben.

Dies mag eine subjektive Sichtweise sein, aber vielleicht können Sie verstehen, dass wir es aus dem Kern fallen lassen, wenn das gesamte Team denkt "dies ist unserer Erfahrung nach immer eine minderwertige Lösung".

An dieser Stelle möchte ich mein Angebot erneuern, um ein reales Beispiel zu diskutieren.

Ich bin mir sicher, dass Sie mit Ihrer Bibliothek noch viele andere Dinge finden können, die sie falsch machen. Wie weit werden Sie gehen, um Ihre Benutzer vor Nachlässigkeit zu "schützen"?

Dies ist natürlich eine heikle Frage und eine schwierige Balance zu finden. Wir werden von Fall zu Fall beurteilen müssen.

Dies ist in Ordnung, wenn das Elternteil nur ein direktes Kind hat - aber in diesem Fall ist $emit() mit einem Listener im Template auch keine wirkliche zusätzliche Arbeit.

Ehrliche Frage (da ich ganz neu bei Vue bin), abgesehen von der Angabe von Zuhörern auf allen Ebenen, müssen Sie das Ereignis nicht auch für jede Komponente in der Kette ausgeben? Das scheint so nervig zu sein.

Da ich von direkten Eltern-Kind-Beziehungen spreche, müssten Sie nur einmal $emit() ausführen.

Wenn Sie tief verschachtelte Kinder haben, müssen Sie natürlich auf jeder Ebene erneut emittieren, aber um mich zu wiederholen: Wir haben keine Situationen gefunden oder dargestellt, die über viele verschachtelte Kinder verteilt sind, die wirklich notwendig oder anderen Lösungen vorzuziehen sind.

Daher versuchen wir, die Benutzer zu den Verhaltensweisen zu führen, die unserer Meinung nach am besten funktionieren, und lassen gleichzeitig einen Weg, dies mit der "Global Bus"-Methode zu umgehen.

Du "versuchst nicht zu lenken", du erzwingst. :)

Ich würde sagen, wir machen dir das Leben ein bisschen schwerer - du kannst

• einen Bus verwenden, der nicht dasselbe ist, aber in den meisten Fällen ein ähnliches Verhalten erreichen kann.
• Implementieren Sie dies ganz einfach als Plugin.

Wir zwingen Sie nicht, $emit() , wir machen es Ihnen nur etwas schwieriger.

Ich denke, Sie können es auch zu jeder Vue-Instanz hinzufügen: Vue.prototype.$bus = new Vue()
Etwas nicht zu mögen ist nicht sehr konstruktiv...
Ich warte auf deine Beispiele 😄

@posva

Ich denke, Sie können es auch zu jeder Vue-Instanz hinzufügen: Vue.prototype.$bus = new Vue()

Ich mag es. Ziemlich clever.

Etwas nicht zu mögen ist nicht sehr konstruktiv

Ich denke, das ist ein ziemlich gültiges Kriterium für die Entscheidung, etwas zu verwenden oder nicht, zumindest für mich. Auf jeden Fall habe ich schon oft gesagt, warum ich denke, dass Event-Bubbling seinen Platz hat.

Ich warte auf deine Beispiele 😄

Ich meine, muss ich das wirklich? Ich habe Beispiele für Situationen gegeben, in denen mir die Idee, einen Event-Bus zu verwenden oder Listener auf jeder Ebene zu deklarieren, nicht gefällt. Sie möchten Code sehen? Ich könnte mir vielleicht etwas einfallen lassen, um meinen Standpunkt etwas klarer zu machen, aber ich glaube, dass Event-Bubbling eine ziemlich normale Sache ist, die die meisten Leute als etwas Nützliches schätzen können, und Event-Busse oder Staatsmanager sind, zumindest für mich, eine Art Paradigmenwechsel, der, obwohl nicht schwer zu verstehen, wie Hipster-Territorium erscheint. 😄

Ich mache natürlich Witze über diesen letzten Kommentar. Wie ich bereits sagte, sehe ich ihren Nutzen und werde definitiv ein Problem finden, das ich damit lösen kann. Tatsächlich neige ich bei einigen Projekten, an denen ich mit Ember gearbeitet habe, dazu, einen "Dienst" zu schreiben, der sich genau wie ein globaler Zustandsmanager verhält. Ich versichere Ihnen, ich versuche nicht absichtlich stur zu sein.

Vue gefällt mir sehr gut. Ich will es nur _lieben_, weißt du?

musst du das Event nicht auch für jede Komponente ausgeben

Sie tun es, wenn Sie in Event-Blubbern denken. Und Sie tun es nicht, wenn Sie die Komponentenzusammensetzung verwenden.

Z.B:

<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 Komponente muss sich nicht um die Ereignisse der a-button Komponente kümmern, da sowohl a-modal als auch zwei a-button Instanzen "direkte logische Kinder" einer einzelnen Instanz sind , obwohl eine komplizierte Ansichtshierarchie mit Verschachtelung vorhanden ist.

Ich glaube, ich wiederhole mich an dieser Stelle nur. Ich werde dieses Problem irgendwie umgehen. Es erscheint mir nur seltsam, dass sich diese Diskussion um die Angabe mehrerer Problemumgehungen für etwas ziemlich Standardmäßiges und Praktisches dreht, das aus irgendeinem Grund einfach nicht mehr existiert.

@LinusBorg :

Nun, der Punkt ist, dass niemand im Team einen realen Anwendungsfall für $dispatch() aufzeigen konnte, in dem es anderen Lösungen (nicht nur $emit()) vorzuziehen war.

Das klingt für mich wie ein Bauingenieur, der mich nach einem Grund fragt, eine Autobahnausfahrt nicht zu sperren:

Er sagt etwas wie: "Diese Ausfahrt führt zu einer Kreuzung, an der die Leute verwirrt sind, ob sie links oder rechts abbiegen sollen. Die meisten Leute kennen den Weg, weil sie seit Jahren hier leben, aber Neubürger verirren sich oft für ein paar Minuten und das wollen wir vermeiden."

Ich sage: "Okay, klar, du kannst es schließen, das ist cool. Ich muss nur noch 10 km weiter bis zur nächsten Abfahrt fahren. Das schaffe ich."

:) Vielen Dank für Ihre Antworten. Ich bin froh, dass Sie zumindest alle offen für Diskussionen sind. Scheint ein gutes Team zu sein.

Das klingt für mich wie ein Bauingenieur, der mich nach einem Grund fragt, eine Autobahnausfahrt nicht zu sperren:

Er sagt etwas wie: "Diese Ausfahrt führt zu einer Kreuzung, an der die Leute verwirrt sind, ob sie links oder rechts abbiegen sollen. Die meisten Leute kennen den Weg, weil sie seit Jahren hier leben, aber Neubürger verirren sich oft für ein paar Minuten und das wollen wir vermeiden."

Ich werde auch meine schlechte Metapher hinzufügen. :) Aus meiner Sicht ist es eher so:

• „Diese Straße ermutigt die Leute, schneller zu fahren, als sie sollten. Geschwindigkeitsbegrenzungen werden selten beachtet. Wir sollten einige Stoßstangen hinzufügen, um die Leute zu zwingen, langsamer zu werden.“
• "Aber ich komme gerne schnell an mein Ziel, indem ich zu schnell fahre!"
• "Klar, es kann dir ein paar Mal gut tun, aber wir beobachten diesen Teil der Straße seit über 1,5 Jahren ständig, und die Anzahl der Unfälle und der Leute, die die nächste Ausfahrt verpassen, ist es einfach nicht wert, wie viele Fahrer, die es hatten eines dieser Probleme hat bezeugt."
• "Aber ich mag diese Stoßstangen nicht!"
• Nun, für 99% der Ziele ist diese andere Straße so schnell wie diese vor den Stoßstangen, nehmen Sie einfach diese.
• "Aber ich mag diese andere Straße nicht! Die Aussicht ist nicht so schön!"
• ...

Etwas nicht zu mögen ist nicht sehr konstruktiv

Ich denke, das ist ein ziemlich gültiges Kriterium für die Entscheidung, etwas zu verwenden oder nicht, zumindest für mich. Auf jeden Fall habe ich schon oft gesagt, warum ich denke, dass Event-Bubbling seinen Platz hat.

Ich denke, @posva meinte: "Das gefällt mir" ist kein konstruktives Argument, wenn man darüber diskutiert, etwas zu behalten oder etwas zur Bibliothek mit einer Vielzahl von Benutzern hinzuzufügen. Aus diesem Grund frage ich immer wieder nach einem validen, realen Anwendungsfall, der statt nach persönlichen Vorlieben diskutiert werden kann.

Ja, außer du hast die tadellos gute Autobahn gesprengt und eine andere mit gummiertem Asphalt gebaut, weil du irgendwo gelesen hast, dass es ziemlich ordentlich ist. Außerdem sind es 10 km mehr. :)

Zum Beispiel: Ich denke, die in der ursprünglichen Frage zu rekursiven Komponenten gepostete ist in Ordnung. Stellen Sie sich vor, Sie möchten auf jeder Ebene der Reihe nach etwas tun, wenn ein Ereignis erfasst wird und Sie ein perfektes Beispiel haben. Das geht mit $dispatch ziemlich einfach.

Sie möchten Code sehen?

Ja bitte

@posva Ich habe ein Beispiel zum vorherigen Kommentar gegeben. Hinweis: Wenn Sie länger als ein paar Sekunden darüber nachdenken müssen, wie Sie das ohne $dispatch tun können, beweist dies meinen Standpunkt.

Zum Beispiel: Ich denke, die in der ursprünglichen Frage zu rekursiven Komponenten gepostete ist in Ordnung. Stellen Sie sich vor, Sie möchten auf jeder Ebene der Reihe nach etwas tun, wenn ein Ereignis erfasst wird und Sie ein perfektes Beispiel haben. Das geht mit $dispatch ziemlich einfach.

mit $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>

mit $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>

Ist das wirklich schlimmer?

Hast du noch einen? :)

OK sicher. Was ist, wenn sie nicht rekursiv sind, aber dennoch so verschachtelt sind?

In Ordung. Es ist 5 Uhr morgens hier und ich werde dank dir einen harten Tag haben. Wenn mir später etwas Besseres einfällt, poste ich es, wenn nicht, dann hast du entweder gewonnen oder ich habe das Interesse verloren :)

Was ist, wenn sie nicht rekursiv sind, aber dennoch so verschachtelt sind?

Sie müssten in jeder Vorlage für $emit() einen @event= Listener hinzufügen, und nicht für $dispatch() , das war es auch schon.

Dies kann als gut oder schlecht angesehen werden, je nachdem, ob Sie die Ausführlichkeit vs. die Ausdruckskraft betonen.

und btw. Wenn Sie in einer Situation ein Ereignis bis zum übergeordneten Element verketten müssen, können Sie dies wie folgt tun:

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

• Sie werden die "Kopplung" betrauern, die dies zwischen den Komponenten bewirkt.
• Ich werde die Ausdruckskraft loben
• Abgesehen davon ist es etwas mehr zu tippen, aber keine große Sache.
• und ich behaupte immer noch, dass bei einem realen Anwendungsbeispiel wahrscheinlich eine andere Optimierung verfügbar ist, wie ein globaler Speicher - aber das hängt vom individuellen Szenario ab und ist mit Beispielcode schwer zu argumentieren.

Wie auch immer, nette Diskussion, genießen Sie Ihren wohlverdienten Schlaf.

@rhyek es sieht nur nach $dispatch , aber das ist nicht das Ziel. Das Ziel ist es, Komponenten zu ermöglichen, mit angemessener Wartbarkeit miteinander zu kommunizieren. Wenn Sie dieses Ziel erreichen, ist $dispatch die minderwertige Lösung, wenn Sie alle praktischen Vor- und Nachteile auflisten, ohne Präferenzen, also haben wir es weggelassen.

Beachten Sie auch, dass sich das DOM-Event-Bubbling grundlegend von der komponentenübergreifenden Kommunikation unterscheidet. Das Argument, dass "Event-Bubbling weithin anerkannt ist", bedeutet nicht, dass es eine gute Lösung für das Problem sein muss, das wir zu lösen versuchen.

Ich bin mit dem Kommentieren dieses Threads fertig, weil es mir schwer fällt, mit "Ich mag es einfach nicht" zu argumentieren.