How do you decide how many layout levels a deeply nested route hierarchy needs and what each level owns?

## What a level actually buys A nesting level is not free structure; it is a commitment every future contributor reads. It is worth adding when it buys at least one of three things: 1. **Persistence.** Chrome, state, a scroll container or a subscription that must survive every navigation below it. This is the strongest reason, because it cannot be had any other way. 2. **Region ownership.** A failure or pending display declared at a level replaces that level's outlet region. Choosing the level therefore chooses the **blast radius** of a failure: how much of the screen the user loses, and how much remains usable. 3. **Scope.** One place to express an access check or a data load that applies to everything beneath, instead of repeating it per screen. If a proposed level buys none of those, it is a pass-through: a component whose entire job is to render an outlet. ## Three tests before adding one 1. **The retention test.** Name one thing at this depth that must still be there after the user navigates below it. No answer means no level. 2. **The blast-radius test.** If something at this depth fails or is not ready, what should the user still be able to use? If the answer differs from the level above, this depth needs its own region. 3. **The scope test.** Is there a rule — an entitlement check, a load, a context value — that applies to everything below and nothing beside? If yes, the level gives it a single home. ## Levels and segments are independent decisions The most common structural mistake is to mirror the URL: one segment, one level, automatically. They answer different questions. | you want | use | effect on the URL | |---|---|---| | screens to share an address prefix | a parent route with a path fragment | adds a segment | | screens to share chrome or state, addresses unchanged | a pathless level | none | | a segment with nothing to persist at that depth | a deeper path fragment on one entry, no extra level | adds a segment | | a section's base address to show something | an index child | none | Published addresses are a long-lived contract; the component tree is refactorable. Letting the URL dictate the tree freezes the cheap decision to the expensive one. ## Over-nesting and under-nesting | | under-nested | over-nested | |---|---|---| | chrome | duplicated in several screens | spread thin across levels that barely render | | state | rebuilt on navigation, so it resets | technically preserved, but nobody can find its owner | | failures | one failure blanks the whole screen | tiny isolated regions, and a fragmented screen while several are pending | | reading the code | one file shows everything, with repetition | "what renders here?" takes a walk down several near-empty levels | | work placement | repeated per screen | placed at a level that is kept, so it quietly never re-runs | The last row of the over-nested column is the failure mode teams underestimate. A level that persists is a tempting place for a load, and precisely because it persists, that load runs once and the numbers on screen drift. Every level you add is a place where that mistake becomes available. ## Leading the decision - **Name the owner of each region in writing.** A short table — level, chrome it renders, state it holds, region its failure replaces — prevents the slow drift where two levels both half-own the header. - **Make the review rule explicit**: a new level must state which of the three things it buys. This is far cheaper than removing a level later. - **Budget for movement.** Moving a level changes what resets for every descendant, and that change is invisible in a diff. If a level might move, do not let much state accumulate there yet. - **Watch for chrome that becomes conditional on the child.** When a level starts asking "which child is showing?" to decide what to render, the chrome is in the wrong place — either push that part down into the children, or split the level. - **Prefer the shallowest tree that gives each persistent thing exactly one home.** Depth is easy to add later when a real need appears, and hard to remove once state, checks and loads have settled into it. ## A worked judgment A product with a top shell, a workspace switcher, a section rail and per-record tabs *looks* like four levels. Interrogate each: the top shell persists and owns the whole-app failure region, so it stays. The workspace level holds membership and entitlement data that everything below reads, so it stays. The section rail renders chrome that all its children show and keeps its own scroll, so it stays. The per-record tabs level is worth a level only if something must persist across tab changes for one record — a loaded record, a draft, a scroll position. If each tab loads independently and shares nothing, the tabs are markup in the record screen, not a level. Four candidates, three or four levels, and the difference is decided by evidence rather than by the shape of the URL.