How does rendering a pending state from each component's own flags differ from one ancestor fallback covering a subtree that declared itself not ready?

## Two ways a tree can say "not yet" A component that depends on a request has to communicate pendingness to whatever will render a placeholder. There are two mechanisms, and they are not variations of one idea. **Local flags.** The component tracks the state of its own request and renders its own branch. Nothing outside it participates. This works in any component framework, because it is ordinary conditional rendering over ordinary state. **A not-ready subtree with an ancestor fallback.** The component, while rendering, signals that it cannot produce output yet. The runtime stops rendering that subtree, throws away the partial work it had already done for it, walks up to the nearest boundary that declares a fallback, and renders the fallback in place of the whole subtree. When the dependency resolves, the runtime retries the subtree and swaps the real content in. This requires a runtime that supports pausing mid-render and retrying; frameworks differ on whether they have it at all. ## What actually differs | Dimension | Local flags | Ancestor fallback over a not-ready subtree | |---|---|---| | Granularity | Per component, as fine as you write it | Per boundary, chosen by where you put them | | Placeholders on screen | One per pending component — often several at once | One for the whole covered region | | Who owns the placeholder | The component that is loading | The ancestor, which may not know what it is covering | | Layout reservation | Each component reserves its own space | One fallback must reserve space for everything under it | | Fast content near slow content | Fast parts render immediately | Everything covered waits for the slowest descendant | | Coordination between regions | Manual, and easy to get wrong | Implicit: one region, one reveal | | Partial render work | Kept; the component rendered its own branch | Discarded for the paused subtree and redone on retry | | Runtime requirement | None beyond conditional rendering | Pause, discard and retry a subtree mid-render | ## The slow-widget question The comparison that interviewers actually reach for: a page is fast except for one widget in the middle of it. - With **local flags**, the page renders, the widget shows its own placeholder, and the user reads everything else. The screen looks busy, and if the widget later grows, the surrounding content moves. - With **one high boundary**, nothing appears until the widget is ready, which converts a fast page into a slow one. - With a **boundary around the widget alone**, the page renders and only the widget's region shows a fallback — the same user-visible result as flags, with the placeholder owned in one place. That is the real lesson: the boundary model does not remove the granularity decision, it relocates it from "which components render a branch" to "where the boundaries sit". Both extremes are bad. One boundary around a whole screen makes the slowest dependency the screen's latency. A boundary around every component reproduces the speckled look of flags, with extra machinery, and makes the reveal order hard to reason about. ## Layout is the sharper cost A per-component placeholder can be shaped like the one thing it replaces, so the swap barely moves the page. One fallback covering a large region has a harder job: it must approximate the footprint of everything beneath it, and it cannot know what that will be. Two common outcomes are a fallback much shorter than the content, so the page grows when the content lands, and a fallback padded to a fixed tall block, so the page shrinks. Neither is fatal, but this is why "wrap the page in one boundary" feels cheap and looks bad. ## What each model gives you afterwards - **Retry.** With flags, the failed component still knows its request parameters, so the retry trigger it renders re-runs exactly one request. With a boundary-style failure, the handler that catches it is an ancestor and typically has no idea what to re-run, so its affordance is coarser. - **Already-visible content.** With flags, you choose to keep the old value while a new request runs. With a boundary, content that was already revealed can be replaced by the fallback again if the subtree becomes not-ready a second time — usually undesirable, and the reason frameworks with this model also provide ways to keep the previous content while the new dependency resolves. - **Testing and reasoning.** A flag is a value you can inspect; a paused subtree is runtime behaviour you observe only through what renders. ## Mixing them Real screens usually mix: boundaries at route and section level to give a coherent first paint, and local flags inside interactive components for refreshes, where replacing content the user is reading would be a regression. The choice is per region, not per application. ## How this shows up in review - A boundary placed so high that one slow dependency delays an otherwise fast screen. - A fallback whose height bears no relation to the content it stands in for. - Both mechanisms active in the same region, producing a placeholder inside a fallback. - A pending branch written per component in a runtime that offers boundaries, with no reason given — or the reverse, boundaries assumed in a runtime that cannot pause a subtree at all.