The Fetch Lifecycle: Loading, Success, Error, Empty States

The plain-language idea

A component that fetches data isn't just "loading" or "loaded." It moves through a real sequence of states, and the UI has to render something correct for each one:

• Idle — no request has started yet (useful when a fetch is triggered by user action, like a search box, rather than firing on mount).
• Loading — a request is in flight; nothing to show yet but the fetch hasn't failed either.
• Success — the request resolved, and inside success there are genuinely two different UIs: populated (there's data to render) and empty (the request worked fine and correctly returned zero results).
• Error — the request failed, and the UI needs to say so instead of pretending nothing happened.

The mistake that causes real bugs is representing this as a handful of independent booleans — isLoading, isError, hasData — instead of one variable that can only ever be exactly one of these states at a time.

See it in a real thing: a search results component

type FetchState<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T[] }
  | { status: "error"; message: string };

function useSearchResults(query: string) {
  const [state, setState] = useState<FetchState<Result>>({ status: "idle" });

  useEffect(() => {
    if (!query) {
      setState({ status: "idle" });
      return;
    }
    let cancelled = false;
    setState({ status: "loading" });

    fetchResults(query)
      .then((data) => {
        if (!cancelled) setState({ status: "success", data });
      })
      .catch((err) => {
        if (!cancelled) setState({ status: "error", message: err.message });
      });

    return () => {
      cancelled = true;
    };
  }, [query]);

  return state;
}

Idle: no request has started. Nothing to render yet.

BackNext

The rendering side then does an exhaustive switch on status, and this is where the empty state earns its own branch: state.status === "success" && state.data.length === 0 is not an error and it's not still loading — it's a correct, successful response that happens to have nothing in it. It needs its own UI (usually "no results, try a different search" style copy), because rendering nothing at all there looks broken, and rendering the loading spinner there is simply wrong.

What people usually miss

Watch out

• A boolean pair like isLoading and error can both be true at once, and nothing stops that. With independent booleans there's no code-level guarantee the UI can't ask "are we loading AND erroring AND have data" simultaneously — a string-union state makes that combination unrepresentable instead of just unlikely.
• Empty is not an error and not loading — it's its own success sub-case. A successful fetch that returns zero rows needs deliberate empty-state UI, not a fallthrough to "loading" or a blank screen.
• Idle is a real, separate state, not the same as loading. A search box before the user has typed anything shouldn't show a spinner or an empty-results message — it hasn't fetched yet at all.
• Forgetting the cleanup/cancellation check lets a stale response overwrite a newer one. If the query changes mid-flight, an older, slower response resolving after a newer one can stomp the correct result with a stale one unless the effect tracks which request is still current.
• "Just add another boolean" is how this gets worse over time, not better. Every new edge case (retrying, refetching in the background) as its own flag multiplies the number of technically-reachable-but-nonsensical state combinations; a single state enum caps that.

Why this matters in interviews

"Walk me through how you'd manage the states of a data-fetching component" is a real, common question, and naming idle/loading/success/error plus the empty-vs-populated split inside success — unprompted — is what separates a candidate who's shipped this from one who's only used isLoading on autopilot.