De ce să deosebești starea UI de starea serverului?

Question

Accepted Answer

**Starea UI** este datele pe care aplicația ta le deține și controlează local (comutatoare, intrări de formular, tab selectat). **Starea serverului** sunt datele care trăiesc pe un server și sunt doar *cache-ate* pe client (utilizatori preluați, produse, postări). Au caracteristici fundamental diferite și au nevoie de instrumente diferite.

## Diferențele cheie

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

## De ce tratarea datelor serverului ca stare UI merge rău

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

Ajungi să reimplementezi urmărirea încărcării/erorii, cache-erea, refetching, deduplicare și manipularea staleness — pentru fiecare fetch.

## Instrumentul potrivit: o bibliotecă de stare a serverului

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

Aceste biblioteci sunt construite special pentru problema stării serverului — menținerea unui cache local sincronizat cu o sursă la distanță.

## Împărțirea practică

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

## De ce este important

Recunoașterea că starea serverului este un **cache al datelor la distanță** — nu stare locală obișnuită — este o perspectivă majoră pentru arhitectura modernă a frontend-ului.

Aceasta explică de ce aruncarea datelor API în Redux/useState duce la munți de cod manual de cache/încărcare, și de ce bibliotecile dedicate de stare a serverului (React Query, SWR) există și sunt atât de larg adoptate.

Împărțirea celor două — stare UI în magazine locale, stare server în bibliotecă de cache — simplifică drastic aplicațiile cu date intensive și elimină o categorie imensă de cod repetat și bug-uri de staleness.