Vue Router Data Loaders

[posva]

• Start Date: 2022-07-14
• Target Major Version: Vue 3, Vue Router 4
• Reference Issues:
• Implementation PR: https://uvr.esm.is/data-loaders/

Basic example

<script lang="ts">
import { getUserById } from '../api'

// name the loader however you want **and export it**
export const useUserData = defineLoader(async (route) => {
  const user = await getUserById(route.params.id as string)
  // ...
  // return anything you want to expose
  return user
})

// Optional: define other component options
export default defineComponent({
  name: 'custom-name',
  inheritAttrs: false,
})
</script>

<script lang="ts" setup>
// find the user as `data` and some other properties
const { data: user, isLoading, error, reload } = useUserData()
// data is always present, isLoading changes when going from '/users/2' to '/users/3'
</script>

📖 See the full rendered proposal at https://uvr.esm.is/data-loaders/

[kiaking]

Great proposal! Love it!

---

I would like to know in SSR, how to define "Do wait for loader on initial load (SSR) but do it lazy on client navigation (SPA)".

The idea is on the initial load (initial page visit), I want it to do SSR. But, if the user visits the page via client side navigation (home page -> users page), then I want it to be lazy.

This is a bit confusing on Nuxt as well. So for example, can we have option like "lazy on client"?

export const useUserData = defineLoader(
  async (route) => {
    const user = await getUserById(route.params.id)
    return user
  },
  // This means `lazy: false` on SSR, but `lazy: true` on client navigation.
  { lazy: 'client' }
)

---

Naming
Rename defineLoader() to defineDataFetching() (or others)

I would day go with Loader. It's simple. And technically, it't about loading data. If we use the word "fetch", it kinda feels like it has to perform http request. But that's not requirement right? We could have async but local data loading so I think loader sounds perfect 👍

So I think setupDataFetchingGuard in "setup" section should also be named setupLoadingGuard or setupLoaderGuard?

[posva]

but we don't have isClient, do we? It changes depending on what is being used for SSR. For example, in Nuxt, you could use process.client

[kiaking]

Ah, good point. Yeah. But still that's going to be enough then 👍

lazy: process.client

[posva]

ah right, I forgot we can just use the variable right away. Same for Vite (https://vitejs.dev/guide/env-and-mode.html#env-variables). It's worth adding though

[posva]

If anybody have use cases where the function syntax would be useful, please share them

[posva]

Regarding lazy and SSR, I think the default for lazy should be to apply only on client by default like it does in Nuxt. On the server, it should always wait. Unless there is a reason to be lazy only on server but I cannot think of any 🤔

edit: there is now a server boolean flag to control this and lazy loaders are still awaiting on server

[jods4]

"Motivation" section doesn't discuss the alternative where pages are simply async components and you have a <suspense> in your main layout. That's what we use in our app and it works well enough, although we had to plug a few holes in what router exposes in a simple fashion (which ties to my 2nd point below):

    <router-view v-slot="{ Component, route }">
      <app-loading v-if="navigating" />
      <!-- rootLoaded and route.matched[0] shenanigans so that the component is not removed when navigating child routes -->
      <suspense v-if="rootLoaded" :key="route.matched[0]?.path ?? route.path">
        <component :is="Component" v-anim="{ enter: 'zoomIn', leave: 'zoomOut' }" />
        <template #fallback>
          <app-loading />
        </template>
      </suspense>
    </router-view>

Data loading is a tricky problem that is central to almost all applications, so I applaud the initiative to design a solution for Vue projects.
Yet I feel like this is too much, too complex, and too opinionated to be that deeply ingrained inside the router.

With so many parts, it's likely that some users will want different conventions, have their own way of loading data, or maybe don't want/need any of this at all. Recently we've seen efforts to innovate in the data loading space and I think it's too early to close down the topic into an official built-in data loader design. Also there's a lot to be debated in this design and it wouldn't be surprising that it takes several iterations to nail it down.

I think it'd be good to identify (and add) the extensibility points that the core router needs so that such solutions can easily be built in a separate package; then create an official vue-router-data out of this RFC.

[posva]

Thanks for the feedback!

"Motivation" section doesn't discuss the alternative where pages are simply async components and you have a

That's true, it's in drawbacks and alternatives but it should only be in alternatives and a bit longer than that

Yet I feel like this is too much, too complex, and too opinionated to be that deeply ingrained inside the router.

I see what you mean by too opinionated and I think it has to be opinionated to be easy to use and it's okay if it's opinionated as long as it's extensible and not enforced (which would be limited).

I would like to know what makes this too much and too complex?

With so many parts, it's likely that some users will want different conventions, have their own way of loading data, or maybe don't want/need any of this at all.

I think I didn't mention it in the RFC, and I should, but this whole loader API is tree shakable and is currently (partially) implemented in unplugin-vue-router. The biggest part is there.

Recently we've seen efforts to innovate in the data loading space and I think it's too early to close down the topic into an official built-in data loader design. Also there's a lot to be debated in this design and it wouldn't be surprising that it takes several iterations to nail it down.

I agree and that's why I'm opening this RFC 😄. The web is ever evolving anyway so I don't think it will ever be one single official data loader design that works forever. Instead, I think this could last a few years, like other official APIs.

I think it'd be good to identify (and add) the extensibility points that the core router needs so that such solutions can easily be built in a separate package; then create an official vue-router-data out of this RFC.

Good news is the Router already has all the needed API

---

A note about Suspense: it's briefly mentioned in the RFC but I will add a bit longer section about why not Suspense for data loading. Here is the TLDR:

• No parallel data fetching, only sequential/cascading
• No way to refresh data when navigating to the same route apart than using a key attribute which remounts the whole view tree and is expensive
• Requires mounting the component to handle entering guards and thus higher memory consumption as two views are being mounted in parallel
• Does not allow granular loading state control. This could ofc be added through new APIs and I think they will have to be added eventually (cf the issue you opened in vuejs/core about missing APIs in Suspense)
• No cache: always refetch

The good part is you can still use Suspense for data fetching or you can even use both APIs at the same time.

[jods4]

I would like to know what makes this too much and too complex?

This RFC composes several aspects that are complex enough on their own and could be sub-components.
For example:

The proposed Dataloader concept encapsulate stuff like:

• Non re-entrant loading (2 calls at the same time only load data once);
• Loading indication (ref) for lazy loads, abortable;
• Caching;
• Composable (dataloader wrapping other dataloaders).

That's already a lot and sounds usable on its own, for example to load data when opening a modal dialog, inside a datagrid component, etc.
It could be packaged into a vue-dataloader as a generic data-access component, and reused as a strategy amongst others by vue-router-data.

Caching itself is a famous can of worms:

• I'd like to cache some stuff long term (localStorage)?
• I'd like to share my cache amongst open tabs (sessionStorage)? That implies a way to invalidate across tabs (sendMessage)?
• I should be able to easily invalidate cache entries when receiving a notification from server?
• The design of refresh being returned by a specific dataLoader is not great in terms of coupling, when a totally unrelated components wants to invalidate stuff. Usually we really on cache key concepts for that.
• Some apps may not want to cache their page and always display fresh data.

vue-dataloader could take a cache interface to abstract all these things away, and maybe offer an optional basic implementation for short-term caching such as the one described in this RFC.

I think I didn't mention it in the RFC, and I should, but this whole loader API is tree shakable
[...] Good news is the Router already has all the needed API

I'd suggest publish things in separate packages then, at least for now.
When this stabilizes into a good design that proves to be very popular, it can always be merged into the router later.

Good news is the Router already has all the needed API

The Motivation section starts by implying that all current ways of loading data have issues.
Yet this is based on existing API so there seem to be a gap in the explanations.

I think that gap is that the API are there but they're not super-convenient to plug into to compose a loading solution. The Motivation section describe solutions based on navigation guards (which this is, right?) as "complex to setup" and "non-ergonomic".

Maybe we should give some thought about how to design some higher-level apis that are easy to consume for such tasks, without necessarily prescribing everything else about the loading. Some kind of applications are totally fine with their data access basically boiling down to fetch and don't need the extra bells and whistles of DataLoader (caching, single-call, etc.). It'd be nice if they could easily plug that into the router like this RFC proposes.

BTW you mention isNavigationFetching and this is something I've asked for before (rather a plain isNavigating at router level) as it's super convenient to display loading indicators. I've done it with guards but it becomes tricky if you work with nested (child) routes, as you may want to display an indicator at a different level in the UI. Ideally there's should be a global isNavigating and also individual isNavigating in each router-view slot.

A note about Suspense:

No parallel data fetching, only sequential/cascading

I assume you're thinking of routes with multiple (named) components? As a single component is free to send multiple requests at the same time and await all of them later.

Maybe that's a part where we could think about router API enhancement. Isn't this a limitation solely because the router loads such components sequentially? Then it would faster for everyone if the router itself loaded components in parallel?

No way to refresh data when navigating to the same route apart than using a key attribute which remounts the whole view tree and is expensive

Do you mean other than handling onBeforeRouteUpdate hook? Which is quite annoying for such a basic requirement, indeed. This is also a part where maybe a more streamlined api could be designed, regardless of actual data loading strategy?

As I mentioned, we use suspense + async components to fetch data; and we solved this issue with the key attribute.
It has an added benefit that you have not mentioned in this RFC: animations.
We have transitions when going from one page to the next, and typically we see going from /product/1 to /product/2 as a full page navigation with transition. So in this case using key and mounting a new tree is kind of required anyway.
I assume that in the context of this RFC animation would be solved by the app template using a key as well in router-view?

Requires mounting the component to handle entering guards and thus higher memory consumption as two views are being mounted in parallel

Agreed, and this points strongly towards the ergonomics of guards, esp. with script setup.

No cache: always refetch

That is untrue. It solely depends on what your data access layer is. It could totally include a cache.
In fact, your data layer inside a suspense design could be based on the DataLoaders you propose here, couldn't it?
That's why I think we should separate the concerns a little bit more: there's "plugging into the router lifecycle" and there's "fetching data strategy".

Going wild

The reflections above on guards usability + this line in the RFC (Alternatives) made me think:

Adding a new <script loader> similar to <script setup>

It'd be pretty sweet if we had some kind of <script before-route-enter> and we could just write async data loading code in there and have the result passed to our component (from useRoute() or similar I suppose).

It's gonna make the SFC compiler and Volar more complicated I guess, and I am not sure what the exact specification of <script XYZ> would be.

[posva]

Caching itself is a famous can of worms:

Yes, but that's explained in the RFC as non-goals. The other points you mention makes me think I should just name it something different than "Cache".

I'd suggest publish things in separate packages then, at least for now.

That's exactly what I did 🙂. I still think getting feedback on this right now is very valuable.

Maybe we should give some thought about how to design some higher-level apis that are easy to consume for such tasks, without necessarily prescribing everything else about the loading.

Sure, I wouldn't mind seeing other proposals 👀. At the end, they all come down to hooking into navigation guards to add what they need.

Some kind of applications are totally fine with their data access basically boiling down to fetch and don't need the extra bells and whistles of DataLoader (caching, single-call, etc.). It'd be nice if they could easily plug that into the router like this RFC proposes.

I agree but I'm also proposing this API for other reasons like making it easier to get data fetching right in simpler cases as well as complicated ones.

I assume you're thinking of routes with multiple (named) components? As a single component is free to send multiple requests at the same time and await all of them later.

No, it's about nested routes and nested suspense creating cascade fetching that cannot be avoided. Named Views shouldn't see that limitation when using Suspense

Maybe that's a part where we could think about router API enhancement. Isn't this a limitation solely because the router loads such components sequentially?

Unfortunately, no and I wish it was different 😅. This is just how Suspense works when nesting components: the mounting requires the async setup to be resolved and that's when other async setup come in.

Then it would faster for everyone if the router itself loaded components in parallel?

Yes, but this is not technically possible because of the reason above.

Do you mean other than handling onBeforeRouteUpdate hook? Which is quite annoying for such a basic requirement, indeed.

I also mean data refreshing, e.g. when the route itself doesn't change and therefore onBeforeRouteUpdate() cannot trigger. For example the home of Twitter shows the latests tweets and that data fetching is not tied to the path. Depending on the user interaction you might want to refresh the data without navigating.

This is also a part where maybe a more streamlined api could be designed, regardless of actual data loading strategy?

This is precisely what I'm trying to do 😅. The main challenge is that we cannot force a new navigation as there is no navigation, it happens in a different layer of the application.

I assume that in the context of this RFC animation would be solved by the app template using a key as well in router-view?

Yes, as you mentioned it's a Vue requirement anyway.

That is untrue. It solely depends on what your data access layer is. It could totally include a cache.

You are right, I was only talking about barebones Suspense.

In fact, your data layer inside a suspense design could be based on the DataLoaders you propose here, couldn't it?

I don't understand this part. You can use the loaders within suspended components if that is relevant to your question.

That's why I think we should separate the concerns a little bit more: there's "plugging into the router lifecycle" and there's "fetching data strategy".

Agreed! I'm still experimenting with some extensibility designs and I also think it would be much more beneficial if the API can be kept simple and extensible while still allowing to expose tree shakable "strategies" with good sensible defaults: setupLoaderGuardWithCache() using setupLoaderGuard() (no cache) internally

It'd be pretty sweet if we had some kind of <script before-route-enter> and we could just write async data loading code in there and have the result passed to our component (from useRoute() or similar I suppose).

Yes, that is actually one of the ideas I built on this RFC, replacing the callback passed to next() in beforeRouteEnter()

IMO a custom script is worth investigating but it should come once there is a version that can be used without a new script.

It's gonna make the SFC compiler and Volar more complicated

Just in case you are curious about it: Yes, it does but it's doable today:

• SFC: add a vite/webpack/rollup plugin to transform the code (although it would be even better if the SFC compiler allow to hook into the compiler process itself, I think there was already an issue in vuejs/core)
• Volar: add a vueCompilerPlugin to tsconfig.json but what about other editors?

[posva]

I added as much as I could at e5ce9cc, let me know if this doesn't make things about suspense clearer. I haven't added anything about the cache layer yet because I still need to experiment with it

[jods4]

DataLoaders must be exported from page components

The RFC is very insistent on this (which sounds a bit weird) but is a bit unclear/contradictory at places.

From Setup section I understand this is not actually a hard requirement of the router, as long as we put the right stuff in the route meta.

If I'm correct, it's a requirement for unplugin-vue-router to find it and put it automatically in meta.

But then later in section Usage outside of page components the RFC is again very strict about this requirement without mentionning unplugin-vue-router.

[posva]

The RFC is very insistent on this (which sounds a bit weird) but is a bit unclear/contradictory at places.

It's probably my wording.

If I'm correct, it's a requirement for unplugin-vue-router to find it and put it automatically in meta.

No, it's needed by the data loading navigation guard (setupLoaderGuard(router)). Exports are scanned and detected that way.

But then later in section Usage outside of page components the RFC is again very strict about this requirement without mentionning unplugin-vue-router.

I need to update the wording so requirements are clearer

[jods4]

Ok, thanks for the clarification.

My feedback would then be that I'm uneasy with the idea of using module exports as significant, esp. in an environment where bundling and tree shaking is the norm.

I'd find it more "natural" if the DataLoaders a component needs were found in the route (meta or otherwise), or maybe the component definition itself.

[posva]

They are added as dynamic imports so they get loaded with the navigation itself. It’s as if they were part of the component. You are of course still free to move these to a different file when using the same data loader in multiple components.

[jods4]

So... I assume that this happens at runtime (as opposed to build time)?
I'm confused by the meta: { [LoaderSymbol] } in Setup that made me think this was a build-time thing by unplugin-vue-router.
Please disregard the rest of this comment if I'm wrong.

I am making bundles that group several pages together by area, I assume this wouldn't work with the proposed dataloaders as the dynamically imported modules don't match 1:1 with pages?

export const routes = [
  { path: "/area-1/page-1", component: () => import("/area-1.js").then(x => x.Page1) },
  { path: "/area-1/page-2", component: () => import("/area-1.js").then(x => x.Page2) },
]

I guess this approach is also ruling out statically imported pages?

import Dashboard from "/dashboard.vue" 

export const routes = [
  { path: "/dashboard", component: Dashboard }
]

Is there a reason to go with the former rather than the later, which DX-wise is pretty similar and a little less "magic"?

<script>
  // Why this?
  export const random_name = defineLoader()

  // Instead of this?
  export default {
    loader: defineLoader()
  }
</script>

<script setup>
  // Component definition...
</script>

[posva]

edit: this meta property is no longer needed, loaders are automatically picked up in lazy loaded routes. In non lazy loaded routes, add meta.loaders[]: https://uvr.esm.is/rfcs/data-loaders/#basic-example

They are both: build+runtime

- build: add the meta: { [LoaderSymbol]: [() => import('pages/viewA.vue'), () => import('pages/viewB.vue')] }
- runtime: get the imports, load them, execute loaders

You can add any dynamic import to the array. For convenience, the array could contain plain functions as well. It doesn't have to be 1:1 per page.

old code not valid anymore

import { useUserData } from '@/loaders'

// ...
// Currently you have to
[LoaderSymbol]: [() => Promise.resolve(useUserData)]
// could be changed to allow
[LoaderSymbol]: [useUserData]

> Is there a reason to go with the former rather than the later, which DX-wise is pretty similar and a little less "magic"?

Yes, the latter is longer, less flexible (cannot be imported by others), doesn’t allow using the returned composable in script setup, and includes the loader with the component like other properties while it doesn't have access to this. It would however in part remove the need of the LoaderSymbol (not 100% sure). I think it could be automatically added by the unplugin if the loader is being exported, it's worth seeing the perf impact this has in build time though as creating the meta field is lighter than transforming the code

[dflock]

This seems like a great plan - I'm excited to try it out as soon as I can make time! My current use case for this is trying to make my components more functional and testable - i.e. don't fetch the data inside the component, do it in the router and pass it in as a prop. I'm also currently using vite-plugin-pages and should probably move to posva/unplugin-vue-router anyway, so win-win!

This rfc seems very quiet, although posva/unplugin-vue-router seems to be moving along. Can I assume that this is still moving forward?

[posva]

Late reply but yes, this is still moving forward with a lot of changes very soon

[Hebilicious]

I'm overall a fan of this pattern, great job on this RFC.

My biggest wish for this, is that it should improve the existing solutions and there should be a path for users/libraries authors to integrate these changes to make data-fetching better in all applications. As you mentioned, I also feel like the most important will be Nuxt, Vue-query and Apollo.

For Nuxt, there's might be room for simplification : here's a list of all the data fetching composable that are currently available :

• useAsyncData
• useLazyAsyncData
• useFetch
• useLazyFetch
• useNuxtData
• refreshNuxtData
• clearNuxtData

All of these are somehow connected to Suspense and use $fetch so that in SSR the internal requests become functions calls.
There's also the pre-render usecase to consider, where you want to fetch some routes at build time to pre-render them with data (ie payload extraction), which is still WIP in Nuxt nuxt/nuxt#13949 nuxt/nuxt#14507

It would be great if Nuxt and this RFC would line-up to integrate and simplify all of this.

Regarding 3rd party libraries, the one that I'm the most familiar with is vue-query, and I'm not sure how it would work. As a user, I would definitely want to leverage all useQuery features (which are out of scope for this RFC).

Something like this :

<script lang="ts">
import { getUserById } from '../api'

export const useUserData = defineLoader(
  async (route) => {
    const user = await getUserById(route.params.id)
    return user
  },
  { lazy: true }
)
</script>

<script setup>
useQuery({ queryKey: ['todos', todoId], queryFn: () => useUserData(todoId) })
</script>

But this wouldn't work, as there's a need for a way to "connect" both, so that the fetching is triggered by the navigation and as well as useQuery (for example for the background fetching.

Note that vue-query can be used with SSR/Nuxt and Supense.

It would be great if there was a straightforward path for library authors/maintainers to integrate with these new capabilities, instead of having them compete against each other.

Edit : I just saw your notes here and it looks great.

Lastly, you mentioned that data loaders and suspense are not mutually exclusive and that they can be used together, could you provide an example of how to do so ?

Is it recommended, what would be the benefits, etc.

[posva]

I still have to revisit this RFC to add the final touches for 3rd party integrations but what I had in mind is closer to:

// useUserData exposes the same API as other loaders
const useUserData = defineVueQueryLoader(...)

My goal is to keep data fetching separate from Suspense because it currently creates a lot of issues (see vuejs/core issues with label suspense 😓 ) and in the end it is just simpler for vue core and the end user to not have to handle all the edge cases that can happen while navigating.

[Hebilicious]

Great! I just saw this in your notes:

export const useTodos = defineQueryLoader(fetchTodoList, { key: 'todos' })

export const useContact = defineQueryLoader(
  async (to) => {
    const contact = await fetchContact(to.params.id)
  },
  {
    key: (to) => ['contact', to.params.id],
  }
)

This is a little more complicated than the traditional version, but a library/plugin should be able to convert a regular useQuery function to a useQuery + defineLoader automatically.

Something else I would want is some DX improvements for script setup.

For example let's assume I have a need for a list of todos on both /planning and /todos.
I want to be able to call useTodos in both planning.vue and todos.vue.
With script setup, you have to export { useTodos } from '~/loaders/todos.ts' in a separated script tag in both files.

Maybe we should have a way to pass a route array to defineLoader (or route names, components names...) so that we don't need to export it ?

Or maybe we can have a macro that automatically inject export { useTodos } from '~/loaders/todos.ts' if it seesuseTodos, or add the routes to the route array of defineLoader

[posva]

Or maybe we can have a macro that automatically inject export { useTodos } from '~/loaders/todos.ts' if it seesuseTodos, or add the routes to the route array of defineLoader

This would be an interesting idea to explore with auto imports 👀

[posva]

To give an update: I'm revisiting a lot of this and have a version that is working without the cache features. The goal is to also have a lower level API oriented to lib maintainers to create their own loaders. There are a few things that are outdated in the RFC like the inability to use inject() within loaders: it's now possible since Vue 3.3. And the resolved value of the promise returned by the loaders being just data now (to avoid confusion of where to use them)

[leopiccionia]

I see how requiring LoaderSymbol is more flexible in theory, but not in practice.

Why not just checking if a given export name (or component definition key, for non-lazy components) exist on the loaded components? When is it not a good idea?

As far as I know, it's how other frameworks implement getServerSideProps, etc. Is it too high level for Vue Router? If yes, couldn't we just configure it at router-level?

Couldn't we just look for something like this?

const useApi = defineLoader({ … })
export const loaders = [useApi]

Or using a compiler macro (we could use a less confusing pair of names):

const useApi = defineLoader({ … })
defineLoaders([useApi])

[posva]

The LoaderSymbol part isn't necessary in the new implementation. I just need to update a bunch of things in this RFC 😄

The new API allows adding a loaders array to routes when defining them while still automatically checking for loaders if the components are lazy loaded and the loaders are exported

[Indeedornot]

Looks awesome!
I'm checking it out as I write it and trying to implement it in a testing environment.
However I'd like to inquire what is the state of navigation and redirects as of right now since as it stands it does not seem to be fully implemented

[posva]

I missed this comment, sorry! It's currently implemented in the new version that I'm still reworking: posva/unplugin-vue-router#246. I'm also rewriting most of this RFC to match the new version

[louiss0]

I don't understand why is it up to the developer to create keys. Unique string id's can be created cheaply.

[posva]

How? They must be deterministic to match on sever and client and has to be light too (no extra dep)

[louiss0]

If I'm correct the loaders are all set up ahead of time before the app is executed. If that's the case the key could be created during that time. I'm sure they are registered in a specific order so either a serialised random number could do or a timestamp could be enough.

I'd be happier with this annoyance if keys could be used to debug loaders. But since this is not the case.

This is enough.

(Math.random() + 1).toString(36).substring(7)

Feel free to remove the 7 or the 36

[posva]

Unfortunately I don’t think the order of execution is 100% deterministic.
They could be generated at build time base on the file name and line. Similar to Nuxt

[louiss0]

I think is a good idea to pass in navigation result as a second param.

//  import { NavigationResult } from 'vue-router'

export const useUserData = defineLoader(
  async ({ params, path ,query, hash }, createNavigationResult) => {
    try {
      const user = await getUserById(params.id)

      return user
    } catch (error) {
      if (error.status === 404) {
        return createNavigationResult({ name: 'not-found', params: { pathMatch:  } }
        )
      } else {
        throw error // aborts the vue router navigation
      }
    }
  }
)

[posva]

I find this less intuitive than importing. It’s harder to discover and locks the argument order for the future. For example, I was planning on adding a signal to the parameters of the function

[louiss0]

I understand. I figured since we would use that class often it would remove the boilerplate.

[posva]

I rewrote the RFC and published it as docs at https://uvr.esm.is/rfcs/data-loaders/. The list of changes is not short and can be found at https://github.com/posva/unplugin-vue-router/blob/main/CHANGELOG.md#breaking-changes. I think I addressed many of the points people made (again, thanks a lot for the feedback 🙏 ) and if I forgot anything or if you have new ideas, please let me know!

[jacekkarczmarczyk]

This url shows 404

[posva]

There are now docs: https://uvr.esm.is/data-loaders/

the rfc is still there for a more technical explanation but I think having a usable library helps more with feedback

[jacekkarczmarczyk]

the rfc is still there

But the url for the rfc has changed, might be a good idea to update links in the initial comment (either provide the new link to rfc or to the docs)

[rijenkii]

A macro definePageLoader()/defineLoader() could be error-prone as it's very tempting to use reactive state declared within the component's <script setup> but that's not possible as the loader must be created outside of its setup() function

To be honest the extra <script> is the only thing that is turning me away from this proposal. Vanilla Vue provides macros that accept local variables from <script setup>, hoists them and actively screams at the user if they did something egregiously wrong, so data loader macros could do the same:

<script setup lang="ts">
import { ref } from "vue";

const inheritProps = ref(true);
defineOptions({ inheritProps });
</script>

[vite:vue] [@vue/compiler-sfc] `defineOptions()` in <script setup> cannot reference locally declared variables because it will be hoisted outside of the setup() function. If your component options require initialization in the module scope, use a separate normal <script> to export the options instead.

/project/workspace/src/App.vue
3  |  
4  |  const inheritProps = ref(true);
5  |  defineOptions({ inheritProps });
   |                  ^^^^^^^^^^^^
6  |  </script>
7  |