When would a router render two matched branches into separate named outlets at once, and what does that cost?

## One URL, more than one matched branch The common case is a single outlet per level: one path, one chain, one screen. A router that supports **named outlets** relaxes that. A level declares several outlets, each identified by a name, and the table says which branch fills which name. Matching then produces not one chain but a set of them, all rendered at the same time inside the same level. That matters when two regions of a screen are genuinely independent and both deserve to be addressable: - a **list beside a detail**, where choosing an item changes only the detail region; - a **persistent secondary panel** — activity, help, a conversation — that stays while the main region navigates; - an **overlay above the screen it covers**, where the underlying region keeps its match instead of being replaced; - a **comparison layout** where two branches of the same shape are shown side by side. ## What the table and the URL have to supply The hard requirement is **reconstructibility**. If a region's branch cannot be derived from the address, then a link, a reload or a restored session shows something different from what in-app navigation produced. That desync is the defect this mechanism is most often blamed for, and it is a design mistake rather than a router bug. Practical options: 1. Both regions derive from the **same segments** — the detail region reads the identifier the main path already carries. 2. One region gets its **own part of the address**, so its state travels with the link. 3. A region is declared **deliberately transient**, with a defined default on a cold load. That is a legitimate choice as long as it is the documented behaviour and not an accident. ## What each outlet needs of its own - An **empty state**, for when its branch matches nothing. A region with no match must render something intentional, not a gap in the layout. - Its **own failure region**, so a failing panel does not take the main region with it. - Its **own pending region**, so one region waiting does not blank the whole screen. - A clear **ownership rule for shared data**, because two regions showing the same entity is exactly where people reach for hidden mutable state to keep them in step. ## What it costs | cost | why it appears | |---|---| | harder reasoning | the screen is a *set* of matches, so "what renders here" cannot be answered by reading one path | | link fidelity | every region must be reproducible from the address, or shared links and reloads diverge from in-app state | | history semantics | you must decide which region changes deserve their own step back, and say so consistently | | combinatorial testing | region states multiply instead of adding | | responsive layout | a multi-region shape has to collapse into one region on a narrow viewport, and something must decide which one wins | | focus and reading order | two live regions need a defined order and a defined place for focus to land after a region-only change | ## When it earns its keep, and when it does not It earns its keep when the regions are **independently meaningful**: each has content worth linking to, each has its own loading and failure story, and users move within one without disturbing the other. A mail client, an admin console with a persistent inspector, or a two-pane browse-and-read surface all fit. It does not earn its keep for ephemeral interface state. A confirmation dialog, a transient menu, a tooltip and a wizard step that nobody would ever link to are cheaper and clearer as component state. Routing them buys addressability you do not need and charges you the whole list above. The honest test is: **would you paste this region's state into a chat message?** If not, it is not routing's problem. ## A middle path Before reaching for named outlets, check whether one branch with a parameter does the job. A list-and-detail screen often works as a single chain where the list level renders both the list and its outlet, and the detail is an ordinary child. That gives you one path to reason about, retention of the list level for free, and a natural empty state through an index child. Named outlets are worth their cost when the regions are **not** in an ancestor relationship like that — when neither region is naturally the parent of the other, or when one must survive while the other is replaced wholesale.