You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pendingComponent replaces the mounted UI on every same-route navigation since 1.170.19 (match-loading rewrite #7805) #7986
Since @tanstack/[email protected] / @tanstack/[email protected]
(the match-loading rewrite in #7805), a navigation that only changes search
params or a path param on an already-mounted route swaps the page to the
route's pendingComponent while a parent layout's async beforeLoad re-runs.
On 1.170.18 the mounted UI stayed on screen during such navigations; the
pending component only appeared when there was nothing rendered yet (initial
load). With defaultPendingMs: 0 (pending immediately on cold start) and defaultPendingMinMs: 250, our app now flashes a full-page spinner for at
least 250 ms on every in-app tab switch and every sibling-route switch,
because the layout's auth-guard beforeLoad does a network round trip.
Shape that reproduces it: a pathless layout route with an async beforeLoad,
a child route /projects/$projectId with validateSearch, router options defaultPendingMs: 0, defaultPendingMinMs: 250.
Click "switch tab" (search-only) or "switch project" (param-only)
The whole page flashes PENDING (full-page spinner) on every click on
1.170.19; on 1.170.18 the content stays mounted
Expected behavior
As a user, I expected an in-app navigation on an already-mounted route to keep
the current UI while beforeLoad/loaders re-run (the 1.170.18 behavior), but
on 1.170.19 the mounted page is replaced by the pendingComponent on every
such navigation.
Screenshots or Videos
No response
Platform
Router Version: 1.170.19 (regression from 1.170.18; router-core 1.171.16 vs 1.171.15)
OS: macOS
Browser: Firefox (also reproduced in jsdom)
Bundler: vite
Bundler Version: 7.x
Additional context
1.170.20 / router-core 1.171.17 only bump dependencies, so the behavior is
unchanged there. react-router pins router-core exactly, so pinning
1.170.18 is the workaround we ship today.
Activity