The Art of State: Zustandsmanagement in React-Anwendung, Teil 3

Der dritte Artikel zum State-Management in React stellt die beiden Bibliotheken MobX und Recoil vor. Welche passt zu welchen Anwendungsszenarien?

Lesezeit: 8 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 12 Beiträge
Von
  • Nils Hartmann
Inhaltsverzeichnis

MobX ist die nach Redux am häufigsten eingesetzte Lösung für das Zustandsmanagement in React-Anwendungen. Genau wie Redux ist der Kern von MobX React-frei, sodass sich die mit MobX umgesetzte Logik auch in anderen (UI-)Frameworks verwenden lässt.

Zur Illustration der Funktionsweise von MobX soll einen kleine Beispielanwendung dienen, die auf GitHub zur Verfügung steht. Mit ihr lässt sich ein Einkaufszettel mit einer Liste zu kaufender Produkte verwalten. Ein Eintrag besteht aus einem Produktnamen und einem Geschäft, in dem das jeweilige Produkt besorgt werden soll. Außerdem kann man jeden Eintrag auf erledigt setzen. Über Steuerelemente auf der Benutzeroberfläche können Anwender die Liste sortieren. Außerdem können sie die erledigten Elemente ausblenden.

Screenshot der Beispielanwendung (Abb. 1)

Den globalen Anwendungszustand hält MobX in Stores. In einem Store liegen die Daten der Anwendung (State). Außerdem sind an einem Store Aktionen definiert, mit denen sich die Daten verändern lassen (Actions). Im Gegensatz zu Redux, bei dem es einen zentralen Store gibt und die Reducer-Funktionen jeweils nur auf einen Teil des Stores Zugriff haben, erlaubt MobX beliebig viele Stores, und diese können Abhängigkeiten untereinander haben. Zum Beispiel kann es je nach Domain einen Store geben oder unterschiedliche Stores für Anwendungsdaten und UI-Zustand. Der Store in MobX ist ein Observable, sodass sich Interessenten (Observer) darüber zu Änderungen informieren lassen können.

The Art of State: Zustandsmanagement in React-Anwendung, die Serie

Ein Store in MobX kann ein Objekt oder eine ES6-Klasse sein, die MobX im einfachsten Fall mit der Funktion makeAutobservable automatisch in ein Observable konvertiert. Ein Eintrag auf dem Einkaufszettel ist als Objekt implementiert:

function newShoppingItem(name, shop) {
  return makeAutoObservable({

    // State:
    id: nextId(),
    name,
    shop,
    done: false,

    // Actions:
    updateShop(newShop: string) {
      this.shop = newShop;
    },

    markAsDone() { this.done = true; }
  })
}

makeAutoObservable legt beim Erzeugen des Observables einige Konventionen zugrunde. Funktionen werden zum Beispiel als Actions interpretiert (updateShop, markAsDone). Die Daten (id, name, shop, done) sind der State und dürfen zwar direkt gelesen, aber nur über diese Actions verändert werden.