Allow loaders to be used to prefetch data for routes

[axwalker]

Since all the data required for a route is nicely contained inside a route's loader, it'd be great to be able to use this to prefetch/preload data for a route. This is especially useful when you can infer that a user is likely to navigate to a new route, for example on hover.

This idea is essentially the same as SvelteKit's preloadData. They also have data-sveltekit-preload-data that is an additional option on their <RouterLink> equivalent but this is just a bonus. The underlying preloadData functionality is the interesting bit.

One quick way to enable this would be to allow a route to be passed to useLoader instead of internally retrieving the current route. This would allow you to import useLoader from wherever it's exported and just call it with the route you expect the user navigate to. For example, one might end up with:

<script setup lang="ts">
import { useExampleLoader } from '@pages/foo'
</script>

<template>
  <RouterLink 
    :to="{ name: 'foo', params: { id: 'h4sh' } }"
    @mouseover="useExampleLoader({ name: 'foo', params: { id: 'h4sh' } })"
  >
    Go to Foo
  </RouterLink>
</template>

You could improve the ergonomics of this in various ways up to the equivalent what SvelteKit's versions provide afterwards at some point.

This all would likely only be useful for any loader implementation that has some kind of caching mechanism baked in, like pinia-colada or vue-query, otherwise you'd just end up double fetching the data once you actually navigate to the route.

[posva]

Yes! This is definitely planned and as you noted, by containing the logic within the loader, it can be preloaded 😁
The API is still not created but I think it's a possible contribution. It should be a combination of resolving a location and calling the inner load attached to the composable. I think there are a couple of adjustments to make though

[axwalker]

I can have a go at contributing if you'd like?

Do you think the general idea would be something like:

export function preloadData(route) {
  const loaders = collectLoaders(route)
  return executeLoaders(loaders, route)
}

Where collectLoaders is essentially the beforeEach guard and executeLoaders is essentially the beforeResolve guard?

Enabling this would involve the following steps:

1. Extract the required core logic of those beforeEach and beforeResolve guards into exported reusable functions
2. Update the UseDataLoader() interface to accept an optional route as an argument
3. Update the various loader implementations to derive the route either from the new optional route argument if passed, otherwise from getCurrentContext() (eg in places like here)
4. Export a preloadData function somewhere pulling this all together for users to import and use

I'm assuming you'd want to explicitly pass the given route in for (3) rather than just setting the current context as that could have other unintended consequences?

There are probably various other gotchas/considerations to consider, but does this sound roughly like the right idea?

[posva]

Of course, feel free to give this a try. It's not the easiest of the contributions but I'm very happy to have someone give it a try

About 2, the useDataLoader() shouldn't change. Instead, using the internal _ property should be enough:

unplugin-vue-router/src/data-loaders/createDataLoader.ts

Line 196 in 464e5d5

load: (

. Therefore, for 3, it should be fine to use the context.

Everything else sounds perfect!

[axwalker]

I'll have a poke around to start getting a better idea of how everything works. I have a couple of questions so far:

1. "using the internal _ property should be enough": by this do you mean that because the route gets passed in to _.load like here nothing internally in the loaders need to change? Or were you thinking about something else?
2. How might this interact with the PENDING_LOCATION_KEY stuff? Unlike actual navigation, we wouldn't want preloading to abort any other loading in progress. Would not setting PENDING_LOCATION_KEY when preloading be enough or is it also required to have the loaders actually work correctly?

If you're doing your Twitch stream on Monday I might pop in and ask some questions there if that's ok!

[posva]

1. Yes
2. I think that preloading shouldn’t interfere with a pending navigation. It’s also fine to first support it only where there is no ongoing navigation. The pending location is used in some place to time when data is set and when to discard results

I will probably go over it during the stream yeah 🙂

[ljcremer]

Is there any update on this feature?

[sanscheese]

I'd say this is the best place to keep an eye on: #435