server component roadmap

[danielroe]

We have experimental support in Nuxt 3 for both island components and server-only components (which are implemented using islands) - see nuxt/framework#5689 and nuxt/framework#9972 for initial implementations and #17956 for initial partial RFC.

There are a number of future linked improvements. This issue is to track those and provide some place to document the linking story, purpose and usage of server components within Nuxt.

Purpose and usage

Currently we are collecting use patterns to ensure that the final API and implementation for server components is useful. But the following are some benefits we are exploring:

1. security and direct access to server APIs within certain components
2. separate caching strategies for individual chunks of HTML
3. leaner bundle size (keeping some dependencies solely on the server, e.g. syntax highlighting)
4. extensibility
5. rendering individual components within other modules or server routes (e.g. for component previews, OG images, PDF downloads, etc.)
6. ...

Comments and suggestions are very welcome.

Roadmap

Beta Give feedback

1. Allow async components - async server components are not rendered in initial HTML #18500
2. Client-side interactivity - support client interactivity within server components #19765
3. remove server component content from payload and prefetch on route transition: perf(nuxt): use prerendered islands to serialise/revive payload #21461
4. Hybrid/remote/streaming sources for server components - hybrid islands (with remote sources) #12343
5. lazy (non-blocking) server components
6. interactive components within server components
7. deep interactive components within server components
8. slot refactor to stabilize the API for other remotes sources such as CMS
9. server pages
10. Looking for server-side Performance optimisation opportunity
11. A deep documentation for islands
12. Apply islands features to non SFC components

[Twitch0125]

I think it'd make sense to have all the available auto imports for server route handlers be available for server components.

[Hebilicious]

This looks promising. Here's my personal 2 cents for "server components".

Disclaimer: I think this name in general is extremely confusing, due to the fact that it's already complicated to understand what's going on. This is not really a problem related to Nuxt, but React has the same problem with RSC, where most people don't really know how they differ from SSR components... Anyways here is some reading to get up to speed ... .

1) More Unified Rendering API

Right now here's a recap of what is possible (correct me if I'm wrong) :

• Nitro route rules : It is possible to decide where and how a page will be rendered. This also allows the handling of more things, like caching rules, redirect, headers ...

  • This works at the page level through a config file
  • This allows patterns like SPA/SSG/SSR/SSR+SWR

• Nuxt Server components : It is possible to tag a component as server only by using .server.vue. This disable hydration and achieve the same thing as SSG.

  • Works at the component level through the file name
  • This allows pattern like "0 javascript" components.

• Nuxt Client components : This is a vue component that can be used to disable SSR at the component level, using a wrapper component.

  • Works at the component level through a wrapper component
  • This allows patterns like "Javascript only" rendering.

As we add more and more features and new things, this becomes hard to understand what takes priority and how everything works. I'm not sure what would be a good way to unify everything. That being said, given that routes and pages are also components, I would personally like to have a good granular API that works for both:

// This could be "aliased" to nuxt="server" and further down to "nuxt-server"
<script setup nuxt="{ render: 'server', hydrate: false }">
console.log("This will be logged on the server only")
</script>
<template>Server Only</template>

// This could be "aliased" to nuxt="client" and further down "nuxt-client"
<script setup nuxt="{ render: 'client' }">
console.log("This will be logged on the client only")
</script>
<template>Client Only</template>

This would be compatible with the "naming" api, ie, renaming a file to .server.vue would effectively do the same as using the nuxt="server" script tag. <ClientOnly /> could be deprecated and replaced by .client.vue.

There could be a configuration file/hook to define custom rendering "templates" so they can be re-used easily (like nuxt="server" => nuxt="{ render:'server', hydrate: false}").

If I'm not mistaken the default for all components and pages should be nuxt="{ render:'server', hydrate: 'true' }" and therefore can be omitted. There should be an easy way to change this default, to enable full SPA or SSG by default.

This is meant to work in tandem with Nitro and these should be "merged" with route rules (the same keys can be used in both route rules and here to unify the API). Some kind of human-readable auto-generated artifact (nuxt-rendered.json ?) should be generated, representing the component tree, so there's a source of truth of what's going on. This can be used by VSCode extensions and the likes for more advanced use case, such as displaying a different file icon for server/client components...

We can detect the "invalid" configurations (ie render: "client" + prerender: "true" or hydrate: "true") and emit a warning.

Alternative API

A few other alternatives API are worth suggesting :

//could be nuxt-render etc
<render>
export { render: 'server', hydrate: false, prerender: true }
</render>
<script setup>console.log("full static")</script>

<script setup>
useNuxtRender(() => ({render: "server", hydrate: "false"}))
console.log("server Only")
</script>

2) "Hybrid Component tree" and Streaming

Currently RSC can support a tree like this (we can achieve something similar with slots)

The entire tree is passed as JSON, and the client side code can reconstruct it with references to the client only components.
So maybe the RFC here needs to be extended to handle all use-cases ?

The streaming part can be a little confusing, we definitely need better naming conventions...
I know that there's some plans regarding streaming, and I wrote this in another issue, and this might be off-topic. Now that Lambda supports streaming, as well as Cloudflare Workers, how does this relate to Server Component streaming is an interesting question. They are different, as the HTML streaming is something related to the way the server sends HTML to the client, while the server component streaming is JSON based api-communication.

What I would assume is that if we have some kind of nested layout like this :

+------+------------------------------------+
| Index                                     |
|      +------+-----------------------------+
|      | SSG                                |
|      |      +------+----------------------+
|      |      | ServerOnly                  |
|      |      +-----------------------------+
|      +------------------------------------+
+------+------------------------------------+

Here Nuxt could use both HTML streaming (using vue pipeToWebWritable instead of renderToString), to send what's already present on the server (static layouts, pre-rendered pages/components), and then execute the the ServerOnly component rendering and pass that to the client using ... a different "stream" ?

Now I don't know if this different stream is what you meant by "Hybrid/remote/streaming sources for server components".

Note that for React, the Root component needs to be a "server component", and that server components supports children (ie slots) that can be either client or server components.

3) Nuxt Islands and relation to @vue/core

I'm not very familiar with that part of the code

The current implementation looks a little like this right now : the current server components use createStaticVNode/createStaticVNode and raw html from an internal nitro endpoint to render server components on the client.
The Nitro endpoint use renderToString, then respond with an object that contains the serialised html and the state (payload). That payload is then "revived" on the client side.

Perhaps this revive logic should be handled by Vue and not by Nuxt. I'm not sure what the benefits would be or if that's something that isn't priority, but it's worth mentioning here. Maybe the vue renderer should have this functionality and should be able to "revive" the state, but also event listeners, lifecycle hooks and everything else that is needed.

[HendrikJan]

I'm probably a bit lat at this party, but I've got an alternative to .server components that has slightly different but mostly the same benefits: #20802

[cosbgn]

I agree with @HendrikJan - His solution would be ideal for my use case. My main issue with component.server.vue is that I would still need multiple files, I would need a billing.vue page and a billing.server components, which doesn't change much from having a billing.js endpoint, I would still have 2 files to manage my billing.

Ideally I want one billing.vue page where I have all my billing logic, frontend and backed.
I have so many file-x.vue for frontend and file-x.js for backend - I would really love to unify them in one single file.

[Hebilicious]

I agree with @HendrikJan - His solution would be ideal for my use case. My main issue with component.server.vue is that I would still need multiple files, I would need a billing.vue page and a billing.server components, which doesn't change much from having a billing.js endpoint, I would still have 2 files to manage my billing.

Ideally I want one billing.vue page where I have all my billing logic, frontend and backed. I have so many file-x.vue for frontend and file-x.js for backend - I would really love to unify them in one single file.

What you are both discussing is another feature that is quite different from server components.
A SFC block or something like this can be implemented without too much effort (I think):

//page/todos.vue
<server>
export default defineEventHandler(() => {
	return [{id: 1, description: "hello-world"}]
})
</server>
<script setup>
const { data } = useFetch("/api/todos")
console.log(data) // [{id: 1, description: "hello-world"}]
</script>

What would happen is that the server block content would be added as route handler in /api/todos.ts.
I've been thinking about doing something like this with a nuxt module... If enough people are interested I might just move forward with it.

Edit : This is now available as a module https://github.com/Hebilicious/server-block-nuxt

[cosbgn]

I've been thinking about doing something like this with a nuxt module... If enough people are interested I might just move forward with it.

As a module it would be amazing and I think the implementation is great (using fetch) and keeping it as a backend function

[urbgimtam]

I've been trying out Nuxt Server Components and really enjoyed the experience!

But I have a few questions that I consider interesting:

• If there was a way for Nuxt to automatically detect if a component can be upgraded into a server component (ie: doesn't have interactivity, etc), wouldn't it be interesting to apply this detection and conversion all over the Nuxt app? What would be its pros and cons?

• The usage of Server Components can improve interaction responsiveness due to less hydration and less js to be downloaded to the client. But at the extreme, wouldn't the server CPU become taxed, building all the HTML to ship to the client? Would a caching system for Server Components bring benefits, and how could that work?

[jd-solanki]

If there was a way for Nuxt to automatically detect if a component can be upgraded into a server component (ie: doesn't have interactivity, etc), wouldn't it be interesting to apply this detection and conversion all over the Nuxt app? What would be its pros and cons?

I really liked this, In addition to this, I also like to ask will it be possible to identify if the component is rendered on server or on the client because when my react/nextjs colleagues ask my help on server component first time I wonder about is "how do you identify if that component loaded on sever or client". The point is, for beginner to server side components it might be the nightmare.

[MuhammadKhizar7]

• The usage of Server Components can improve interaction responsiveness due to less hydration and less js to be downloaded to the client. But at the extreme, wouldn't the server CPU become taxed, building all the HTML to ship to the client? Would a caching system for Server Components bring benefits, and how could that work?

I also discussed the same thing before in a discussion #16469. I think server components and caching go hand in hand (just like React does). Otherwise, what would be the difference between Nuxt and PHP or ASP.NET Razor pages (they also have page caching)? With server components and on edge (Vercel, Cloudflare Worker), there is a cost and time delay (like 10 API calls) every time this page renders, just like in server-side PHP, etc.

I am proposing component caching along with the current page-level caching. Some components change often, while others do not. Why not cache these components instead of the page? Or, if they never change, make them static?

[clemvnt]

Hey guys,

With the future evolution of interactive components within server components, will there be a "mode" where all pages are server components by default?

[Rigo-m]

From a team-oriented standpoint, is it feasible to add an option to the nuxt.config so that by default every component is a server component and client hydration is opt-in?
This would help with streamlining development so that the approach for the whole team is to work in a client-performance, small client bundle environment and thoroughly think through the addition of client side javascript.
I don't know if I conveyed my thoughts correctly on this one.
Let me know.

[madebyfabian]

Hi there! I just discovered something currently not implemented that could be interesting:

When using throw createError({ statusCode: 404 }) in a server component, I expect nuxt to transfer the error to the client and display an error page. Just like it's advised to do so in regular components at https://nuxt.com/docs/getting-started/error-handling#example-1.

When I try to do that with a server component, the follow happens:

1. The HTTP Request to this component (/__nuxt_island/...) returns a clean http 404. That's kind of good.
2. But then I get a log from vue-router, complaining the route doesn't exist:

   [Vue Router warn]: No match found for location with path "/__nuxt_island/MyComponent_KtzRNsoXNj"

3. And the rendered page on the client doesn't show any signs of an error. Just a blank page.

Is there a way to catch these so that I get the error.vue template displayed, and nuxt catching that error?

[Youhan]

Would there be a way to serve a server component using nuxt and then consume it using vanilla JS on other apps?

[fabianwohlfart]

Encountered a little caveat that I was not aware of, not sure if it's mentioned somewhere:
A component islands always needs a root element.

[fabianwohlfart]

Is there a way to not run into 431 header issues when using server components, for example for long texts passed as props to a markdown component, despite changing the server settings max-http-header-size?