How should a page distinguish loading, empty, and failed data?

Treat the result of the request as one of four states, rather than inferring everything from whether the list happens to contain items. A useful state map is:

1. Loading: the request is in progress. Show a progress message or indicator; don’t label the collection empty yet.
2. Success with no items (empty): the request completed successfully and returned an empty collection. Show an empty-state message, such as “No projects yet.”
3. Success with items: the request completed successfully and returned one or more items. Show the collection.
4. Error: the request did not complete successfully. Explain that the list could not be loaded and, if available, offer a retry.

The important distinction is that an empty state is a successful result. A failed request means the page does not know whether items exist. Keep each state explicit so an initial empty array or a failed request can’t accidentally render the empty-state message.

Separate variables can accidentally describe contradictory situations—for example, loading is true while an old error is still present. One option is a single state value that says what the request means now. For example, in JavaScript:

const state = { status: "loading" };

// After a successful response:
const nextState = items.length === 0
  ? { status: "success", items: [] }
  : { status: "success", items };

// If the request fails:
const failedState = { status: "error", message: "Could not load projects." };

The status controls which kind of information belongs in that state. In a typed application, you can define a discriminated union so that success carries items and error carries its error information. Even without types, follow that rule consistently. Make “not loaded yet” different from “loaded successfully and empty”; don’t use an empty array to mean both.

Here is a framework-neutral JavaScript rendering sketch. renderMessage and renderList stand for your own rendering functions; the example assumes items is an array after a successful response.

function render(state) {
  switch (state.status) {
    case "loading":
      return renderMessage("Loading projects…");

    case "success":
      return state.items.length === 0
        ? renderMessage("No projects yet.")
        : renderList(state.items);

    case "error":
      return renderMessage("Projects could not be loaded.");

    default:
      throw new Error("Unknown project-list state");
  }
}

A request handler can set loading before it starts, success only after a successful response, and error when the request fails. If there is a retry control, its action should start a new request and return the interface to loading. Avoid showing a reassuring empty-state message on failure; it can mislead people into thinking there really are no projects. This sketch doesn’t define a particular framework, network client, or project-specific retry behavior.

Walk through one example for each state and ask what a person should see. For loading, use the moment before a response arrives. For empty, use a successful response with []. For success, use a successful response with at least one item. For error, use a rejected request or other failure path. Then check transitions: loading should lead to success or error; a retry should lead from error back to loading. If the product supports refreshing existing data, decide deliberately whether to keep showing that data while refreshing or replace it with a loading view. That’s an additional design choice, not a reason to treat a failure as empty.

A copyable review note for a simple first-load collection is:

loading → show progress success + [] → show empty message success + items → show list error → show failure message and retry if supported

As a final check, confirm every message matches what the application actually knows. A failed request cannot establish that the collection has no items.