From a library audit (see AUDIT.md on branch claude/library-audit-sxpugz, §3.5).
Motivation
event.intercept() accepts scroll: "after-transition" | "manual" and focusReset: "after-transition" | "manual", but the router calls intercept({ handler }) with defaults only (packages/router/src/core/NavigationAPIAdapter.ts). Users can't opt out of automatic scroll/focus behavior or take manual control.
Notably, the FAQ already documents a manual navigatesuccess + scrollIntoView workaround for hash-fragment scrolling — a symptom of these options not being reachable.
Proposal
Router-level defaults plus per-navigation override, e.g.:
<Router routes={routes} interceptOptions={{ scroll: "manual", focusReset: "manual" }} />and/or let the onNavigate callback influence the options for a specific navigation. Exposing event.scroll() timing control (e.g. scroll after data resolves, before/after transition) would let apps implement scroll restoration properly on top.
From a library audit (see
AUDIT.mdon branchclaude/library-audit-sxpugz, §3.5).Motivation
event.intercept()acceptsscroll: "after-transition" | "manual"andfocusReset: "after-transition" | "manual", but the router callsintercept({ handler })with defaults only (packages/router/src/core/NavigationAPIAdapter.ts). Users can't opt out of automatic scroll/focus behavior or take manual control.Notably, the FAQ already documents a manual
navigatesuccess+scrollIntoViewworkaround for hash-fragment scrolling — a symptom of these options not being reachable.Proposal
Router-level defaults plus per-navigation override, e.g.:
and/or let the
onNavigatecallback influence the options for a specific navigation. Exposingevent.scroll()timing control (e.g. scroll after data resolves, before/after transition) would let apps implement scroll restoration properly on top.