Frontend-Zustand
Prozess
- Klassifiziere jeden Wert: dauerhafte Serverdaten, gemeinsam nutzbarer URL-/Navigationszustand, Formularentwurf oder temporärer Präsentationszustand. Wähle genau einen autoritativen Besitzer.
- Verwende die installierten State-/Data-Fetching-Tools wieder. Halte lokalen Zustand nahe bei seinen Konsumenten; führe gemeinsamen Zustand nur für ein konkretes Koordinationsbedürfnis ein.
- Schlüssele Server-Caches nach allen Abfrage- und Autorisierungsdimensionen. Leere oder isoliere sie bei Logout, Tenant-Wechsel und Identitätsänderungen.
- Modelliere Lade-, Leer-, Fehler- und Erfolgszustände explizit. Bei gleichzeitigen Requests kann Abbruch die Arbeit reduzieren, aber schütze auch die Ergebnisakzeptanz, sodass eine ältere Antwort keine neuere Absicht ersetzen kann.
- Bei optimistischen Mutationen gleiche mit dem Server ab und definiere Fehlerverhalten. Ein Rollback darf keine neuere erfolgreiche Mutation löschen; verfolge Operationen oder verwende das von der Bibliothek unterstützte Parallelitätsmuster.
- Überprüfe Zurück-/Vorwärts-Navigation, Wiederholungen, schnelle Eingabeänderungen, fehlgeschlagene Mutationen und Konto-Wechsel.
Beispiel
Suche nach A und dann B ergibt, dass B zuerst und A später zurückkommt. Die angezeigten Ergebnisse bleiben B, und die URL spiegelt die aktuelle Suche wider, nicht die Reihenfolge des Antwortabschlusses.
Stopp-Bedingungen
Ersetze nicht die State-Bibliothek, um ein lokales Race zu lösen. Das Duplizieren desselben Serverwerts in unabhängige globale Stores erzeugt eine Synchronisationsverpflichtung.
Evidenz
- Zustandsbesitzübersicht und Cache-Schlüssel.
- Race-/Rollback-/Sitzungswechsel-Prüfungen.
- Sichtbares Lade- und Wiederherstellungsverhalten.
Referenz
Workflow unabhängig geschrieben nach Überprüfung von react-state-management.