Zustand des Scope nach Lebensdauer: Wann ein React Portal tatsächlich einen globalen Store benötigt

Teams, die interne Portale entwickeln, beginnen die Diskussion oft mit der Frage „Redux oder Zustand?“. Eine nützlichere Erstfrage ist, welche Teile des Zustands tatsächlich global sein müssen. Dieser Artikel zeigt, wie man den Portalzustand nach dem Eigentümer sowie der Dauer seiner Gültigkeit klassifizieren kann, warum das Speichern kurzlebigen Zustands in einem globalen Store zu einer ständigen Flut an Bereinigungsfehlern führt, und wann ein globales Bibliothekskonzept die richtige Entscheidung ist.

Der größte Teil des Portalzustands ist kurzlebig

Portale bestehen in der Regel aus mehreren separaten Arbeitsabläufen. Ein Benutzer öffnet eine Seite, sucht oder bearbeitet etwas, beendet die Aufgabe und wechselt zu einem anderen Bereich der Anwendung. Formwerte, Filter, ausgewählte Tabellenspalten, die aktive Registerkarte sowie ob ein Modalfenster geöffnet ist, gehören alle zu dieser Seite oder diesem Arbeitsablauf. Sie müssen selten über mehrere unverwandte Routen hinweg gespeichert werden.

Nur ein kleiner Datensatz ist wirklich anwendungssweit relevant:

• der angemeldete Benutzer;
• der Authentifizierungsstatus und die Berechtigungen;
• die aktuelle Organisation oder Mieterin;
• Themen- und Sprachvorlieben.

Fast alles andere sollte in der Nähe der Funktion bleiben, zu der es gehört.

Globale Stores machen die Lebensdauer zu einer Aufräumarbeit

Führt man temporären Zustand in Redux, Zustand, MobX oder einen anderen globalen Store ein, überdauert dieser den Bildschirm, der ihn erstellt hat. Nun benötigt man zusätzlichen Code, um ihn bei Navigation, nach Absendung, beim Ausloggen, bei einem Wechsel der Mieterin sowie auf jedem anderen Abbruchweg zurückzusetzen. Verpasst man einen solchen Weg, kehrt der Benutzer zu einem Bildschirm zurück, der veraltete Filter, alte Auswahlmöglichkeiten oder halb ausgefüllte Formfelder aus einem früheren Besuch anzeigt. Solche Fehler sind schwer nachzuvollziehen, da sie von der genauen Reihenfolge der besuchten Bildschirme abhängen.

Die daraus resultierende Faustregel ist kurz: Wenn der globale Zustand ständig gelöscht werden muss, damit er sich wie ein lokaler Zustand verhält, hätte er wohl von Anfang an lokal sein sollen.

Wählen Sie den kleinstmöglichen Umfang

Passen Sie jeden Zustandsteil zum engsten Werkzeug an, das seine Lebensdauer abdeckt:

• Component-Zustand für UI-Verhalten, das sich auf eine einzelne Komponente bezieht;
• React Context für Zustand, der innerhalb einer Funktion oder einer Gruppe verwandter Routen geteilt wird;
• URL-Suchparameter für Filter, Paginierung und anderen Navigationszustand, wodurch Ansichten auch nach einem Neuladen weiterhin nutzbar bleiben;
• eine Server-Zustandsbibliothek wie TanStack Query für von der Backend-Seite abgerufte Daten, da Caching und Invalidation zu ihren Aufgaben gehören und nicht zu denen Ihres Stores;
• einen globalen Store nur für Client-Zustand, der tatsächlich auf die gesamte Anwendung angewendet wird.

Der Kontext auf Route-Ebene verdient eine besondere Erwähnung. Wenn Sie einen Provider um eine Gruppe von Routen platzieren, führt das dazu, dass beim Entfernen dieser Gruppe der Provider deinstalliert wird und sein Zustand automatisch verschwindet. Reacts Komponenten-Lebenszyklus übernimmt die Aufräumarbeiten, die man sonst manuell schreiben müsste. Wenn der Anreiz dafür, einen Store zu verwenden, tatsächlich darin besteht, Props über viele Ebenen weiterzuleiten, handelt es sich dabei um ein separates Problem mit leichteren Lösungen, das in „Warum Prop-Drilling kein Grund ist, Redux oder Zustand zu installieren“ erläutert wird.

Wann ein globaler Store sinnvoll ist

Redux, Zustand und ähnliche Bibliotheken sind die richtige Wahl, wenn der Zustand absichtlich über unzusammenhängende Screens hinweg erhalten bleiben soll. Typische Beispiele sind:

• Einkaufswagen;
• Komplexe Zahlungsabläufe, die mehrere Seiten umfassen;
• Entwürfe, die gespeichert bleiben müssen;

• Offline-first-Anwendungen;
• Über die gesamte App hinweg funktionierende Messaging- oder Benachrichtigungssysteme;
• Undo- und Redo-Funktionen;
• Echtzeitfunktionen, bei denen der Client-Zustand koordiniert werden muss;
• Komplexe Workflows mit vielen miteinander verbundenen Zustandswechseln.

In solchen Fällen löst ein zentralisierter Zustand ein echtes Problem, anstatt eines zu schaffen.

Haupterkenntnisse

• Entscheiden Sie sich vor der Auswahl einer Bibliothek für die Verantwortlichkeiten und die Lebensdauer des Zustands.
• Der Zustand, der zu einem bestimmten Workflow gehört, sollte mit diesem Workflow verschwinden – idealerweise durch Entfernen statt manuellen Zurücksetzens.
• Speichern Sie Serverdaten in einer Abfragesammlung und den Navigationszustand im URL.
• Reservieren Sie einen globalen Speicher für Zustände, die die gesamte Anwendung über Zeit absichtlich teilt; zu wissen, wann man ihn nicht verwenden sollte, ist Teil einer guten Architektur.