Fetching in effects: races, waterfalls, and why the baseline is worth knowing

The honest baseline: an effect, a param, three states

A fetch-in-effect is a synchronization: “while this component shows query q, the screen should hold the server’s answer for q.” The effect re-runs whenever query changes, and you hand-write the three states every data UI needs — loading, error, data:

function FlightSearch({ query }) {
  const [results, setResults] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    let ignore = false;                    // race guard
    const controller = new AbortController(); // network cancel
    setLoading(true);
    setError(null);

    fetch(`/api/flights?q=${encodeURIComponent(query)}`, {
      signal: controller.signal,
    })
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      })
      .then((data) => {
        if (!ignore) { setResults(data); setLoading(false); }
      })
      .catch((err) => {
        if (err.name === "AbortError") return; // expected on cleanup
        if (!ignore) { setError(err); setLoading(false); }
      });

    return () => {            // runs before re-run and on unmount
      ignore = true;
      controller.abort();
    };
  }, [query]);
  // render loading / error / results...
}

That is roughly twenty lines per endpoint, and every line earns its place. The shape to internalize: the effect body starts a request tied to one value of query; the cleanup disowns it. React guarantees cleanup runs before the next effect body and on unmount — that ordering is the entire correctness story.

The race: responses do not return in the order you sent them

Type “w”, “wa”, “war” quickly and you issue three requests. HTTP gives no ordering guarantee across requests — caches, retries, and server load reorder them freely. Without a guard, each response calls setResults, and the slowest request paints last. The two guards do different jobs. The ignore flag is correctness: a closure variable per effect run; when cleanup flips it, the stale closure’s setResults becomes a no-op. The response still downloads — you just refuse to commit it. AbortController is efficiency: it cancels the network work itself, freeing the browser’s per-origin connection slots (HTTP/1.1 allows 6) and the server’s time. Abort alone is almost enough — the rejected promise exits via AbortError — but the ignore flag also protects non-abortable async work after the fetch (a res.json() already in flight, a chained transform), so the pair is the idiom. StrictMode runs setup→cleanup→setup on dev mount precisely to prove your cleanup actually disowns the first request: if you see doubled commits in dev, the production race is real.

Waterfalls: the component tree becomes your network schedule

The second structural problem is invisible in any single component. ProfilePage fetches the user, renders <Posts userId={...}> only after the user arrives, and Posts fetches posts, then renders <Comments> which fetches again. Each fetch starts only after the parent’s data has landed and the child has mounted — so three logically independent requests run in series. At 200 ms per round trip that is 600 ms of pure structure-imposed latency before counting server time; on a 75 ms-RTT LTE connection with TLS setup, real traces routinely show 1.5–2 s waterfalls on pages that could load in one round trip. The network panel signature is unmistakable: a staircase. The tree decided your schedule, and the tree knows nothing about the network. Cures, in increasing order of ambition: hoist the fetches to the highest component that knows all the parameters and run them with Promise.all; start fetches before rendering (in the route loader or event handler) and pass promises down; or hand the problem to a library or framework whose cache decouples “who renders this” from “who fetches this”. That last move is the subject of the rest of this unit.