In a nested route chain, if one level fails or is still loading, how much of the rendered page does its state replace?

## Scoping is positional Every level in a route chain can declare two extra states beside its normal output: what to show while its own work is unfinished, and what to show when that work fails. Both are **scoped to where the declaring level sits**. Whatever markup the levels above it produced is already on screen and stays there; only the slot belonging to the declaring level is filled with the pending or failure output. The rule that decides how much of the page changes is therefore not 'how bad was the failure' but 'where is the nearest boundary'. ## Walking the chain upward 1. A level's work fails - its data step rejects, or its rendering throws. 2. The framework looks for the **nearest boundary at or above that level**. 3. That boundary's slot is replaced with its failure output. 4. Everything **outside** that slot - the levels above it - keeps its rendered markup and, in most frameworks, keeps working: navigation controls in a shared header still respond, because those components were never torn down. The same walk describes pending states: a level with its own pending state shows it inside its slot while the rest of the page is already visible; a level without one is covered by an ancestor's, which means a larger region of the page is occupied by a placeholder. | Where the boundary sits | What the user sees when a deep level fails | |---|---| | On the failing level itself | Full chrome, with one region replaced | | On a section level above it | That whole section replaced, app chrome intact | | Only at the outermost level | Effectively the whole page replaced by one fallback | | Nowhere | The framework's own last-resort handling takes the page | ## Consequences worth designing for - **Granularity is a choice you make by file placement.** Adding a boundary near a fragile leaf is usually a one-file change that converts a whole-page failure into a contained one. - **One boundary at the top is the common anti-pattern.** It satisfies 'we handle errors' while guaranteeing that any failure anywhere costs the user the entire screen, including navigation away from the problem. - **A boundary cannot catch its own level's failure.** If a level's own data step throws, the state that renders is its ancestor's - because the failing level is the thing being replaced. This is the detail that surprises people: the fallback they wrote on that level covers its children, not itself. - **The outermost level has nothing above it.** A failure it raises cannot be contained by the chain, so whatever the framework does as a last resort is what the user gets. Keep that level's work minimal and defensive for exactly this reason. - **A contained failure leaves a partial page.** The rest of the chain rendered successfully, so the user sees a working app with one broken region. That is usually the goal, but the fallback then has to say enough for the user to know what is missing and what to do. - **Pending states have a symmetrical cost.** A placeholder high in the chain hides a large region of otherwise-ready content; a placeholder per level keeps the page usable but can make it flicker in pieces. ## Choosing where the boundaries go A workable default is one boundary per region a user could still use if the rest broke, plus one on anything known to be flaky: - Give a level its own pending state when its work is slow enough that the rest of the page is worth showing first. - Give the level **above** a fragile data step a failure state, so that step can fail without taking its whole section with it. - Resist wrapping every single level; a placeholder per level turns one loading page into a page that flickers into existence in six pieces. - Keep the outermost level thin, because both its waiting time and its failures are uncontainable by anything else in the chain. Both extremes are real failure modes. One boundary at the top makes every fault total; a boundary on every level makes the user watch the page assemble itself and never see a stable frame. The middle - boundaries on the seams a user would recognise as separate parts of the screen - is what most teams converge on. ## Where the framework-specific details live Meta-frameworks differ in the file or declaration that marks a level as a boundary, in whether a boundary must run on the client, and in what status the response carries when the failure happens during a server render. The positional rule - **nearest boundary at or above the failure wins, everything outside it keeps rendering** - is the part that transfers between them, and it is the part an interviewer is checking you understand.