Fetching Data from an API

Almost every interesting application in the React for Beginners series loads data from somewhere else: a REST endpoint, a search service, your own backend. Fetching looks simple — call fetch, put the result in state — but the details (loading states, errors, cancellation, race conditions) are what separate a demo from a working feature. This chapter builds the pattern you will reuse everywhere.

The three states of remote data

Whenever data comes from the network, the UI must handle three mutually exclusive conditions — plus a fourth that beginners forget:

Model them explicitly with state. A single status string plus a data value keeps impossible combinations (loading and showing data) out of your component.

The standard effect

Fetch inside useEffect, list the trigger values as dependencies, and update state when the response arrives:

import { useEffect, useState } from 'react';

function UserList() {
  const [users, setUsers] = useState([]);
  const [status, setStatus] = useState('loading');  // loading | error | ready

  useEffect(() => {
    async function load() {
      try {
        const res = await fetch('https://jsonplaceholder.typicode.com/users');
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        const json = await res.json();
        setUsers(json);
        setStatus('ready');
      } catch (err) {
        setStatus('error');
      }
    }
    load();
  }, []);

  if (status === 'loading') return <p role="status">Loading users…</p>;
  if (status === 'error') return <p className="error">Could not load users.</p>;
  return (
    <ul>{users.map((u) => <li key={u.id}>{u.name}</li>)}</ul>
  );
}

Expected output: briefly "Loading users…", then the list of names — or an error message if the request fails. Every branch of the UI is covered, so the screen is never mysteriously blank.

Cancellation: the race condition

If the effect can re-run (different id in the URL, for example), two requests may be in flight at once — and the slower one can arrive last and overwrite fresher data. Modern fetch solves this with an AbortController returned as the effect's cleanup:

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

  async function loadPost() {
    setStatus('loading');
    try {
      const res = await fetch(`/api/posts/${postId}`, {
        signal: controller.signal,
      });
      const json = await res.json();
      setPost(json);
      setStatus('ready');
    } catch (err) {
      if (err.name !== 'AbortError') setStatus('error');
    }
  }
  loadPost();

  return () => controller.abort();   // cancels the stale request
}, [postId]);

Expected output: switching rapidly between posts leaves only the last request's result on screen; aborted requests are silently ignored instead of surfacing as errors. This is the same cancellation idea you may know from the Fetch chapter, now wired into React's lifecycle.

React 18/19 semantics

Two behaviours worth knowing for 2026-era React:

• Effects run once per mount in development — StrictMode mounts, unmounts and remounts to verify your cleanup; a correctly paired effect fetches twice in dev and once in production, with no leaked requests.
• State updates after unmount are ignored, not fatal — React no longer warns about setting state on an unmounted component, but cancellation still matters for bandwidth and race conditions.
• async does not belong directly in the effect callback — the callback must return nothing (or your cleanup), so declare an inner async function and call it, exactly as above.

Loading and retrying

A polished loader is more than a spinner. Keep the previous data visible while refetching (avoid layout jumps), disable the button that triggered the request, and offer a retry that simply increments a refreshKey in the dependency array — re-running the effect without new props:

const [refreshKey, setRefreshKey] = useState(0);
useEffect(() => { /* fetch using refreshKey as a trigger */ }, [refreshKey]);

return (
  <>
    {status === 'error' && (
      <button onClick={() => setRefreshKey((k) => k + 1)}>Try again</button>
    )}
  </>
);

Expected output: after a failure the user clicks "Try again" and the same effect re-runs — no reload, no duplicated fetch code.

Beyond raw fetch

This pattern is the foundation. As applications grow, libraries such as TanStack Query or SWR add caching, background refetching and request de-duplication on top of exactly these states. Learn the manual version first — you will then understand what those tools automate.

Common mistakes

• Fetching without a loading state — the UI flashes empty and looks broken on slow connections.
• Ignoring non-2xx responses — fetch only rejects on network failure; a 404 or 500 still needs an explicit res.ok check.
• Missing or wrong dependencies — fetching a record by id with [] shows the first record forever.
• Letting stale responses win — without cancellation, an old request can overwrite newer data.
• Calling setState outside any guard in a loop — update once per request, after validation, and only for the request that is still relevant.

Practice checklist

1. Build the user list with all four states, including the empty case (use a URL that returns []).
2. Log the network tab: confirm requests are made once per mount and once per dependency change.
3. Add AbortController cancellation and test it by switching records quickly.
4. Implement the retry button via a refresh key.
5. Simulate an error (typo the URL) and verify the error branch renders with a working retry.

Data now flows from the server into your UI. To keep it organised as the app grows, reshape your components with Component Composition and Children.