Loading, errors and slow networks: Full-Stack Development (Intermediate)

Three pieces of state

While a request is on its way, the screen must know three things: is it loading, did it fail (error), and what came back (data). In React each one is a piece of state. try/catch/finally fits this well: try does the request, catch stores the error, and finally runs in both cases, so it is the right place to turn loading off.

javascript

function NotesList() {
  const [notes, setNotes] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();
    async function load() {
      setLoading(true);
      setError(null);
      try {
        const res = await fetch('/api/notes', { signal: controller.signal });
        if (!res.ok) throw new Error('HTTP ' + res.status);
        const data = await res.json();
        setNotes(data.notes);
      } catch (err) {
        if (err.name !== 'AbortError') setError(err);
      } finally {
        if (!controller.signal.aborted) setLoading(false);
      }
    }
    load();
    return () => controller.abort(); // leaving the page cancels the request
  }, []);

  if (loading) return <p>Loading notes...</p>;
  if (error) return <ErrorBanner error={error} />;
  return <NoteGrid notes={notes} />;
}

Loading, error and data in one component. The cleanup function aborts the request when the user leaves the page, and an aborted request is not shown as an error.

Think of it like this: Booking a cab on a phone app works like this. First you see "Finding your driver" (loading). If nobody accepts in a few minutes, the app says "No cabs nearby, try again" (a timeout with a friendly message). If you press Cancel, the app stops searching at once (abort). And if your mobile data drops, it says "No internet", which is a different problem from "no cabs".

Two kinds of failure

	Network error	HTTP error
What happens	fetch rejects (throws), often TypeError: Failed to fetch	fetch resolves, but res.ok is false
Typical causes	No internet, server down, CORS blocked, timeout	400 bad input, 401 not logged in, 404, 500 server bug
Is there a body?	No answer at all	Yes, usually { error: { code, message } }
What to tell the user	"You seem to be offline" or "Taking too long"	The server's message, or a friendly text for the status

Timeouts and cancelling

fetch has no short timeout of its own; on a weak signal a request can hang for a long time. An AbortController is an object with a signal you pass to fetch; calling controller.abort() cancels the request, and fetch rejects with an error named AbortError. AbortSignal.timeout(ms) is a ready-made signal that cancels itself after ms milliseconds; its error is named TimeoutError.

javascript

try {
  const res = await fetch('/api/notes', { signal: AbortSignal.timeout(8000) });
  // ... check res.ok and read the JSON
} catch (err) {
  if (err.name === 'TimeoutError') showMessage('The server is taking too long. Please try again.');
  else showMessage('You seem to be offline. Check your internet and try again.');
}

Give up after 8 seconds instead of spinning forever.

Retry, but only when it is safe

Some failures are temporary: a network blip, or a 502, 503 or 504 while the server restarts. Retrying a GET is safe, because reading the notes twice changes nothing. Retrying a 4xx is pointless: the request itself is wrong, so the answer will be the same. Wait longer before each new try (500 ms, then 1 s, then 2 s), which is called exponential backoff, so a struggling server is not flooded.

Careful: Never retry a POST automatically when you do not know if it reached the server. If the server saved the note (or took the money) and only the answer was lost, a retry makes a second note, or a double UPI payment. Payment systems use an idempotency key: a unique id the client creates once per action and sends with every try. The server remembers it and ignores repeats.

javascript

// Create the key ONCE when the user presses Pay, and reuse it for any retry
const key = crypto.randomUUID();
await fetch('/api/payments', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json', 'Idempotency-Key': key },
  body: JSON.stringify({ amount: 499, upiId: 'asha@okbank' }),
});

If the same key arrives twice, the server returns the first result instead of charging again.

Friendly messages and double submits

Situation	Message to show
Network error	You seem to be offline. Check your internet and try again.
Timeout	The server is taking too long. Please try again.
400 with a message	The server's message, such as "Title is required", next to the field
401	Please log in again. (then go to the login page)
404	This note was not found. It may have been deleted.
500 to 599	Something went wrong on our side. Please try again.

A double submit happens when an impatient user taps Save twice on a slow network and two notes are created. Disable the Save button while saving, change its text to "Saving...", and enable it again only when the answer (or an error) arrives.

Tip: Test the bad cases on purpose. In Chrome DevTools, the Network tab has a throttling menu with "Slow 4G" and "Offline". Stop your Express server too, and check that every screen shows a clear message instead of a blank page.

Loading, errors and slow networks

Explanation

Three pieces of state

Two kinds of failure

Timeouts and cancelling

Retry, but only when it is safe

Friendly messages and double submits

Watch the lesson

In real life: Booking a train ticket at a busy hour

Practice (0/3 done)

Quick quiz

Read more (free)