Wie denkst du über den Unterschied zwischen Server State und Client State in einer Frontend-App?

Server State sind Daten, die dir nicht gehören: sie leben in einer Datenbank, sie können in dem Moment veraltet sein, in dem sie ankommen, und sie brauchen Caching, Revalidierung, Retries und Deduplizierung. Client State sind Daten, die dir gehören, etwa welcher Tab offen ist oder was in ein Formular getippt wurde, und der ist synchron und immer korrekt. Behandle beides unterschiedlich: einen Query-Cache für Server State, lokalen Komponenten-State oder einen kleinen Store für Client State.

Server State ist eine gecachte Kopie von etwas, das ich nicht kontrolliere. Er kommt asynchron an, er kann veraltet sein, zwei Komponenten wollen ihn womöglich gleichzeitig, und er braucht Revalidierung, Retries und Deduplizierung. Client State gehört mir: das offene Accordion, der Entwurf in einem Formular, der ausgewählte Filter, bevor ich ihn anwende. Er ist synchron und nie veraltet. Seit ich beides als verschiedene Probleme behandle, ist eine Menge Code verschwunden. Serverdaten landen in einem Query-Cache mit den Parametern als Key, das erledigt Lade- und Fehlerzustände, dedupliziert parallele Requests und lädt beim Fokus nach. Client State bleibt lokaler Komponenten-State, bis mehr als eine Komponente ihn braucht, und erst dann wandert er in einen kleinen gemeinsamen Store. Das Symptom, wenn man das falsch macht, ist sehr wiedererkennbar: ein globaler Store voller Entitäten, handgeschriebene Loading-Booleans auf jedem Screen, und ein Bug, bei dem zwei Komponenten denselben Nutzer laden und sich über ihn uneinig sind. Ich habe so eine App gewartet und würde sie nicht noch einmal so bauen.