Mentos und Coke

Wir haben gelernt in unseren mobilen und Desktop-Anwendungen konsequent die Model-View-Controller Architektur einzuhalten. Nun aber scheint es uns im Web-Breich sehr verlockend zu sein davon abzugehen und Frameworks zu benutzen, die es nicht so genau mit dem Applikationszustand nehmen und sich zum Zwecke des Databindings lokale Kopien von Daten des Models in die Komponenten ziehen. Zu Beginn scheint das sehr viel einfacher zu sein und die durchwegs sehr guten Demo-Beispiele geben uns das Gefühl in diesen Frameworks gut aufgehoben zu sein. Oft gibt es ein böses Erwachen, wenn die Anwendung weg vom trivialen Demo-Beispiel zu einer echten Applikation wachsen soll.

Man denke zum Beispiel an eine alltägliche Aufgabenstellung: Ein Benutzer fügt ein Produkt zum Warenkorb hinzu. Wie mühsam ist es da für manche Programmierer das Badge rechts oben, das anzeigt wie viele Produkte sich im Warenkorb befinden, zu aktualisieren. Eine Vielzahl spaghettiartig verflochtenter Komponenten kommuniziert miteinander oder reagiert auf Inputs(), erzeugt Outputs und so weiter. Das Angular - Anfänger - Tutorial hierzu ist so lange, dass man beim Lesen schon beinah einen Muskelkater vom vielen Herumscrollen bekommt.

Das ist alles viel zu kompliziert, es geht wesentlich einfacher wenn wir uns konsequent an unsere Entwurfsmuster halten.

Unsere Anwendungen müssen große Mengen von “Zustand” verarbeiten. Dieser Zustand setzt sich zusammen aus den Antworten, die wir von unserem Applikations-Server erhalten haben, aus gecachten und lokal erstellten Daten, aus aktiven Routen, aktuellem Zustand von Fortschrittsbalken, Seiten- und Tabauswahl-Informationen und vielem mehr.

Diesen Applikationszustand zu managen ist eine nicht zu unterschätzende Aufgabe. Ein typisches Beispiel eines solchen Vorganges ist: ein Model aktualisiert eine View, dann aktualisiert diese View das Model, diese aktualisiert wiederum eine andere View, das ein anderes Model aktualisiert, da wiederum zum Update einer anderen View führt. Dabei treten zusätzlich viele Ereignisse asynchron ein, wie etwa eine Benutzereingabe, eine asynchron eintreffende Antwort vom Server, ein Event über einen Websocket etc.

Weil wir die zwei an sich einfachen Dinge Veränderung und Asynchronizität vermischen, ist die Komplexität schwer zu handhaben. Unserem Verstand fällt es schwer mit der Kombination dieser beiden an sich harmlosen Tatsachen umzugehen. Es erinnert etwas an das Beispiel Mentos und Coke.

In meinem Demo - Beispiel wird im www-Ordner gezeigt, wie wir mit den zwei Herausforderungen Veränderung und Asynchronizität problemlos umgehen können.