Zun\u00e4chst ging es um die Eigenheiten von React. Daraufhin f\u00fchrte uns der Weg zu Flux. W\u00e4hrend sich React prim\u00e4r als View-Controller versteht und mit einer virtuellen DOM-Schicht nur das erneuert, was sich auch wirklich in der Darstellung ge\u00e4ndert hat, ist Flux ein Modell, durch das sich Frontend-Entwicklung fast wie Desktop-Software-Development anf\u00fchlt. Durch die virtuelle DOM ist die Darstellung auch komplexerer Anwendungen rasend schnell, somit war die uns zun\u00e4chst gestellte Aufgabe eines kleinen Tickers f\u00fcr React fast lachhaft leicht.<\/p>\n

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.<\/p>\n

Verwirrung inbegriffen – doch alles handhabbar<\/h2>\n

Denn bis man seinen Kopf von der \u201cklassischen\u201d 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.<\/p>\n

Flux-View vs MVC und Beispiele<\/h2>\n

W\u00e4hrend im bekannten MVC-Modell multidirektionale Kommunikation zu schwierig zu \u00fcberschauenden 1 zu n Verbindungen f\u00fchren 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\u00f6glichen Stores verteilt. Zur\u00fcck zu unserem Ticker, f\u00fcr diesen hatten wir eine einzige Komponente (mit der f\u00fcr 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\u00f6tigem Overhead? F\u00fcr einen kleinen Ticker vielleicht \u2013 doch die Skalierbarkeit macht den zun\u00e4chst notwendigen Mehraufwand schnell wett \u2013 wie wir am n\u00e4chsten 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 \u201cLeucht-Element\u201d \u00fcber einer ausgegrauten Leinwand per Mausbewegung hin und her schieben konnten.<\/p>\n