Zakaj razlikovati med stanjem vmesnika in stanjem strežnika?

Question

Accepted Answer

**Stanje vmesnika** je podatek, ki ga vaša aplikacija poseduje in nadzira lokalno (preklapljači, vnosi obrazcev, izbrani zavihek). **Stanje strežnika** je podatek, ki živi na strežniku in je le *predpomnjen* na odjemalcu (pridobljeni uporabniki, proizvodi, prispevki). Imajo fundamentalno različne značilnosti in potrebujejo različna orodja.

## Ključne razlike

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

## Zakaj obravnavanje podatkov strežnika kot stanja vmesnika ne deluje

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

Nakonec se znajdete v ponovno implementaciji sledenja nalaganju/napakam, predpomnenja, ponovnega pridobivanja, deduplikacije in upravljanja zastarelostjo — za vsako pridobitev.

## Pravo orodje: knjižnica za stanje strežnika

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

Te knjižnice so posebej zgrajene za problem stanja strežnika — ohranjanje lokalnega predpomnilnika v sinhronizaciji z oddaljenim virom.

## Praktična razdelitev

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

## Zakaj je to pomembno

Prepoznavanje, da je stanje strežnika **predpomnilnik oddaljenih podatkov** — ne navadno lokalno stanje — je velik vpogled za sodobno arhitekturo sprednjega dela.

To pojasnjuje, zakaj vnašanje podatkov API v Redux/useState vodi v gore ročnega predpomnenja/kode za nalaganje in zakaj namenjena knjižnica za stanje strežnika (React Query, SWR) obstaja in je tako pogosto sprejeta.

Razdelitev obeh — stanje vmesnika v lokalnih skladiščih, stanje strežnika v knjižnici za predpomnenje — dramatično poenostavi aplikacije, bogate s podatki, in izloči veliko kategorijo schematske kode in hroščev zastarelosti.