using Server Loaders as a general way to provide data for SSR

[jangxyz]

Reading "Form actions for progressive enhancement" issue on nuxt/#20649, I understand the purpose of form actions. I'm still bit confused with server loaders though.

Coming from SvelteKit, I understand that both form actions and data loading on the server side are two critical channels of data communication between the client and the server.
In fact, I was a bit surprised to find out that nuxt did not have anything like it by default, and the closest thing was using server/api/. Guess how happy I was when I discovered this module 😂

However, although form actions does meet the expectations of what I have thought of, server loaders still lacks some features. Since the nuxt issue above only discusses about form actions, I thought this would be a good place to ask about server loaders.

In sveltekit, the purpose of Loading data is to provide data required for page component to render on the server, which is accomplished without any additional fetch requests. From the components perspective, you receive the data as a prop, and no need to perform a fetch request.

From the PESPA article you've introduced (great article, by the way!)

PESPA Document Request

... Routing and Data fetching is solely done on server side.

This does not seem to be the case for Server Loaders, in which:

• though it does render on the server, during hydration useLoader() performs additional fetch request via /_nitro/loader/.
  plus, Vue warns about Hydration text mismatch. Scary 😨

• the loader does not provide route matching, so defining a server loader in server/actions/books/[bookId].ts does not capture useLoader('books/123'). It only works when I call a literal useLoader('books/[bookId]'). Form actions are able to pass additional parameters via form data, but we don't have additional channels to pass params for server loaders.

  In SvelteKit using data loaders is the default way of passing data for SSR, and I was expecting something similar:

  // /pages/books/[bookId].vue
  <script setup>
    const route = useRoute()
    const { data } = await useLoader(route.params)
    // or maybe omit the argument at all?
    //const { data } = await useLoader()
  </script>

Thinking about these limitations, it seems like the current implementation is a wrapper around /server/api/, and by defining a server loader 1) it provides an api internally, and 2) requests the api on render.
Though if this is the case, it is strange that while /server/api/books/[bookId] works, /server/actions/books/[bookId] does not.

Is this the limit of the current architecture of nuxt -- which I do not know deeply of -- and is the best so far a module can get? Or maybe there is no limits on the architecture, and the implementations are coming, and I just need to wait a bit longer?
My most fearful scenario would be that this is by design, and the server loader is not the same as sveltekit data loaders (which is hard to imagine, reading through the discussion in nuxt/#20649). If that is the case, I would have to go back and 'build an api endpoint' for every page components (sigh).

[Hebilicious]

Thank you for your feedback @jangxyz it is very helpful !
I haven't used SvelteKit a lot, so I'm not very familiar with how loaders works.

Modules are actually super powerful and even Nuxt itself use modules in its core, so we shouldn't hit any hard limitations for a while.
We are free to design the API/feature however we see fit.

You are right, the implementations use regular nitro handlers and useFetch, but that can be changed as well.

• For the hydration mismatch this is probably a bug, do you have a repro ? With useFetch the data fetched on SSR is passed in the payload to the client (so you should see it in the nuxt devtools in Payload/Data)
• Parameters support is a good candidate, how about useLoader("books", { params: {id: "abc} } ) ?
• Omitting the argument can be done in the future, for now TS relies on it.

[Hebilicious]

Just implemented the route parameters in #30 with some examples, let me know if that works for you

[jangxyz]

• For the hydration mismatch this is probably a bug, do you have a repro ? With useFetch the data fetched on SSR is passed in the payload to the client (so you should see it in the nuxt devtools in Payload/Data)

Here's a minimal reproduction on stackblitz: https://stackblitz.com/edit/nuxt-starter-trga3p?file=components%2FBooks.vue
Again, same minimal code from README using ServerLoader, tested on nuxt v3.6.5 + form-actions-nuxt 0.2.0-beta.1.

Screenshot

You can see the Hydration text mismatch warning on the console.

Some interesting points:

• console.log inside the component is run more than once on the server (see lower left, console from terminal). Here you see it three times, but on my actual project I consistently see it twice.
• console.log on the client does not return result value -- see console on Chrome dev tools: result.value: null. I think this is where vue figures out there is a mismatch. One thing interesting is if you check the network request, you DO get a response with data in it. It seems like the data gets lost during returning it to the component.
  Despite the node mismatch you can still see the rendered screen in the screenshot, but on the actual project the client fails to render the data. (Maybe its because on stackblitz the client also renders the component twice, but not the actual project.)

I'm also checking on the route params update as well. Stay tuned for feedbacks! :)

[Hebilicious]

Thanks, there is actually a couple of bugs that don't happen in the playground, but happens with the deployed version. Let's track in #31

[Hebilicious]

I also want to mention that @posva is working on vuejs/rfcs#460 , which could be a better underlying implementation than using a regular nitro handler.

[jangxyz]

Seems like a grand plan :) I'll try to follow along as time permits. Thanks.

[Hebilicious]

Is there anything else you have in mind that we could improve for now ? Any missing feature or weird behaviour, or something that you can do in Svelte Kit but can't do with server loaders ?

[jangxyz]

I'm still trying to get used to Vue and nuxt, so I beg your apology for being a bit late on the response :)

While I am keep investigating, here are some thoughts on it so far:

• My idea is that loader names should match the url pathname. So a form submission without any particular action= could figure out which action to look for. In this sense, it is also plausible that you can omit the argument in useLoader, since the user expects it to be useRoute().path automatically.
  Currently it binds with the filename of the corresponding action, instead of the matched route. From it, I get the feeling that the current implementation regards the action more like a representative title of group of actions. The actions on the examples are not more than one directory deep... and I think I've seen some mismatches when I tried to work on deeper directories -- need to do some more digging here to confirm.
  Though I understand if action names become useLoader('todos/3') instead of useLoader('todos/[id]', { params: { id: 3 } }), it would be a bit harder for typescript to catch up?

• Perhaps the thought of making 'one loader per one page' seems to align more with the Server Block module. However on earlier attempts I encountered the same "no params supported" problem with the server blocks module as well. Do you have any updates on it?

• I'm a bit lost inside the "enhanced" mode, and is preparing a separate submitForm issue for it.

• I'm also puzzled about the action option in the run handler. I know that it binds with the <form action="login"> attribute, but I was also expecting it to respond to <button formaction="login?register"> attributes as well. If this is possible I could do different behaviors depending on the action.

I'll try more experiments, and come up with more questions & ideas until I understand better.

[Hebilicious]

• For loader and pathNames, initially I had something like this, but that caused issues and that wasn't working properly with Typescript ... So I changed to explicit naming. You are right, it binds with the filename. Multiple nesting levels should work, but I actually haven't tested them. Getting rid of the arguments could be done with some kind of vite transform where we infer todos/[id]', { params: { id: 3 } } from the route path and inject it for the user, but I want everything to work flawlessly before we tackle this.

• There shouldn't be any difference if you are using the right versions, as the server-block module doesn't implement useLoader. If you have a repro that would be helpful.

• This is poorly documented but the zod-vorms playground should be helpful.

const { enhance } = await useFormAction({
  run: async ({ cancel, submitForm }) => {
    cancel() // Cancel the default form submission
    const result = await validateForm() // Validate with the library
    if (Object.keys(result).length === 0) await submitForm() // Submit the form if valid ...
  }
})

If this is working with action but not with formaction this might be a bug.