Server State vs Client State

The plain-language idea

Client state is state your app fully owns and controls — a form's current input, whether a menu is open, the selected tab. Server state is a local cache of data that actually lives somewhere else — an API, a database — which means your copy of it can become stale at any moment without your app doing anything.

// The naive approach: server state handled like client state
function Profile({ userId }) {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetch(`/api/users/${userId}`).then((r) => r.json()).then(setUser);
  }, [userId]);
  // no loading state, no error state, no cache, no re-fetch on window refocus,
  // no dedup if another component fetches the same user at the same time...
}

This works for the simplest case, but server state has needs client state never does: loading/error states, caching, deduplication of identical in-flight requests, background re-fetching, and cache invalidation after a mutation. Writing all of that by hand in every component that fetches data is exactly the problem dedicated data-fetching libraries (React Query, SWR, RTK Query) exist to solve.

Client state: theme, form input, isOpen — lives only in this browser tab, owned by useState.

BackNext

What people usually miss

Watch out

• Putting server state in Redux/Context and treating it like client state is a very common real-world mistake — you inherit all the caching/staleness/loading-state problems yourself instead of using a tool built for exactly that.
• "Stale-while-revalidate" is the dominant strategy: show the cached (possibly stale) data immediately, while quietly re-fetching in the background to update it — better perceived performance than always showing a spinner.
• Two components both needing the same server data ideally share one cache entry, not two independent fetches — this is exactly what request deduplication in these libraries handles, and what the naive useEffect version above doesn't.

Why this matters in interviews

"How would you handle data fetching in a large React app?" is really asking whether you distinguish server state from client state — recognizing that "just useState + useEffect" doesn't scale to caching, staleness, and shared requests is the actual signal.