React.js - Fluss gegen globalen Ereignisbus
Was ist der Vorteil von Flux über einen globalen Event-Bus? Ich denke, der Dispatcher ist alles was benötigt wird:
- Komponente veröffentlicht "Benutzerereignis" mit Daten zum Dispatcher
- Dispatcher führt den Handler des subskribierten Speichers aus Der
- -Handler veröffentlicht 'update event' mit den aktualisierten Eigenschaften des Geschäfts
- Dispatcher führt den Handler der abonnierten Komponente aus und aktualisiert den Komponentenstatus mit den aktualisierten Eigenschaften des Geschäfts
Was fehlt mir hier, dass ich nicht ohne Flux auskommen kann?
4 Antworten
Ich denke, was andere über die Anwendungsstruktur und das Ereignis change gesagt haben, ist wichtig, aber ich sollte dieses eine Ding hinzufügen:
Die waitFor -Methode des Dispatchers ist der größte Unterschied zwischen der Registrierung der Filialen mit einem Dispatcher und den Filialen, die einen globalen Event-Bus hören. Mit dieser Methode können Sie verwalten, welche Speicher vor anderen aktualisiert werden. Und das wird wichtig, wenn Sie wollen, dass StoreB zuerst nachgeht, was StoreA getan hat, bevor es entscheidet, was zu tun ist.
Sie könnten sich den Dispatcher als einen globalen Event-Bus mit einer waitFor -Methode vorstellen, und das wäre etwas genau.
Ich bin kein Experte für den Fluss, aber eine Architektur ermöglicht es Ihnen nicht, etwas zu tun, was vorher nicht möglich war, und gibt Ihrer Anwendung eine Struktur, die erweiterbar und verständlich ist.
Ich glaube, es geht um eine Code-Struktur, die selbst in großem Maßstab verständlich ist.
Supose Sie haben appState , die zugrunde liegende Daten für Komponenten enthält.
Die Komponenten rufen action auf. Action ist dafür zuständig, Daten von XHR zu sammeln oder die eingehenden Daten von der Komponente zu ändern und dann vollständige Daten an den subskribierten Speicher zu senden.
Store ist der einzige Teil Ihres Codes, der Ihre appState ändern kann und es ist im Prinzip das einzige, was es tut. Es nimmt Daten aus der Aktion und speichert sie in appState oder entfernt einige Daten aus appState entsprechend der Aktion.
Dann feuern Sie stateChanged event, was Ihre Komponente hören soll und rerender wird.
Sie haben also alle aktionsspezifische Logik in Aktionen. Sie behandeln appState nur in Geschäften. Und das sollte dir helfen, deinen Code verständlich zu halten.
Flussmuster
Mein Verständnis von warum ist eine gute Idee, nur vollständige Daten zu versenden kommt hauptsächlich aus Dieser Artikel . Und es basiert auf dem offiziellen Facebook Flux-Diagramm
Die Vorteile dieses Ansatzes sind:
- speichert sind einfach und synchron, enthält keine Entscheidungslogik, behandelt nur gegebene Daten
- Es besteht keine Notwendigkeit, eine weitere Aktion auszulösen, die die Flux -Kette unterbricht
- Dispatcher ist der einzige Kanal für alle Statusänderungen, er weiß, welche Aktion mit welchen Daten verarbeitet wird, daher ist es einfacher zu debuggen
Sie haben im Grunde Fluss beschrieben, der einzige Unterschied ist:
- Geschäfte geben ein Änderungsereignis aus
Und die Komponente, die ihren Zustand aktualisiert, ist nicht Teil des Flusses, das ist eine übliche Praxis für das Integrieren von Fluss und Reagieren.
Flux benennt jedes dieser Stücke und gibt Richtlinien für die Verantwortung jedes einzelnen Stücks.
Im Wesentlichen handelt es sich um einen Hauptereignis-Emitter (Dispatcher), die Ereignistypen (Aktionen), Funktionen, die ein Ereignis auf dem Dispatcher ausgeben (Aktionsersteller; der Ereigniskörper ist eine Nutzlast) und andere Ereignisemitter, die: Zustand halten, zuhören an den Dispatcher senden und Änderungsereignisse (Stores) ausgeben.
Zumindest funktioniert das in JS. Das Kernprinzip ist der unidirektionale Datenfluss. Es gibt viele Ereignisemitter, die für die bidirektionale Kommunikation verwendet werden.
Tags und Links javascript reactjs reactjs-flux event-bus flux