Server state vs client state: deciding who owns which truth

Two kinds of state with opposite physics

Before writing your next useEffect to fetch data, ask: who actually owns this truth? The useState/useReducer/store toolkit from the previous lessons manages client state: truth that originates in the UI — which tab is active, whether the modal is open, the sidebar width. You are its source of truth; it is synchronous, always correct, and dies with the session. Server state is a different substance that happens to flow through the same hooks if you let it: the project list, the user profile, prices. The server owns that truth. Your copy is a cache of someone else’s data — asynchronous, shared with other users who mutate it, and stale the moment it arrives. Caches have a lifecycle client state never has: fetching and refetching, deduplication of concurrent requests, invalidation after mutations, background revalidation, garbage collection of unused entries. A query library (TanStack Query, SWR, RTK Query) is not a “data fetching library” — fetching is one line. It is a cache manager: entries keyed by query key, with staleness tracking, dedupe, focus/interval revalidation, and mutation-driven invalidation. That lifecycle is the actual work, and hand-rolling it per-component is how the rename ghost is born.

The bug class: copying server data into useState

The anti-pattern looks harmless and compiles fine:

// ANTI-PATTERN: forking server truth into local state
function ProjectList() {
  const [projects, setProjects] = useState([]);
  useEffect(() => {
    fetchProjects().then(setProjects); // private copy, frozen at fetch time
  }, []);
  // ...
}

// Cache-managed: one shared entry, invalidated by mutations
function ProjectListFixed() {
  const { data: projects } = useQuery({
    queryKey: ["projects"],
    queryFn: fetchProjects,
  });
  // rename elsewhere: queryClient.invalidateQueries({ queryKey: ["projects"] })
}

The mechanism of the bug: the moment server data lands in useState, it forks. The component owns a snapshot with no key identifying what it is a copy of, so no mutation can find and invalidate it; two components fetching the same resource hold independent forks that disagree after any write; a refetch races a mutation and the slower response wins, resurrecting old data. Every “fix” — event buses, prop-drilled refresh callbacks, manual refetchAll() — is a hand-rolled, bug-for-bug reimplementation of cache invalidation. The derived variant is subtler and survives reviews: useState(props.user.name) to “initialize” — the initializer runs once on mount, so when the query refetches and props update, the state keeps the stale fork. If you need a transformed view of server data, derive it during render (const sorted = useMemo(...)) — derivation recomputes from fresh truth; copying freezes dead truth.

Form state: the third kind — a deliberate fork

Forms look like a contradiction: an edit form must copy server data into local state — the user types into the draft. The resolution is that a draft is a fork on purpose, with an explicit commit. Divergence from the server is the feature (the user is editing); submit is the commit point that sends the draft back and invalidates the cache. The discipline that keeps deliberate forks safe: the draft is initialized from server data once per editing session, never silently re-synced mid-edit (imagine a background refetch overwriting a half-typed field), and the component remounts when the subject changes — key={project.id} on the form, so editing a different project gets a fresh draft instead of a stale one. Form libraries (react-hook-form, the form tag with actions) are this discipline productized: dirty tracking, reset-on-success, validation on the draft.

The decision table