On a client-side navigation between two URLs in the same nested route chain, which segments' server fetches re-run?

## What a client-side navigation actually does On a full document request the browser throws the current page away. On a **client-side navigation** it does not: the router intercepts the intent, matches the new URL, decides what data it is missing, asks the server for exactly that, and re-renders the parts of the tree that changed. The URL in the address bar is updated through the History API rather than by loading a document. That gives the router a comparison it did not have on first load: *the old match versus the new match*, segment by segment. ## The segment-by-segment comparison Consider a chain of three matched segments — an outer section, a collection, and a detail view — and a navigation from one detail URL to a sibling detail URL. | Segment | Match before | Match after | Typical treatment | |---|---|---|---| | Outer section | identical | identical | data reused, not refetched | | Collection | identical | identical | data reused, not refetched | | Detail | one identifier | a different identifier | data function re-runs | The rule of thumb is that a segment whose matched parameters are unchanged is a candidate for reuse, and a segment whose parameters changed must be refetched because its data is a function of those parameters. This is why the outer chrome of an application does not flash or refetch when you move between items inside it. There are qualifications worth stating out loud: - **Reuse is an optimisation, not a law.** Some frameworks re-invoke every matched segment's data function on every navigation, favouring freshness over round trips. Some reuse by default and offer an explicit way to force a re-run. Some let each route declare the condition under which it should re-run. - **An unchanged parent can still need fresh data.** If a write in the detail view changed something the collection displays, reuse shows a stale count. Invalidating those copies is a separate mechanism with its own rules; what belongs here is knowing that reuse is why the stale value survived. - **A full reload is the reset.** Anything reused in memory is gone; every matched segment fetches again from scratch. ## What comes back over the wire The same server-side code runs, but the response is different in kind. On a document request the output is HTML. On a client navigation it is a **serialised data payload** — the data (or the rendered description of the changed subtree, depending on the framework) for the segments that changed, in a format the already-running client can apply to the existing page. Practical consequences: 1. The payload is typically far smaller than a document, because unchanged layouts are not resent. 2. The data still has to be serialisable, exactly as on first render — same constraint, same reason. 3. The route's server code is still the only place the fetch runs; the browser did not gain direct access to the data source. 4. Because no new document is delivered, a normal HTTP status line is not how failures present themselves to the user — the payload has to carry the failure so the client can render the right state. ## Why this matters in practice The reuse boundary is the single biggest lever on how a navigation *feels*. If every segment refetches, moving between two rows in a list costs the whole route's data phase every time. If only the leaf refetches, it costs one read. Two failure modes follow directly: - **Too much reuse** shows stale outer data after a write, and the fix belongs to invalidation, not to the fetch. - **Too little reuse** makes every navigation as expensive as a cold load, and the fix is to check what the framework considers "changed" — a parent whose data function reads something request-specific may be treated as changed on every navigation. ## How to answer it well Say the comparison out loud: match the new URL, diff it against the old one per segment, re-run the changed segments' data functions on the server, reuse the rest, and apply a serialised payload to the live page. Then add the honest caveat that the reuse policy varies between frameworks and can usually be overridden per route — that caveat is what distinguishes someone who has read a single product's documentation from someone who understands the mechanism.