React Async Data Fetching: Prevent Stale UI & Race Conditions

Give each response an owner

Async bugs are often ordering bugs. Request A begins, the user changes the query, and request B begins. If B finishes first and A finishes last, an unguarded setState lets an older intent overwrite the newer screen. The network did exactly what it was allowed to do; the interface failed to declare which result still owns the view.

Start by separating data that belongs to the server from transient interface state. The ownership model in our React state-management guide helps here: server data is not a copy of form state, and a loading flag should not stand in for a resource's real lifecycle.

Cancel work that no longer matters

An ignore flag prevents a stale response from updating React, but it does not free the browser connection, server work, or bandwidth. When the fetch API is involved, create an AbortController for the active request and abort it in the effect cleanup. Treat abort as expected control flow, not as an error banner for the user.

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/search?q=${encodeURIComponent(query)}`, {
    signal: controller.signal,
  })
    .then((response) => response.ok ? response.json() : Promise.reject(response))
    .then((data) => setResults(data))
    .catch((error) => {
      if (error.name !== "AbortError") setError(error);
    });

  return () => controller.abort();
}, [query]);

Cancellation is cooperative. Pass the signal through every layer that can honor it, including a client SDK or a server-side downstream request. Still retain the latest-request check: a response can win the race just before cleanup runs, and not every async API supports aborting. For endpoints that may be repeated after a timeout, pair the client behavior with idempotency keys on the Node.js side.

Model loading, empty, error, and stale data separately

A spinner is not a data model. A screen may have no data yet, usable data while a background refresh runs, an empty successful result, a retryable error, or data that is known to be old. Make those distinctions visible in the state and in the interface so users do not lose a usable page every time a refresh begins.

• Show a full loading state only when there is no trustworthy data for the current key.
• Keep prior results visible during a related transition, with a subtle refreshing indicator when that remains honest.
• Render a specific empty state only after a successful response with zero matching items.
• Preserve a retry action and a meaningful error message; never replace a valid record with a blank failure panel.

Loading and errors are part of the product's recovery design. Use focused component boundaries and retry affordances alongside the failure isolation practices in our React error-boundaries guide so one failing widget does not erase an otherwise useful page.

Deduplicate by resource key instead of hand-rolling global flags

Two components asking for the same project should not create two unrelated requests and two conflicting loading states. A query cache or a small application data layer can use the resource key to share in-flight work, retain a last successful value, invalidate after a mutation, and apply a consistent retry policy.

Keep mutation consequences explicit. After a successful write, either update the affected cached record deliberately or invalidate the narrow resource keys that can be stale. Broadly clearing every cached value is slow and can trigger a refresh storm. If server-rendered content also needs an update, use the targeted path and tag practices in our Next.js cache-revalidation guide.

Combine aborting with latest-request protection

This compact hook gives one screen a clear owner for its fetch. The sequence ref rejects any completion that is no longer current; the controller ends obsolete network work. A production data library can provide this behavior too, but the ownership rules stay the same.

import { useEffect, useRef, useState } from "react";

export function useProject(projectId) {
  const requestNumber = useRef(0);
  const [state, setState] = useState({ status: "idle", data: null, error: null });

  useEffect(() => {
    if (!projectId) return;
    const request = ++requestNumber.current;
    const controller = new AbortController();
    setState((previous) => ({ ...previous, status: "loading", error: null }));

    fetch(`/api/projects/${projectId}`, { signal: controller.signal })
      .then((response) => response.ok ? response.json() : Promise.reject(response))
      .then((data) => {
        if (request === requestNumber.current) setState({ status: "success", data, error: null });
      })
      .catch((error) => {
        if (error.name !== "AbortError" && request === requestNumber.current) {
          setState((previous) => ({ ...previous, status: "error", error }));
        }
      });

    return () => controller.abort();
  }, [projectId]);

  return state;
}

Do not depend on a component being mounted as the only safety condition. The important question is whether the response belongs to the current screen state. Also consider React development behavior that intentionally re-runs effects: cleanup needs to be safe and a duplicate development fetch should never create a duplicate server-side action.

Test the order you hope never happens

Most happy-path tests resolve requests in the order they were made. Write at least one test where the first request resolves after the second, then assert that the newest data remains visible. Test unmount cleanup, an abort that should not display an error, a failed refresh with preserved data, and a mutation that invalidates only the affected query.

In production, measure request start, completion, abort, deduplication, error category, resource family, and duration. Avoid logging raw search terms, tokens, or personal data. When an upstream dependency is slow, bounded client retries and cancellations should complement—not fight—the server timeouts and fallbacks in our Node.js circuit-breaker guide.

React async data checklist