Run loaders on navigation

[pleek91]

Description

Sixth step of #805, stacked on #812. This is the one that makes loaders do something.

const user = createRoute({ name: 'user', path: '/user/[id]' })
  .addView(UserView, { props: (route) => ({ id: route.params.id }) })
  .addLoader(async (route) => api.getUser(route.params.id))

// in a component
const route = useRoute()
const user = await route.data

To the store, a props getter and a loader are the same thing: a named callback belonging to one match. Both are set into the navigation's store together, and only what waits on them differs — props are awaited as what a view renders with, loaders are awaited only so a push or a rejection from one is still acted on. That is what makes loaders non-blocking: nothing on the render path reads them.

The kind is part of the key, so a view and a loader sharing a name on one route stay two values.

Who has data

Data is attached to a route as it becomes current, not as it is resolved — a route is resolved before the navigation that computes its data owns a store, so reading it any earlier subscribes to the store that navigation is about to replace.

Surface	Data
RouterRoute — useRoute(), router.route	yes
a props getter's route	yes
a loader's route	no
ResolvedRoute — router.resolve, router.find, hook to/from	no

A props getter has it because one loader feeding several views is the reason data exists:

.addLoader(async (route) => api.getUser(route.params.id), { name: 'user' })
.addView(UserHeader, { props: async (route) => ({ user: await route.data.user }) })
.addView(UserSidebar, { props: async (route) => ({ user: await route.data.user }) })

A loader does not. A route's data includes what its own loaders are computing, so a loader reading it could only wait on itself, or on a sibling waiting back. Its route is a plain ResolvedRoute, and reading data anyway throws LoaderDataAccessError rather than hanging.

Both reach other routes through parent.props and parent.data, which point only upward:

.addLoader(async (route, { parent }) => api.getPosts(await parent.data))

So the dependency graph is acyclic by construction: loaders read upward, props read upward and their own route, nothing reads downward.

Since the store is no longer only about props, createPropStore is now createRouteValueStore (and usePropStore follows). "Value" is the word the store already used internally — getValue, ValueLocation, and #806's own title — and it stays distinct from route.data, which means loader data specifically. Nothing renamed here is exported from the package.

Worth a look

• createRouterRoute snapshots the resolved route in a spread, so anything that changes per navigation has to be passed as a ref. data now is. title has the same problem and is left alone here.
• The warning for stalling while prefetching now covers loader data and route data, not just parent props, so its wording is no longer parent-specific — one existing assertion moved with it. Happy to carry the relationship into the message instead, so the parent case keeps its original advice.
• reactive()'s unwrap types cannot see through a generic route's data (it is a promise), so createRouterRoute asserts its return shape instead of inferring it.
• The route a callback receives is a proxy over the resolved route rather than a copy, so the data it replaces is only read when something asks for it.

Prefetching loaders is the next PR: the loaders prefetch setting does not exist yet, so a loader only runs on navigation.