From a library audit (see AUDIT.md on branch claude/library-audit-sxpugz, §3.6).
Motivation
After a mutation performed outside the action flow (WebSocket update, a fetch in an event handler, cache invalidation), there's no way to re-run the current entry's loaders. hardReload() throws away the whole document; navigating away and back pollutes history.
Proposal
const { revalidate, isRevalidating } = useRevalidator();
await revalidate();The machinery mostly exists: the reload-count mechanism (#reloadCounts in NavigationAPIAdapter) already generates fresh cache keys so loaders re-execute on navigationType: "reload". Revalidation is essentially "bump the reload count for the current entry, invalidate the snapshot, notify subscribers inside a transition" — without an actual browser reload. Alternatively navigation.reload() interception already flows through this path; a thin wrapper that calls navigation.reload({ info }) and lets the existing intercept handle it may be enough, if the resulting UX (pending UI via the transition) is acceptable.
From a library audit (see
AUDIT.mdon branchclaude/library-audit-sxpugz, §3.6).Motivation
After a mutation performed outside the action flow (WebSocket update, a fetch in an event handler, cache invalidation), there's no way to re-run the current entry's loaders.
hardReload()throws away the whole document; navigating away and back pollutes history.Proposal
The machinery mostly exists: the reload-count mechanism (
#reloadCountsinNavigationAPIAdapter) already generates fresh cache keys so loaders re-execute onnavigationType: "reload". Revalidation is essentially "bump the reload count for the current entry, invalidate the snapshot, notify subscribers inside a transition" — without an actual browser reload. Alternativelynavigation.reload()interception already flows through this path; a thin wrapper that callsnavigation.reload({ info })and lets the existing intercept handle it may be enough, if the resulting UX (pending UI via the transition) is acceptable.