React API Integration: Loading, Error Handling and Retry

Why this concept matters

Unlike a local array, server data arrives later and may fail. A dependable React screen distinguishes waiting, success and failure.

Server responses can take time, fail or contain unexpected data. You will learn: explain the idea, follow the execution flow, read a compact example and try one realistic decision. Basic React components, props and useState are helpful; this Byte also works as a standalone introduction.

Start with a familiar scenario

Ordering online shows the idea: an order can be pending, confirmed, or failed. API-backed screens need the same explicit states.

Vocabulary: request, response, loading, error, retry, server state.

Understand the core concept

Think of ordering a parcel: processing is not the same as delivered, and a failed delivery needs a retry path. A data view similarly has at least pending, error and success situations.

Keep remote data distinct from local UI state. Fetch may resolve on HTTP errors, so check response.ok. Represent loading, success and error; provide a retry action. Protect against stale requests. For larger systems, server-state libraries can handle caching and synchronization.

When not to use it: Select the simplest React feature that solves the actual problem. An advanced API or Hook is not a requirement for every component.

Architecture and execution flow

Trace the information as it moves through the application. Every stage has a specific purpose.

01Request → loading → response validation → success / error → retry

Interactive decision lab

Choose an answer to a realistic development situation. Review the resulting explanation before writing code.

Try It Yourself — code and browser output

1import { useReducer, useState } from 'react';2type Issue = { id: number; title: string; priority: 'Low' | 'High' };3type Action = { type: 'add'; issue: Issue };4function reducer(state: Issue[], action: Action): Issue[] {5  switch (action.type) {6    case 'add': return [...state, action.issue];7  }8}9export default function App() {10  const [issues, dispatch] = useReducer(reducer, []);11  const [title, setTitle] = useState('');12  const [error, setError] = useState('');13  function addIssue() {14    if (!title.trim()) { setError('Title is required'); return; }15    dispatch({ type: 'add', issue: {16      id: Date.now(), title: title.trim(), priority: 'Low'17    } });18    setTitle(''); setError('');19  }20  return <main>21    <h1>Issue Desk</h1>22    <label htmlFor="issue">Issue title</label>23    <input id="issue" value={title} onChange={e => setTitle(e.target.value)} />24    {error && <p role="alert">{error}</p>}25    <button onClick={addIssue}>Add issue</button>26    <ul>{issues.map(i => <li key={i.id}>{i.title}</li>)}</ul>27  </main>;28}

Experiment: Click Load / Retry with failure disabled. Then enable Simulate server failure, retry and inspect the visible error. Disable it and retry again. Explain why the UI must not display old data as a successful new response.

Guided code walkthrough

Step 1 — Identify the inputs and the expected output. Server responses can take time, fail or contain unexpected data.

Step 2 — Read the implementation. The example is intentionally small; it isolates the concept before introducing additional application architecture.

01type Issue = { id: number; title: string };02async function loadIssues(signal: AbortSignal): Promise<Issue[]> {03  const response = await fetch('/api/issues', { signal });04  if (!response.ok) throw new Error('Could not load issues');05  return (await response.json()) as Issue[];06}

Step 3 — Predict the browser result. Show pending status, then issues or an error with Retry. The API path is illustrative, not included as a backend.

Step 4 — Explain the execution. Request; then loading; then response validation; then success / error; then retry.

Step 5 — Verify. Run the example in a React/TypeScript project with the appropriate installed package or mock API. The purpose is understanding behavior, not copy-pasting an unexplained application.

Common mistakes and recovery

Assuming fetch rejects on HTTP 404; showing a blank screen during loading; displaying stale results.

When behavior is surprising, verify the inputs and first observable failure. Check browser-console warnings, network responses and visible error states before adding complexity.

How developers use this at work

This pattern appears in customer portals, internal dashboards and SaaS products. Developers use it to make interfaces predictable and maintainable. QA engineers test the user-facing outcome, while product teams define valid states and errors.

What users see versus system behavior

Practice task

Use a mock Promise returning two issues; simulate an error and show Retry.

Success check: describe the input, the React action and the output. Try the failure case once, then explain the recovery.

Interview Bit

Does fetch reject automatically for HTTP 404? No. Network failures can reject, but HTTP responses normally resolve; inspect response.ok and handle the returned status.

Key Takeaways

1. API records are server data, not the same as local input draft state.
2. fetch is asynchronous, so loading must be visible.
3. HTTP error status does not always reject the fetch promise.
4. Check response.ok before trusting the response.
5. Handle invalid data and network failures separately.
6. Retry must start another request, not merely hide the message.
7. Ignore or cancel stale responses when requests overlap.
8. For larger apps, routing or server-state libraries may simplify loading and caching.

Knowledge Check and Primary Sources

FAQ: Is this technique required in every React component? No; apply it only when the corresponding problem exists.

FAQ: Can it be tested without a real backend? Yes, with local examples and mock responses.

FAQ: Should learners understand the underlying JavaScript? Yes. Hooks and libraries build on ordinary functions, arrays, objects and promises.

Primary sources: Official reference 1 · Official reference 2.