Warum zwischen UI-Zustand und Serverzustand unterscheiden?

Question

Accepted Answer

**UI-Zustand** sind Daten, die deine App lokal besitzt und kontrolliert (Umschalter, Formeingaben, ausgewählter Tab). **Serverzustand** sind Daten, die auf einem Server vorhanden sind und nur auf dem Client *gecacht* werden (abgerufene Benutzer, Produkte, Beiträge). Sie haben grundlegend unterschiedliche Eigenschaften und benötigen verschiedene Werkzeuge.

## Die wichtigsten Unterschiede

```text
                  UI state                    Server state
Ownership         you own it (client)         the server owns it; client caches
Freshness         always current              can become STALE (server changed it)
Sync needed?      no                          yes — refetch, invalidate, revalidate
Shared?           usually one client          shared across users/devices/tabs
Concerns          just set/read it            caching, loading, errors, retries, dedup
```

## Warum das Behandeln von Serverdaten wie UI-Zustand schiefgeht

```jsx
// ❌ treating server data as plain local state — you must hand-build everything
function Users() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

useEffect(() => {
    fetch("/api/users")
      .then(r => r.json()).then(setUsers)
      .catch(setError).finally(() => setLoading(false));
  }, []);
  // and now: caching? refetch on focus? dedup? retries? stale data? all manual 😓
}
```

Du landest darin, Lade-/Fehler-Tracking, Caching, Refetching, Deduplizierung und Staleness-Handling zu reimplementieren — für jeden Fetch.

## Das richtige Werkzeug: eine Serverzustand-Bibliothek

```jsx
// ✅ React Query / SWR / RTK Query handle caching, loading, errors, refetch for you
function Users() {
  const { data: users, isLoading, error } = useQuery({
    queryKey: ["users"],
    queryFn: () => fetch("/api/users").then(r => r.json()),
  });
  // automatic: caching, background refetch, dedup, retries, stale-while-revalidate
}
```

Diese Bibliotheken sind speziell für das Serverzustand-Problem gebaut — einen lokalen Cache mit einer Remote-Quelle synchron zu halten.

## Die praktische Aufteilung

```text
UI state    → useState / Zustand / Context / Redux
Server state→ React Query / SWR / RTK Query / Apollo (for GraphQL)
```

## Warum es wichtig ist

Zu erkennen, dass Serverzustand ein **Cache von Remote-Daten** ist — kein normaler lokaler Zustand — ist ein großer Einblick für moderne Frontend-Architektur.

Es erklärt, warum das Dumpen von API-Daten in Redux/useState zu Bergen von manuellem Caching-/Lade-Code führt und warum dedizierte Serverzustand-Bibliotheken (React Query, SWR) existieren und so weit verbreitet sind.

Die beiden zu trennen — UI-Zustand in lokalen Stores, Serverzustand in einer Caching-Bibliothek — vereinfacht datenintensive Apps dramatisch und eliminiert eine riesige Kategorie von Boilerplate und Staleness-Bugs.