Eine Einführung in das Architekturmuster von Flux

Discover Functional JavaScript wurde von BookAuthority als eines der besten neuen funktionalen Programmierbücher ausgezeichnet !

Flux ist ein von Facebook vorgeschlagenes Architekturmuster für den Bau von SPAs. Es wird empfohlen, die Anwendung in die folgenden Teile aufzuteilen:

  • Shops
  • Dispatcher
  • Ansichten
  • Aktion / Aktionsersteller

Geschäft

Store verwaltet den Status. Es kann sowohl den Domänenstatus als auch den Benutzeroberflächenstatus speichern.

Speicher und Status sind unterschiedliche Konzepte. Status ist der Datenwert. Speichern ist ein Verhaltensobjekt, das den Status mithilfe von Methoden verwaltet. Bei der Verwaltung von Büchern: Die Buchliste ist der Status, und BookStore verwaltet diese Liste.

Ein Geschäft verwaltet mehrere Objekte. Es ist die einzige Quelle der Wahrheit in Bezug auf diese spezifischen Objekte. In einer Anwendung kann es viele Geschäfte geben. Zum Beispiel: BookStore, AuthorStore, UserStore.

Es gibt keine Setter-Methoden im Geschäft. Sie können eine Statusänderung nur anfordern, indem Sie eine Aktion an den Dispatcher übergeben.

Ein Geschäft hört auf alle Aktionen und entscheidet, welche davon ausgeführt werden sollen. Dies bedeutet normalerweise eine switchAussage. Sobald der Store die Statusänderungen vorgenommen hat, wird ein Änderungsereignis ausgegeben. Der Laden ist ein Event-Sender.

Geschäfte nehmen andere Geschäfte nicht als Abhängigkeiten.

Dispatcher

Der Dispatcher ist ein einzelnes Objekt, das Aktionen / Ereignisse an alle registrierten Geschäfte sendet. Geschäfte müssen sich beim Starten der Anwendung für Ereignisse registrieren.

Wenn eine Aktion eingeht, wird diese Aktion an alle registrierten Geschäfte weitergeleitet.

Aussicht

Ansicht ist die Benutzeroberflächenkomponente. Es ist für das Rendern der Benutzeroberfläche und die Handhabung der Benutzerinteraktion verantwortlich. Ansichten befinden sich in einer Baumstruktur.

Ansichten warten auf Speicheränderungen und rendern erneut.

Ansichten können in Präsentations- und Containeransichten weiter aufgeteilt werden.

Präsentationsansichten stellen keine Verbindung zu Dispatcher oder Filialen her. Sie kommunizieren nur über ihre eigenen Eigenschaften.

Containeransichten sind mit Filialen und Dispatcher verbunden. Sie warten auf Ereignisse aus Geschäften und stellen die Daten für Präsentationskomponenten bereit. Sie erhalten die neuen Daten mithilfe der Public-Getter-Methoden der Stores und geben diese Daten dann im Ansichtsbaum weiter.

Containeransichten lösen Aktionen als Reaktion auf Benutzeriterationen aus.

Aktionen

Eine Aktion ist ein einfaches Objekt, das alle Informationen enthält, die für diese Aktion erforderlich sind.

Aktionen haben eine typeEigenschaft, die den Aktionstyp identifiziert.

Wenn sich Aktionsobjekte in der Anwendung bewegen, empfehle ich, sie unveränderlich zu machen.

Aktionen können von verschiedenen Orten kommen. Sie können aus Ansichten als Ergebnis der Benutzerinteraktion stammen. Sie können von anderen Stellen stammen, z. B. vom Initialisierungscode, an dem Daten von einer Web-API abgerufen und Aktionen zum Aktualisieren der Ansichten ausgelöst werden. Die Aktion kann von einem Timer ausgehen, für den Bildschirmaktualisierungen erforderlich sind.

Aktionsersteller

Die Praxis besteht darin, den Code zu kapseln und Aktionen in Funktionen zu erstellen. Diese Funktionen zum Erstellen und Versenden von Aktionen werden als Aktionsersteller bezeichnet.

Web-API-Aufrufe

Wenn Sie Web-API-Aufrufe ausführen, um die Benutzeroberfläche zu aktualisieren, folgt auf den Web-API-Aufruf eine Aktion zum Aktualisieren des Speichers. Wenn der Speicher aktualisiert wird, wird ein Änderungsereignis ausgegeben, und als Ergebnis wird die Ansicht, die auf dieses Ereignis wartet, erneut gerendert.

Web-API-Aufrufe werden in Aktionserstellern ausgeführt. Wir können den Code, der den API-Aufruf ausführt, in Web API Utils-Funktionen extrahieren.

Unidirektionaler Datenfluss

Das Aktualisieren von Ansichten erfolgt in eine Richtung:

Ansichten ändern die empfangenen Daten nicht. Sie warten auf Änderungen dieser Daten, erstellen Aktionen mit neuen Werten, aktualisieren die Daten jedoch nicht.

Geschäfte, Ansichten und andere Aktionen können den Status in (anderen) Geschäften nicht direkt ändern. Sie müssen eine Aktion über den Dispatcher senden

Der Datenfluss ist beim Speichern im Geschäft kürzer als beim Schreiben. Der Datenfluss beim Schreiben im Geschäft unterscheidet sich zwischen asynchronen und synchronen Aktionen.

Store Reads

Speichern Schreibt in synchronen Aktionen

Speichern Schreibt in asynchronen Aktionen

Vorteile

Die Flussarchitektur ist in einer Anwendung besser, in der Ansichten nicht direkt Domänenspeichern zugeordnet werden. Anders ausgedrückt: Wenn Ansichten Aktionen erstellen können, mit denen viele Geschäfte aktualisiert werden, können Geschäfte Änderungen auslösen, mit denen viele Ansichten aktualisiert werden.

Aktionen können beibehalten und dann wiedergegeben werden.

Nachteile

Flux kann einer Anwendung, bei der jede Ansicht einem Geschäft zugeordnet ist, unnötige Komplexität hinzufügen. Bei dieser Art der Anwendung reicht eine Trennung zwischen Ansicht und Speicher aus.

Schauen Sie sich zum Beispiel an, wie Sie mit React eine dreischichtige Anwendung erstellen.

Fazit

Geschäfte verwalten den Status. Sie ändern ihren Status nur, indem sie auf Aktionen warten. Speichert Benachrichtigungsansichten zum Aktualisieren.

Ansichten rendern die Benutzeroberfläche und behandeln die Benutzerinteraktion. Containeransichten warten auf Speicheränderungen.

Der Dispatcher sendet Aktionen an alle registrierten Geschäfte.

Aktionen sind einfache Objekte.

Discover Functional JavaScript wurde als einer derbeste neue funktionale Programmierbücher von BookAuthority !

Weitere Informationen zum Anwenden funktionaler Programmiertechniken in React finden Sie unter Functional React .

Lernen Sie funktionale Reaktionen projektbasiert mit funktionaler Architektur mit React und Redux .

Auf Twitter folgen