bookTitle="Front-End Reactive Architectures: Explore the Future of the Front-End using Reactive JavaScript Frameworks and Libraries",
year="2018",
publisher="Apress",
address="Berkeley, CA",
pages="129--158",
abstract="After a deep dive into the first reactive framework, we can continue our journey discovering others' reactive architectures, reviewing a flexible and easy-to-use state management system like MobX.",
@ -216,10 +216,29 @@ Damit wird dann auch das dritte Prinzip umgesetzt. Ein \textit{Reducer} stellt n
Für Dart wurde dies mit der \texttt{redux} Bibliothek umgesetzt. Ähnlich wie bei Riverpod wird hier noch eine zusätzliche Bibliothek benötigt, die Redux für das Flutter-Widget-System anwendbar macht. Dafür wird \texttt{flutter\_redux} verwendet. Diese adaptiert das Prinzip der Provider-Bibliothek für Redux-Stores. So wird der Store mittels eines Provider-Widget über die Widget-Tree für nachgelagerte Widgets zur Verfügung gestellt. Auf den Store zugegriffen wird über Selektoren, welche den benötigten Teil des globalen Zustands eingrenzen und per Callback-Funktion zurückgeben. Somit wird über diese Selektoren auch die Verändunger der Widgets ausgelöst, wenn sich der entsprechende Teil des globalen Zustands ändert.
\subsection{MobX}
MobX ist wie Redux ebenfalls ein Ansatz, der ursprünglich aus dem React-Ökosystem stammt. MobX stellt sich dabei die Aufgabe, es zu vereinfachen automatisch diverse Informationen aus dem Anwendungs-Zustand abzuleiten. Um dies zu erreichen, gibt es bei MobX fünf grundlegende Konzepte:
\blockquote[{\cite[S.130]{mobx}}]{\begin{itemize}
\item Observables [...]
\item Computed Values [...]
\item Reactions [...]
\item Actions [...]
\end{itemize}}
Observables bilden die Grundlage eines Zustands. Ein Observable stellt einen Wert da, welcher beobachtet werden kann und somit auf Änderungen reagiert werden kann. Von Observables werden alle anderen Informationen abgeleitet.
Mit Computed Values lassen sich ein oder mehrere Observables kombineren oder einer weiteren Verarbeitung unterwerfen. Wenn sich eines der zugrundeliegenden Observables ändert, wird auch dieser Wert neu berechnet.
Reactions reagieren auf Änderungen von Observables oder Computed Values und lösen Seiteneffekte aus. Ein Beispiel hierfür ist das Observer-Widget, welches es ermöglicht, Widgets neu zu bauen, wenn sich die referenzierten Observables ändern.
Actions werden wie bei Redux hier ebenfalls verwendet, um Änderungen am Zustand - hier also Observables - durchzuführen. Allerdings wird hier als Action eine Funktion verstanden, welche Observables abändert und nicht ein Objekt, welche mithilfe eines Reducers den Zustand mutiert.
Observables, Computed Values und Actions werden dabei oft in Klassen zu einem Store zusammengefasst. Die Instanzen dieser Stores müssen dabei über einen Service Locator ähnlich wie bei Riverpod in die Widgets injiziert werden, damit diese den Store mithilfe von Observern nutzen können.
\subsection{GetIt}
Der Ansatz mit GetIt kombiniert diverse bereits eingeführte Konzepte miteinander. GetIt ansich ist ein Service-Locator. Ein Service Locator bietet eine zentrale Stelle, an der alle benötigten Komponenten registriert werden und abgerufen werden können. Dieser Service Locator wird nun mit dem bereits eingeführten Konzept des ChangeNotifier und von StatefulWidgets verknüpft. \autocite[Kap.4]{managingstateinflutter} Dazu wird der Zustand mittels einer ChangeNotifier-Klasse modelliert und anschließend über GetIt an die Widgets übergeben, die den Zustand benötigen. Diese Widgets müssen StatefulWidgets sein und registrieren bei der ChangeNotifier-Instanz einen Listener, welcher aufgerufen werden soll, wenn sich der Zustand ändert. Bei einer solchen Zustandsänderung, wird im StatefulWidget die \texttt{setState}-Methode aufgerufen, welche zum Neubauen des Widgets führt.
