Frontend Development: Das Flux Pattern

Von vielen Backendentwicklern gemieden, vom Web geliebt und vor allem ein Teil des Büroalltages des Webentwicklers. Die Rede ist von der Frontendentwicklung mit Javascript. Nicht nur der Umfang des entstandenen Biotops an Bibliotheken, Frameworks und Hilfstools für die clientseitige Softwareentwicklung deutet darauf hin, dass genau diese extrem wichtig ist. Auch die Kunden messen die Qualität einer Software oftmals an der Handhabung und dem ersten Eindruck dieser. Beides wird eben mit Frontend-Techniken erstellt und sollte für jedes Projekt dementsprechende Beachtung finden.

Neben klassischen Auszeichnungssprachen wie HTML und den dazugehörigen Stylesheets (css) sollte demnach auch die clientseitige Skriptsprache Javascript in jedem Softwareprojekt verankert sein. Mit dieser werden die Interaktionen der Nutzer schließlich zur Verfügung gestellt. Doch wie organisiert man den Frontendcode so, dass er wartbar ist und bleibt, sich ein Entwickler schnell hinein arbeiten und effektiv entwickelt werden kann?

Beschäftigen wir uns für diese Frage mit einem von Facebook proklamierten Design-Pattern.

The One Way Data Flow

Eines sei vorweg genommen. Flux ist kein Framework. Es ist viel mehr als Designvorschlag für einzelne Frontendseiten zu verstehen. Die Vorteile des Patterns kommen dabei schnell zu tragen, dazu aber später mehr.

Grundlegend kann man das Pattern auf drei essenzielle Arten von Komponenten herunter brechen.

  1. Dispatcher
  2. Store
  3. View

Flux definiert dabei einen unidirektionalen Datenflow. Daten werden also immer in eine Richtung verteilt.

Der Store enthält die Daten, sozusagen die Businessmodels des Frontends, und die jeweilige Businesslogik der einzelnen Models. Die Views bekommen die Daten der Businessmodels lediglich zur Verfügung gestellt. Es findet keine direkte Manipulation der Daten aus den Views heraus statt. Somit ist gesichert, dass die Daten an einer Stelle bearbeitet werden und nicht nachvollziehbare Manipulationen unterbunden sind.

Der Datenfluss geht von Dispatcher über den Store zur View.

Die Nutzerinteraktion findet jedoch auf den Views statt. Um dieser entgegnen zu können werden von den Views die jeweiligen Dispatcher-Events getriggert.  Folgende Grafik stellt diesen Data Flow dar.

 

Man erkennt eindeutig, dass der Dispatcher aufgrund von Actions Events triggert. Der jeweilige Store wartet auf diese Events und führt darauf basierend Businesslogik, wie einen ajax-Request oder eine Berechnung aus. Aufgrund dieser Änderungen werden die Views neu arrangiert oder ein Rerendering des Frontends gestartet.

Eine good-practice ist es dabei, für jeden Store genau einen Dispatcher zur Verfügung zu haben. So kann man als Entwickler einfacher nachvollziehen, von wo das jeweilige Event getriggert wird. Jeder Store sollte sich wiederum auf genau ein Businessmodel konzentrieren. Somit kann eine separation of concerns erreicht werden, die es dem Entwickler leicht macht, den Code nachzuvollziehen.

Fazit und Ausblick

Durch die bloße Anwendung des Pattern ist der Code automatisch strukturiert. Man kann als Entwickler auch nach einiger Zeit schnell den Einstieg in die Seite finden. Durch das Pattern werden etwaige Seiteneffekte und ungewollte Manipulationen unterbunden. In der Theorie ist das Pattern also sehr zu empfehlen.

Dabei ist jedoch zu beachten, dass sich das Pattern auf genau eine Seite bezieht. Es handelt sich also nicht um geschriebenen Code, der so direkt wieder verwendet wird, sondern auf den Kontext einer Seite zugeschnitten ist. Das Pattern entfaltet sich erst vollkommen bei Single-Page-Applications, die bspw. RESTful Webservices konsumieren und darauf basierend den DOM anpassen. Jedoch kann die einfach erstellte Strukturierung auch bei weniger komplexen Seiten einen enormen Vorteil für spätere Anpassungen oder Umbauten bieten.

Facebooks offizielle Beschreibung des Patterns kann auf deren Githubseite nachgelesen werden.

Fraglich ist nun, wie das Pattern in der Praxis umgesetzt werden kann. Dazu könnt ihr unseren Artikel mit einer beispielhaften Verwaltung von Externen Mitarbeitern lesen. 😉

 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.