Proč rozlišovat mezi stavem uživatelského rozhraní a stavem serveru?

Question

Accepted Answer

**Stav UI** jsou data, která aplikace vlastní a kontroluje lokálně (přepínače, vstupy formuláře, vybraná karta). **Stav serveru** jsou data, která existují na serveru a jsou pouze *uložena v mezipaměti* na klientu (načtení uživatelé, produkty, příspěvky). Mají fundamentálně odlišné charakteristiky a potřebují jiné nástroje.

## Klíčové rozdíly

```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
```

## Proč zacházení se serverovými daty jako se stavem UI selhává

```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 😓
}
```

Skončíte s opětovnou implementací sledování načítání/chyb, ukládání do mezipaměti, opětovného načítání, deduplikace a řešení zastaralosti — pro každý fetch.

## Správný nástroj: knihovna stavu serveru

```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
}
```

Tyto knihovny jsou vytvořeny speciálně pro problém stavu serveru — udržování lokální mezipaměti v synchronizaci se vzdáleným zdrojem.

## Praktické rozdělení

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

## Proč je to důležité

Uvědomit si, že stav serveru je **mezipaměť vzdálených dat** — ne normální lokální stav — je hlavním poznatkem pro moderní architekturu front-endu.

Vysvětluje to, proč vhazování dat API do Redux/useState vede k horám manuálního kódu pro ukládání do mezipaměti/načítání a proč existují a jsou tak široce přijímány vyhrazené knihovny pro stav serveru (React Query, SWR).

Rozdělení obou — stav UI v lokálních úložištích, stav serveru v knihovně pro ukládání do mezipaměti — dramaticky zjednodušuje aplikace s vysokou zátěží dat a eliminuje obrovskou kategorii boilerplate kódu a chyb zastaralosti.