How do you decide how many error boundaries a React app needs and where they go, given that a single boundary at the root already prevents every blank page?

## The question behind the question "How many boundaries?" is really "what is this page's primary job, and what may fail without stopping it?" Boundaries are a declaration of acceptable degradation, and only a product-aware answer is possible. An interviewer asking this is checking whether you reason about user outcomes rather than reciting an API. ## Why root-only is not enough One boundary at the root does prevent the blank page — it replaces the entire app with a fallback. From the user's perspective that is barely distinguishable from the crash: the checkout they were completing is gone, along with the form state, scroll position and open dialogs. Root-only also destroys diagnostic resolution: every failure looks like "the app broke", with the component stack as the only clue about where. So the root boundary is the last resort, not the strategy. ## The layers that usually earn a boundary **Root.** Catches everything nothing else did. Its fallback must be dependency-free — no data access, no context it might not have — because a fallback that throws escalates to an unmounted tree. **Route or page.** A boundary per route means a broken page does not poison the app shell, navigation still works, and moving elsewhere clears the failure. Keying this boundary on the route makes recovery automatic. **Independently valuable regions.** A dashboard is the canonical case: five panels, each fed by a different service. A boundary per panel converts "the dashboard is down" into "one panel says it is unavailable". The test is whether the region's failure should remove the page's primary task. **Untrusted or volatile subtrees.** Third-party embeds, user-authored content renderers, experimental features behind flags, anything rendering data whose shape you do not control. These fail in ways your own code does not, and containing them is high value for one wrapper. ## Where a boundary is actively harmful A boundary destroys the state below it. Wrapping a region that contains the user's in-progress work means an unrelated crash inside that region takes their typing with it. Concretely: do not put a single boundary around "the whole editor" if a sidebar widget inside it can crash — give the widget its own boundary so the editor survives. Similarly, a boundary around something whose failure makes the rest of the page meaningless buys nothing. If the order summary cannot render, a "summary unavailable" box beside a live "Pay" button is worse than a page-level failure. Degrade at a level where the remaining UI is still coherent and safe to act on. ## Boundaries versus modelled failure states Most failures should never reach a boundary at all. An expected empty result, a validation rejection, a request timeout — those are states the component should render deliberately, with retry affordances and no state loss. Boundaries are for the unexpected: a bug, an invariant violation, data the component genuinely cannot render. A team-level heuristic worth stating: if you find yourself adding a boundary to make a *known* failure look acceptable, you have found a missing state in the component's design, not a missing boundary. ## Observability is the non-negotiable half A boundary makes failure invisible to the user, which means it makes failure invisible to *you* unless you wire reporting. Two levers in React 19: - `componentDidCatch(error, errorInfo)` per boundary, adding local context — which feature, which entity, which flow; - `createRoot(container, { onCaughtError, onUncaughtError })`, giving one app-wide reporting site with the component stack, including for boundaries you forgot to instrument. Then decide the operational policy: contained errors are not free. Track their rate per boundary, alert when one climbs, and treat a chronically failing panel as an incident even though nobody saw a blank page. The failure mode of a well-boundaried app is that it degrades quietly for weeks. ## Fallback quality as a design decision If every boundary renders the same generic "Something went wrong", users learn to reload the whole page whenever anything goes wrong — which throws away the containment you just built. Fallbacks should say what is unavailable, what still works, and what the user can do: retry, continue without it, or reload. That is a design and copy decision, not a React one, and it belongs in the same review as the placement. ## Interaction with Suspense boundaries Error and Suspense boundaries answer different questions — "this failed" versus "this is not ready yet" — and their placement usually converges, since a region that can load independently is normally a region that can fail independently. Pairing them per region gives a coherent story: a skeleton while loading, a scoped error message when it fails, and the rest of the page untouched in both cases. ## Summary answer Root as the last resort, route level so navigation recovers, region level wherever independent degradation is meaningful, and never around the user's in-progress work. Pair each with reporting and an alerting threshold, and write fallbacks that describe the loss rather than repeating one generic apology.