Suspense Boundaries

## What a boundary is `<Suspense>` is an ordinary React component with one special prop, `fallback`. Everything you nest inside it is the real UI. `fallback` is the placeholder React puts on screen in that subtree's place while something inside it is not ready. ```jsx <Suspense fallback={<p>Loading chart…</p>}> <RevenueChart /> </Suspense> ``` Nothing about `RevenueChart` changes. The boundary is a declaration about the *hole in the screen*: "if anything under here isn't ready, show this instead." ## What "not ready" means A component becomes suspended when it tries to render something that has not arrived yet. In React 19 the two everyday sources are a component created with `React.lazy` whose module has not loaded, and a component that reads data that is still pending — a Server Component awaiting its data, or a client component reading a resource that has not settled. From the boundary's point of view the cause does not matter: any suspension inside its subtree puts it into fallback state. ## All-or-nothing within one boundary This is the part candidates get wrong. A boundary does not render the children that are ready and a fallback for the one that is not. It renders `fallback` *instead of the entire subtree*. ```jsx <Suspense fallback={<Skeleton />}> <Header /> {/* ready */} <Feed /> {/* suspended */} <Footer /> {/* ready */} </Suspense> ``` The user sees `<Skeleton />` and none of the three. `Header` and `Footer` appear only when `Feed` is ready too. This is deliberate: React reveals a consistent screen rather than a progressively assembling one, and it is exactly why boundary placement matters — the boundary defines how much of the page waits on the slowest thing inside it. A boundary reacts only to suspensions *inside itself*. A sibling boundary elsewhere in the tree going into fallback has no effect on it. ## The fallback is a normal render `fallback` accepts any React node. `fallback={<Spinner />}`, `fallback="Loading…"` and `fallback={null}` are all legal; `null` means "render nothing here while we wait", which is occasionally what you want for a small, non-blocking widget. Because it is a normal render, the fallback's components genuinely mount when the boundary suspends and unmount when the content is revealed. Two consequences follow. First, any state inside the fallback is thrown away on the swap — never store anything meaningful there. Second, an expensive fallback costs real render time at exactly the moment the app is already waiting, so a fallback should be cheap: a skeleton, a spinner, a placeholder box. ## The swap back When the last suspended thing inside the boundary resolves, React renders the children and removes the fallback in the same commit. There is no intermediate frame where half the children are on screen; the transition from placeholder to content happens in one paint. ## There is no default fallback A suspension travels up the tree until it finds a boundary. If there is none, React has nothing to render in its place, so it raises an error telling you to add a `<Suspense fallback=…>` higher in the tree. React never invents a spinner for you and never silently blanks the app. In practice this means every code path that can suspend must have a boundary somewhere above it — which is why frameworks and shells usually keep at least one boundary near the root as a backstop, even when the interesting boundaries are much deeper. ## What this buys you The payoff is that loading state stops being a per-component `if (loading) return <Spinner/>` branch scattered through your code. The component that needs data just reads it, and an ancestor — often owned by whoever owns the layout — decides what the waiting UI looks like and how much of the screen it covers. Loading UI becomes a property of the layout instead of a property of every leaf component.