A local failure must not make the whole page unusable
Aliases: isolate module failure · don't kill the page · partial load error
What it is
A page often has several independent loads: main column, rail, comments, recommendations, hero. When one channel fails, only that piece should enter failure presentation. The rest, already successful or still operable, stays usable. Catching one rail 500 with a whole-page error screen, a whole-page spinner or a whole-page empty state widens failure from a channel to a task. The article people came to read is there; they cannot scroll, copy, or use the primary button because the recommendation endpoint hung.
Why it happens
Failure scope crawls upward along the cheapest error handling: one uncaught rejection becomes a route-level error boundary, and the whole tree unmounts. Clean for implementation, dirty for the task. Tasks usually depend on one piece (the body); the rest is enhancement. A dead enhancement channel should not revoke the part whose dependency is already met. Isolation draws the error boundary at the module edge: the main column has its own failure, the rail has its own, they do not hold each other’s stock.
The cost of not isolating is usable area collapsing. People read “the whole page went red” as “this job cannot be done”, even when logs show body 200. They leave, refresh the page, or resubmit the part that already succeeded. Wrong scope is harder than wrong copy, because even accurate copy cannot help once the controls are gone.
Where it stops holding
When the main column itself fails and the task does not exist without it, a whole-page failure is honest scope, not widening. Shared auth death (session expired) makes every block meaningless at once; it should rise to the page, not draw expiry in every module. Blocks that are structurally stuck to each other (main column height cannot be computed without the rail) may truly be unable to lay out the main column when the rail fails — that is structure binding scope; decouple the layout rather than treating whole-page failure as reasonable. If the shell on the critical path (nav, identity) fails, remaining content has nowhere to go and whole-page failure can stand; comment failure cannot.
Applying it
- Put error boundaries on modules: one failed request replaces that piece, it does not unmount the route.
- Keep successful chunks interactive: select, copy, primary action, scroll — not disabled because a neighbour failed.
- Split shell (nav, identity) from enhancement (recommendations, comments). Only shell or main-task failure rises to the page.
- How to check: 500 the recommendation endpoint, leave the body healthy. If the whole page becomes an error screen or the primary button vanishes, scope has widened. Correct is body readable and operable, recommendation slot failed on its own with a nearby retry.