Skip to main content

Flux Capacitation

Stores, Actions, Components. Für wen das nach Einkaufszentrum klingt, der liegt nicht weit daneben - nur im übertragenen Sinne. Denn die von Facebook 2013 ins Leben gerufene JavaScript Bibliothek React.js und die damit hervorragend funktionierende Applikations-Architektur Flux bieten eine Fülle neuer Möglichkeiten in der Webentwicklung. Umdenken ist angesagt! Und unser Einkaufswagen wurde in einem unserer internen Workshops letzte Woche prall gefüllt.

React Geschwindigkeit und mehr

Zunächst ging es um die Eigenheiten von React. Daraufhin führte uns der Weg zu Flux. Während sich React primär als View-Controller versteht und mit einer virtuellen DOM-Schicht nur das erneuert, was sich auch wirklich in der Darstellung geändert hat, ist Flux ein Modell, durch das sich Frontend-Entwicklung fast wie Desktop-Software-Development anfühlt. Durch die virtuelle DOM ist die Darstellung auch komplexerer Anwendungen rasend schnell, somit war die uns zunächst gestellte Aufgabe eines kleinen Tickers für React fast lachhaft leicht.

Aber lernen konnten wir einiges dabei. Angefangen bei JSX (einer Vereinfachung und Beschleunigung der JS-Programmierung durch XML basierte Befehle) hin zum anfangs verwirrenden unidirektionalen Modell von Flux.

Verwirrung inbegriffen - doch alles handhabbar

Denn bis man seinen Kopf von der “klassischen” JavaScript- hin zu komponentenbasierter Entwicklung lenken kann ist einiges Umdenken angesagt. Die einzelnen Komponenten agieren nicht direkt mit der View, sondern fordern via eines Dispatchers und dem Aufrufen spezifischer Actions den Store auf neue Daten zu liefern, mit denen die View in einer render()-Methode geupdatet wird. Und dieser kurze Satz beschreibt eigentlich schon den kompletten Gedanken der Flux Architektur.

Flummox-LaufzeitmodellEine Darstellung des Flux Laufzeit-Modells.

Flux-View vs MVC und Beispiele

Während im bekannten MVC-Modell multidirektionale Kommunikation zu schwierig zu überschauenden 1 zu n Verbindungen führen kann, bleibt Flux konsistent und die Kommunikation erfolgt immer nur in eine Richtung, bzw. im Kreis. Das wichtigste Utensil dabei ist der Dispatcher, der spezifische Actions an alle möglichen Stores verteilt. Zurück zu unserem Ticker, für diesen hatten wir eine einzige Komponente (mit der für die View wichtigen render()-Methode), welche mit einer einzigen Action den Store aufforderte, neue Daten (hier die bisherige Laufzeit der App) an die View zu liefern. Klingt nach unnötigem Overhead? Für einen kleinen Ticker vielleicht – doch die Skalierbarkeit macht den zunächst notwendigen Mehraufwand schnell wett – wie wir am nächsten Beispiel des Workshops schnell erkennen konnten. Wir bauten eine Image-Mover Komponente blitzschnell auf dem bisher Geschriebenen auf, indem wir ein Element in der View austauschten und durch Drag und Drop ein “Leucht-Element” über einer ausgegrauten Leinwand per Mausbewegung hin und her schieben konnten.

Flummox zeigt den weiteren Weg

Auf dem Workshop aufbauend wandte ich mich dann „Flummox“ zu, einer Implementation von Flux, welche die Arbeit damit noch weiter vereinfacht und Boilerplate-Code reduziert. Und kaum mit React und Flux angefangen, bin ich angefixt und nur auf den ersten Blick „flummoxed“. Danke für einen verfluxt tollen Workshop und die Einführung in die Entwicklung mit React!

Wird nicht veröffentlicht