Data Fetching and Server State on the Frontend

The fetch that looks fine and isn't

You build a profile page. You fetch the user in a useEffect, store it in useState, render a spinner while it loads. It works on your machine. Then a user clicks between two profiles fast, and the page shows the wrong person. Another user opens the same screen twice and you fire the same request twice. Someone leaves the tab and comes back to data that is ten minutes old. None of these are bugs in your code exactly, they are gaps in the *model* you used.

The fix is not a cleverer useEffect. It is recognizing that the data you fetch from a server is a fundamentally different kind of state than the data your UI owns, and that there is a whole category of library built to manage it. This article shows why, and how to do it right.

Server state is someone else's data, cached

UI state is state you own and can change at will. Server state is a local, temporary, possibly-stale copy of data that actually lives somewhere else, and can change without telling you.

Think about who is the source of truth. The toggle that says a dropdown is open? You own it. Nobody else can flip it. That is UI state, synchronous, yours, gone on refresh, and perfectly at home in useState or a store (see state management in frontend apps).

The list of orders for a customer? You do not own that. It lives in a database behind an API. Your component holds a *copy*. That copy is stale the instant another user, another tab, or a background job changes it. This is server state, and the hard parts, caching, knowing when the copy is too old, refetching, deduping, retrying a flaky network, are all about managing a copy of data you do not control.

Why useEffect + useState is a trap

Here is the canonical hand-rolled fetch. Read it and count the problems before the list below.

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    setLoading(true);
    fetch(`/api/users/${userId}`)
      .then((r) => r.json())
      .then((data) => {
        setUser(data);   // (!) which userId is this for?
        setLoading(false);
      })
      .catch((e) => {
        setError(e);
        setLoading(false);
      });
  }, [userId]);

  if (loading) return <Spinner />;
  if (error) return <ErrorBox error={error} />;
  return <Profile user={user!} />;
}

1. Race condition. Change userId from A to B quickly and both requests are in flight. If A's response lands after B's, you render A's data for B. There is no cancellation or request-versioning here.
2. No caching. Navigate away and back and you refetch from scratch, a spinner every time, even though you had the data two seconds ago.
3. No dedupe. Two components asking for the same user fire two identical requests. Nothing coordinates them.
4. No background refresh. Once loaded, the data is frozen until the component remounts. Stale data sits on screen indefinitely.
5. No retries, no focus refetch. A flaky request just fails. Coming back to the tab after an hour shows ancient data.
6. Boilerplate, repeated forever. Three pieces of state and the same try/catch dance in every component that fetches anything.

The same thing with a server-state library

A server-state library, TanStack Query, SWR, or RTK Query, turns all of that into a few lines. Here is the profile with TanStack Query.

import { useQuery } from '@tanstack/react-query';

function getUser(userId: string): Promise<User> {
  return fetch(`/api/users/${userId}`).then((r) => {
    if (!r.ok) throw new Error('Failed to load user');
    return r.json();
  });
}

function UserProfile({ userId }: { userId: string }) {
  const { data, isPending, isError, error, refetch } = useQuery({
    queryKey: ['user', userId],   // identity of this data
    queryFn: () => getUser(userId),
    staleTime: 30_000,            // fresh for 30s; no refetch within window
  });

  if (isPending) return <Spinner />;
  if (isError) return <ErrorBox error={error} onRetry={refetch} />;
  return <Profile user={data} />;
}

Same line count, but the race condition is gone (results are keyed by ['user', userId], so a late response for the old id can never overwrite the new one), the data is cached (revisit = instant render from cache), identical queries are deduped into one request, it retries failed requests, and it refetches in the background when the data goes stale or the window regains focus. You wrote the queryFn; the library owns everything around it.

Stale-while-revalidate: the mental model

The behavior that makes these libraries feel fast is stale-while-revalidate (SWR): when you ask for data that is already cached but stale, you get the cached copy *immediately* so the UI renders with no spinner, and a refetch fires in the background. When the fresh data arrives, the cache updates and the UI re-renders. The user sees content instantly, then a quiet update.

1. 1

   Ask

   The component calls useQuery with a key. The library checks the cache for that key.

2. 2

   Serve stale

   There is a cached entry but it is older than staleTime. Return it immediately so the UI paints with real content.

3. 3

   Revalidate

   In parallel, run the queryFn to fetch fresh data from the server.

4. 4

   Reconcile

   When the response arrives, write it to the cache under the same key.

5. 5

   Update

   Every component subscribed to that key re-renders with fresh data, usually an invisible swap.

Server state vs UI state, side by side

Before reaching for a tool, classify the state. If it is server state, it belongs in a query cache, not in useState or your global store.

Mutations, optimistic updates, and rollback

Reads are queries; writes are mutations. After a write, the cache holds stale data, so a mutation's job is not just to POST, it is to make the affected queries refetch. The simplest version invalidates by key on success.

import { useMutation, useQueryClient } from '@tanstack/react-query';

function useRenameTodo() {
  const qc = useQueryClient();
  return useMutation({
    mutationFn: (vars: { id: string; title: string }) =>
      fetch(`/api/todos/${vars.id}`, {
        method: 'PATCH',
        body: JSON.stringify({ title: vars.title }),
      }).then((r) => r.json()),
    onSuccess: () => {
      // mark the list stale -> it refetches with the new title
      qc.invalidateQueries({ queryKey: ['todos'] });
    },
  });
}

Invalidation is correct but it waits for a round trip before the UI changes. For instant feedback, do an optimistic update: write the expected result to the cache immediately, then roll back if the server rejects it.

function useToggleTodo() {
  const qc = useQueryClient();
  return useMutation({
    mutationFn: (todo: Todo) =>
      fetch(`/api/todos/${todo.id}`, {
        method: 'PATCH',
        body: JSON.stringify({ done: !todo.done }),
      }),
    // 1. before the request fires
    onMutate: async (todo) => {
      await qc.cancelQueries({ queryKey: ['todos'] });
      const previous = qc.getQueryData<Todo[]>(['todos']);
      qc.setQueryData<Todo[]>(['todos'], (old) =>
        old?.map((t) => (t.id === todo.id ? { ...t, done: !t.done } : t)),
      );
      return { previous }; // context handed to onError
    },
    // 2. on failure, restore the snapshot
    onError: (_err, _todo, ctx) => {
      if (ctx?.previous) qc.setQueryData(['todos'], ctx.previous);
    },
    // 3. always reconcile with the server
    onSettled: () => qc.invalidateQueries({ queryKey: ['todos'] }),
  });
}

1. 1

   onMutate

   Cancel in-flight refetches, snapshot the current cache, and apply the optimistic change so the UI updates instantly.

2. 2

   onError

   If the server rejects, roll the cache back to the snapshot you returned from onMutate.

3. 3

   onSettled

   Whether it succeeded or failed, invalidate so the next read reconciles with the server's real state.

Pagination and infinite queries

Lists that load in pages have their own trap: naive pagination flickers to a spinner on every page change. Use placeholderData to keep the previous page on screen while the next loads, and useInfiniteQuery for endless-scroll feeds.

import { useInfiniteQuery, keepPreviousData, useQuery } from '@tanstack/react-query';

// Paged: stays on the old page (no spinner flash) until the new one arrives
function usePagedTodos(page: number) {
  return useQuery({
    queryKey: ['todos', { page }],
    queryFn: () => fetchTodos(page),
    placeholderData: keepPreviousData,
  });
}

// Infinite: each page appended; getNextPageParam drives "load more"
function useFeed() {
  return useInfiniteQuery({
    queryKey: ['feed'],
    queryFn: ({ pageParam }) => fetchFeed(pageParam),
    initialPageParam: 0,
    getNextPageParam: (last) => last.nextCursor ?? undefined,
  });
}

Avoiding request waterfalls

A waterfall is when request B cannot start until request A finishes, not because B needs A's data, but because of how you wrote it. Components that each fetch in their own effect, nested, create a cascade: each level mounts, fetches, renders its child, which then mounts and fetches. The page is as slow as the sum of every hop.

// BAD: sequential, orders waits for user even though it doesn't need it
const user = await getUser(id);
const orders = await getOrders(id);

// GOOD: independent requests run in parallel
const [user, orders] = await Promise.all([getUser(id), getOrders(id)]);

// In React: independent useQuery calls already run in parallel.
// useQueries batches a dynamic list of them:
const results = useQueries({
  queries: ids.map((id) => ({ queryKey: ['user', id], queryFn: () => getUser(id) })),
});

// Prefetch on intent (hover/route enter) so data is warm before render:
function onHover(id: string) {
  queryClient.prefetchQuery({ queryKey: ['user', id], queryFn: () => getUser(id) });
}

Where this meets React Server Components

React Server Components (RSC) change *where* fetching happens. A server component runs on the server and can await data directly, no useEffect, no client cache, no loading state shipped to the browser. The HTML arrives with data already in it. That removes a class of client-side fetching entirely. (See React Server Components and the App Router.)

// Server Component, runs on the server, awaits data, no client JS for the fetch
export default async function UserPage({ params }: { params: { id: string } }) {
  const user = await getUser(params.id); // direct, on the server
  return <Profile user={user} />;
}

So does a server-state library still matter? Yes, for everything interactive. RSC is great for the initial, read-mostly render. But mutations, optimistic updates, polling, infinite scroll, refetch-on-focus, and anything that changes after load still live on the client. The modern pattern is both: fetch the initial data in a server component, then hydrate it into TanStack Query so client components take over with a warm cache and full interactivity.

Common mistakes that cost hours

1. Treating server data like UI state, stuffing fetched data into a global store and syncing it with effects. Let the query cache be the source of truth for remote data.
2. Unstable query keys, building the key from a fresh object or omitting a param. The cache fragments, dedupe breaks, and you refetch constantly. Keys must be serializable and include every input.
3. Optimistic update without a snapshot, no rollback path means a failed write silently leaves the UI lying.
4. Forgetting to invalidate after a mutation, the write succeeds but the list still shows the old data because nothing told it to refetch.
5. Sequential awaits for independent data, a self-inflicted waterfall; Promise.all or parallel queries fix it.
6. staleTime of 0 everywhere, every focus and remount refetches, hammering the API. Match staleTime to how often the data really changes.
7. Disabling retries globally then blaming flakiness, or retrying non-idempotent mutations. Retry reads; be careful with writes.

Takeaways and where to go next

Data fetching is one of three state problems on the frontend, the other two are local UI state and rendering. Solidify the neighbors and the whole picture clicks into place.

• state management in frontend apps, where server state fits among the kinds of state, and why your global store should not hold remote data.
• React fundamentals: hooks and rendering, the rendering and effect model that makes queries and re-renders behave the way they do.
• React Server Components and the App Router, moving fetching to the server and hydrating it into the client cache.