Good loading UX is more than "show a spinner." It's about modeling states correctly and choosing the right fallback.

Model state as an enum, not a boolean

status: "idle" | "loading" | "success" | "error" | "empty"

A single isLoading boolean can't express "loaded but empty," "error," or "refetching in the background." An enum (or a state machine) makes every state explicit and prevents impossible combinations.

Skeleton screens > spinners (for content)

• Skeleton screens — gray placeholder shapes mimicking the real content's layout. They communicate what's coming, reduce perceived wait, and — crucially — prevent layout shift because they occupy the same space the content will.
• Spinners — fine for short, indeterminate actions (a button submit), but for loading a page/list they feel slower and cause a jarring swap.
• Progress bars — when you can estimate completion.

Avoid the jank

• Match the skeleton to the final layout — same dimensions, same structure — or content "pops in" and shifts (bad CLS).
• Debounce the indicator for fast loads — if data usually arrives in <200–300ms, showing then instantly hiding a spinner is a worse flicker than showing nothing. Delay the indicator; if the load finishes first, the user never sees it.
• Set a minimum display time — conversely, if you do show a spinner, a tiny minimum (~300ms) avoids a flash.

Don't forget the other states

The mark of a complete answer: loading is one of four states, and all must be designed:

• Empty — "No results yet" with guidance, not a blank screen.
• Error — a message and a retry action, not a dead end.
• Success — the actual content.

Suspense for declarative loading

React.Suspense provides a declarative fallback for lazy-loaded components and (with a Suspense-enabled data layer) for data:

<Suspense fallback={<ProfileSkeleton />}>
  <Profile />
</Suspense>

It co-locates the fallback with the boundary and handles the loading state for you.

Other touches

• Optimistic UI — for mutations, show the result immediately and roll back on error; no spinner at all.
• Preserve old data on refetch (keepPreviousData) — don't blank the screen to re-show a skeleton.
• Accessibility — aria-busy, aria-live so screen readers know something is loading/arrived.

The framing

"I model status as an enum — idle/loading/success/error/empty — not a boolean, so every state is explicit. For content I prefer skeleton screens that match the final layout: they reduce perceived wait and prevent layout shift, where a spinner causes a jarring swap. I debounce the indicator so fast loads don't flicker, and I always design the empty and error states — error with a retry — not just the happy path. For code or Suspense-enabled data, <Suspense fallback> makes it declarative; for mutations, optimistic UI skips the spinner entirely."