Grundlegendes zum Flussmuster

Ich studiere gerade das Flussmuster und es gibt etwas, das ich in Bezug auf die Läden nicht verstehen kann .

Was genau sind sie?

Ich habe viele Artikel gelesen und es scheint, dass es sich um die Domain handelt.

Bedeutet dies, dass dies der "abstrakte" Teil ist, der sich auf API-Aufrufe oder Backend-Aufrufe bezieht?

Es ist nicht sehr klar für mich.

Edit: Könnte es dasselbe sein wie die eckige Fabrik? Abrufen von Remote-Daten, Ausführen einer Geschäftsaufgabe oder Speichern einiger Anwendungszustände (z. B. aktueller verbundener Benutzer)?

Ok, lassen Sie sich von mir Schritt für Schritt erklären

1 Was ist Flussmittel?

• Ein Muster
• Zentraler Dispatcher
• Unidirektionale Datenflüsse
• Listenpunkt

Sie nennen es auch aus einem Grund Flux.

Flux-Implementierungen

• Facebooks Flux
• Alt
• Reflux
• Flummox
• NuclearJS
• Fluxibel

Ein Chat mit Flux

Reaktion : Hey Aktion, jemand hat auf die Schaltfläche "Kurs speichern" geklickt.

Aktion : Danke Reagieren! Ich habe einen Aktionsersteller beim Dispatcher registriert, daher sollte der Dispatcher darauf achten, alle betroffenen Geschäfte zu benachrichtigen.

Dispatcher : Lassen Sie mich sehen, wer sich darum kümmert, dass ein Kurs gespeichert wird. Ah! Anscheinend hat der Store einen Rückruf bei mir registriert, also werde ich es ihr mitteilen.

Speichern : Hi dispatcher! Danke für das Update! Ich werde meine Daten mit den von Ihnen gesendeten Nutzdaten aktualisieren. Dann werde ich ein Ereignis für die React-Komponenten ausgeben, die wichtig sind.

Reagieren Sie : Ooo! Glänzende neue Daten aus dem Laden! Ich werde die Benutzeroberfläche aktualisieren, um dies widerzuspiegeln!

Flux API

Anmelden (Funktionsrückruf) - „Hey Dispatcher, lass mich laufen, wenn Aktionen stattfinden. -Geschäft"

unregister (string id) - „Hey Dispatcher, hör auf, dir wegen dieser Aktion Sorgen zu machen. -Geschäft"

waitFor (Array-IDs) - „Aktualisieren Sie zuerst diesen Speicher. -Geschäft"

dispatch (object payload) - „Hey Dispatcher, erzähl den Geschäften von dieser Aktion. -Aktion"

isDispatching () - "Ich bin gerade damit beschäftigt, Rückrufe zu versenden."

Das ist die Frage, die wir uns stellen

Ist Flux also ein Publish-Subscribe-Modell?

Nicht ganz.

Unterscheidet sich in zwei Punkten:

1.Jede Nutzlast wird an alle registrierten Rückrufe gesendet.

2. Rückrufe können auf andere Rückrufe warten

Zusammenfassung

Flux ist ein Muster für unidirektionale Datenflüsse. Aktionen kapseln Ereignisse. Dispatcher ist ein zentraler Hub, der Rückrufe speichert. Stores halten den App-Status. Viele Implementierungen

In einem einfachen Beispiel ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ) heißt es: „Stores verwalten den Anwendungsstatus für eine bestimmte Domäne in der Anwendung.“ Das heißt, sie enthalten Daten über den Status eines Aspekts der Anwendung und den gesamten Code, um ihn zu ändern. Immer wenn es eine neue Aktualisierung vom Dispatcher gibt, entscheiden alle Stores, wie sie ihre Daten als Antwort aktualisieren, und benachrichtigen dann die Views, dass sich die Daten geändert haben. In den Beispielen enthalten Stores Dinge wie "Liste nicht sichtbarer Threads" (wobei der Dispatcher sie benachrichtigt, dass eine neue Nachricht eingetroffen ist oder eine alte gelesen wurde, und die Ansichten dem Benutzer die Nachrichtenthreads anzeigen) und "Aktuelle Wiedergabezeit und" Zustand."

Technischer ausgedrückt: Sie sind die Zwischenschicht des Frameworks, die Rückrufe beim Dispatcher registriert, um Aktualisierungen zu erhalten. Anschließend werden die Ansichten benachrichtigt, wenn sich der Status der Daten ändert. (Die Ansichten können dann Aktionen an den Dispatcher zurücksenden.) Es gibt eine von ihnen implementierte abstrakte Schnittstelle, bei der jeder Store einen Rückruf beim Dispatcher registriert und Ereignisse an die Ansichten sendet, aber jeder Store scheint auf konkrete Weise eine bestimmte Domäne darzustellen. (Gibt es Gegenbeispiele?)

Informationsspeicher sind Codebereiche, in denen der Anwendungsstatus und die komplexe Logik gespeichert sind. Ein Grund dafür ist, dass mehrere Ansichten wahrscheinlich dieselben Daten verwenden, sie jedoch auf unterschiedliche Weise anzeigen oder einige, jedoch nicht alle Daten für eine bestimmte Domäne anzeigen. Beispielsweise meldet sich ein Benutzer an und Sie erhalten seinen Vor- und Nachnamen, seine E-Mail-Adresse, sein Foto, seinen Ort, seine Adresse, seine Telefonnummer usw. Diese Informationen werden in separaten Ansichten angezeigt. Anstatt Daten über Ansichten hinweg zu duplizieren, können wir einen Speicher namens UserStore verwenden, in dem die Daten für den Benutzer gespeichert werden. Dies vereinfacht das System, indem "ein Ort zum Ändern" angegeben wird, wann immer die gespeicherte Logik oder Daten geändert werden müssen. Es gibt viele andere Gründe, einen Store zu nutzen, aber ich denke, das ist der offensichtlichste.