Zum Hauptinhalt springen

MVI (Model–View–Intent)

Einleitung​

MVI basiert auf unidirektionalem Datenfluss.

Benutzeraktionen (Intents) werden verarbeitet, daraus entsteht ein neuer, vollständiger Model-State, der die View deterministisch rendert.

Ziel:

Vorhersagbares, reproduzierbares und testbares State-Management.

Einordnung

MVI ist ein UI-Architektur-Pattern auf Applikationsebene.

Es ist besonders geeignet für:

  • reaktive Frameworks
  • komplexe State-Logik
  • zustandsintensive SPAs
  • mobile Apps

Es ist kein Deployment-Modell und kein Backend-Pattern.

Grundprinzip

Charakteristisch:

  • Datenfluss ist strikt unidirektional
  • View rendert ausschließlich State
  • Reducer erzeugt neuen State (kein Mutieren)

Zentrale Konzepte

1️⃣ Single Source of Truth​

Der gesamte UI-Zustand liegt im Model.

Kein:

  • versteckter lokaler State
  • implizite Seiteneffekte
  • bidirektionale Bindung

2️⃣ Reducer​

Reducer sind:

  • rein funktional
  • deterministisch
  • testbar

Signatur:

newState = reducer(oldState, intent)

3️⃣ Side Effects​

Asynchrone Effekte (HTTP, Timer, Storage) sind:

  • explizit modelliert
  • vom Reducer getrennt
  • kontrolliert rückgeführt

MVI trennt:

  • State-Transition
  • Side Effect

4️⃣ Immutable State​

State wird nicht verändert, sondern ersetzt.

Vorteile:

  • Time Travel Debugging
  • reproduzierbare Bugs
  • klar nachvollziehbare Übergänge

Vorteile

  • Deterministisches UI-Verhalten
  • Hohe Testbarkeit
  • Klare Zustandsflüsse
  • Gute Debugbarkeit
  • Kontrollierte Nebenläufigkeit

Risiken / typische Fallstricke

1️⃣ Boilerplate​

Intent-, State- und Reducer-Strukturen erzeugen:

  • mehr Code
  • höhere Einstiegshürde

2️⃣ Überdimensionierter Global State​

Nicht jeder Button-Klick braucht globalen State.

Zu grober State führt zu:

  • unnötigen Re-Renders
  • Komplexität

3️⃣ Falsche Side-Effect-Modellierung​

Wenn Effekte nicht sauber isoliert sind:

→ MVI degeneriert zu versteckter Imperativ-Logik.

MVI vs andere Patterns

PatternDatenflussState-TransparenzKomplexität
MVCteilweise bidirektionalmittelmittel
MVVMoft bidirektionalmittelmittel
MVIstrikt unidirektionalhochhöher
MVI + ESvollständig nachvollziehbarsehr hochhoch

Wann sinnvoll?

  • komplexe State-Maschinen
  • Offline-/Sync-Logik
  • parallele Async-Prozesse
  • Micro Frontends mit klarer Domänen-State-Grenze
  • hohe Debug-Anforderungen

Wann nicht sinnvoll?

  • kleine Marketing-Seiten
  • einfache CRUD-Formulare
  • geringe UI-Komplexität

Strategische Perspektive

MVI ist kein Trend-Pattern.

Es ist eine Disziplinierungsstrategie für UI-State.

In großen Frontend-Landschaften:

  • reduziert es implizite Kopplung
  • erleichtert Ownership
  • verbessert Stabilität

Es passt besonders gut zu:

  • Micro Frontends
  • Feature-Sliced Architecture
  • reaktiven State-Libraries

Fazit

MVI bietet:

  • deterministischen Datenfluss
  • klare State-Transitions
  • reproduzierbare UI-Zustände

Es erhöht Struktur und Disziplin – aber auch initialen Aufwand.

Für komplexe Frontends ist das meist ein lohnender Trade-off.