When the user navigates between two sibling child routes under the same parent, what does the router keep mounted?

## Two matches, one shared prefix A navigation inside a nested app is a diff, not a rebuild. The router resolves the new URL into a matched chain, lines it up against the chain that is currently rendered, and walks down comparing level by level: 1. While the entries agree, the existing components at those levels are **kept** and re-rendered with whatever changed (the new matched child below them, new parameter values). 2. At the first level where the entries differ, the currently rendered branch from there down is **unmounted** and the new branch is **mounted** into that level's outlet. 3. Everything above the divergence point never learns that it could have been rebuilt; from its point of view, one input changed. Moving between two siblings under the same parent is the simplest case of this: the divergence point is the child level, so exactly one outlet's contents change. ## What "kept" means concretely At a kept level, the instance is the same object the framework created when that level first mounted. Therefore: - **local state survives** — a collapsed navigation panel stays collapsed, a filter box keeps its text, a tab keeps its selection; - **element references survive**, so a scroll container keeps its offset instead of snapping to the top; - **work started at mount survives** — a subscription, a timer, an observer, and any one-time data load. Mount-time work does **not** run again; - **derived and memoised values survive** unless the values they depend on changed; - **cleanup does not run**, because nothing was destroyed. At the divergence point the opposite happens: the outgoing branch's cleanups run, its instances and their state are gone, and the incoming branch starts from scratch. ## Re-render is not remount This is the distinction the question is really testing. | | re-render | remount | |---|---|---| | triggered by | new inputs, new parameters, a new child in the outlet | the level's route entry changing, or an explicit identity change | | instance | the same one | a new one | | local state | preserved | discarded | | mount-time work | not repeated | repeated | | cleanup | not run | run for the old instance | A parent whose outlet content changed will typically re-render, and a candidate who says "nothing happens to the parent at all" is overstating it. The correct claim is narrower: the parent is not rebuilt. ## The parameter-change trap The interesting edge is a parent whose own segment is dynamic — a record shell wrapping several tabs for that record. Moving from one record to another keeps the **same route entry** at that level, so most routers keep the instance mounted and simply hand it a new parameter value. Consequences: - work the shell did when it mounted — including the load for the previous record — does **not** re-run on its own; - state left over from the previous record is still there, so a stale name, a stale count or a half-edited draft can bleed across records; - the fix is to make the shell **react to the parameter** rather than assume mount equals fresh: re-run the load when the identifying value changes, and reset the state that is tied to it. Some routers also let you request a fresh instance for that level deliberately, which is the blunt version of the same fix and costs you the retained scroll and chrome state. ## Frameworks differ in *how*, not in *whether* The retention rule is a router-level decision, but what happens inside a kept level depends on the reactivity model. A runtime that re-runs a component's function re-executes it with the new values while preserving the state it holds; a fine-grained runtime does not re-run the component body at all and only updates the specific reactive reads that changed; a compile-time runtime updates the generated instructions for the changed values; a dirty-checking runtime re-evaluates the level's bindings. None of them create a new instance merely because a value changed — creating instances is what mounting does. ## Verifying the behaviour rather than assuming it When you need certainty on a given app, instrument it instead of arguing: - record a counter or log line at each level's creation, navigate between siblings, and see which levels report a new creation; - put a visible piece of throwaway state in the shared level (a typed character) and check whether it survives; - watch whether the shared level's data request fires again — if it does, something above it is being rebuilt. The answer that instrumentation gives you is also the answer to the design question: whatever must survive belongs at a level both URLs share, and whatever must reset belongs below the divergence point.