Data-Fetching Patterns in React

The plain-language idea

The obvious way to fetch data in a component is: useEffect runs, kicks off a fetch, and setState when it resolves. That works — until the thing you're fetching by changes quickly, like a userId prop flipping from 1 to 2 before the first request has come back. Now you have two in-flight requests, and there's no guarantee they resolve in the order they were sent. If the request for userId=1 resolves after the request for userId=2, you silently overwrite fresh data with stale data.

This is why "just fetch in an effect" is the pattern you learn first and the pattern real apps mostly move away from. Cache-based libraries (React Query, SWR, and RSC's built-in fetch deduping) exist specifically to close this gap, plus a handful of related ones a raw effect doesn't handle at all.

See it in a real thing: the race condition, and the fix

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    let ignore = false;

    fetch(`/api/users/${userId}`)
      .then((r) => r.json())
      .then((data) => {
        if (!ignore) setUser(data);
      });

    return () => {
      ignore = true; // runs before the next effect, and on unmount
    };
  }, [userId]);

  return user ? <Profile user={user} /> : <Spinner />;
}

If userId changes from 1 to 2, the effect's cleanup runs first and sets ignore = true for the old closure — the one still waiting on the request for userId=1. When that request finally resolves, ignore is true inside that specific closure, so setUser is skipped. Only the request that matches the current userId is allowed to update state.

Miss the ignore guard entirely and this becomes a genuine bug: switch to a user, switch away, and if the first request is slow enough, its response can land after the second one and clobber the profile you're actually looking at.

A cache-based library does this same guard for you automatically, and adds what a hand-rolled effect doesn't: caching per query key (switching back to userId=1 is instant if it's still cached), request deduping (two components fetching the same userId share one request), and background revalidation instead of a manual refetch button.

What people usually miss

Watch out

• Forgetting the cleanup guard is the single most common bug in effect-based fetching, and it's silent — nothing throws, the UI just occasionally shows the wrong data for a moment, which makes it easy to ship without ever noticing in dev.
• The race isn't about the network being slow — it's about order not being guaranteed. Even fast, reliable requests can resolve out of order if they were sent close together; this isn't an edge case you can dismiss as "won't happen on a good connection."
• Cache libraries aren't "a nicer useEffect." They model a fetch as a query with an identity (a key), with its own lifecycle — staleness, garbage collection, refetch-on-focus — none of which a plain effect has any concept of at all.
• Loading and error states are easy to forget by hand. The example above has no error handling; a real effect-based fetch needs a .catch() and an error state too, which is one more piece cache libraries give you as a built-in convention instead of a per-component reinvention.

The genealogy: the cleanup function is doing the real work

The ignore guard only works because of the cleanup-function timing covered in the earlier lesson on side effects — cleanup runs before the next effect fires, which is precisely what lets the previous, now-outdated request recognize itself as outdated when it finally resolves.