On-demand server component rendering

[jmikrut]

Goals

1. Based on a client-side trigger, be able to render a given server component and all of its children
2. This needs to work recursively, and thus can't be based on filesystem routing
3. These on-demand RSCs need to be rendered anywhere in the React component tree, so that their client components can access parent context from where they were rendered accordingly

Non-Goals

1. May not have any overlap with Parallel Routes due to the non-recursive nature of parallel routes

Background

Lots of highly dynamic admin UIs feature drawers / modals that can be opened in a "nested" or recursive fashion up to an unknown level, based on runtime data which is not statically predictable.

Here is a simple example of Payload showing a recursive relationship field. This is a VERY simple / unlikely example, but will help illustrate the issue. Payload has lots of drawers / modals that need to render on-demand, based on client interactions. These modals can be recursive in nature. They contain server components that need to be rendered on the server (fields, views, etc).

recursive-modals.mp4

The Contentful admin panel does something similar, where you can "drill in" to relationship fields up to any level deep.

Right now, Payload renders all custom server components at the top level, so that they are ready to be used in client-side drawer interactions, but this is not ideal, because this means that RSCs cannot receive context-specific props. Consider a custom field component that is an RSC. We want to pass its value into the component as a prop, so the developer can use that value in their component. But, we can't pass the value, given that the RSC could be used in any number of drawers, each corresponding to a different document (thus a different value).

Parallel Routes may seem like a potential solution to this, but due to their file-based routing, recursion to an unknown level is impossible.

If we could have some type of mechanism where we could dynamically request specific RSCs from the frontend, and then render them, this would solve for our use case.

Proposal

Not sure how this could be implemented. We would love to brainstorm this idea with the Next.js team.

One idea that comes to mind is some way to be able to import server components within client components, in a safe manner, such that they are available to render on-demand, but are not added to the client-side bundle. Maybe some directive could be created similar to use client, which would allow the import of server components in client components.

Alternatively, if we could pass un-rendered server components as props to client components, that would also solve the issue.

Really though, we're open to any implementation mechanism!

Thank you for reading!

[jmikrut]

Update - we've found that we can return RSCs on-demand from server actions, which might solve for this whole thing!

[jonathanhefner]

I agree this would be an amazing feature to have! The way I think about it is that server components are currently excellent for fetching data that corresponds to a page URL, but there are many times when client-side interactivity requires fetching data independent of the page URL. Some examples:

• Populating suggestions in an autocomplete / typeahead widget.

• Populating dynamic options for a select box based on another input. For example, populating a list of cities or states based on a selected country.

• Clicking through a calendar widget to select an existing appointment from arbitrarily far in the past or future.

• "Navigating" within a modal wherein the modal's state is ephemeral. For example, a file picker like MacOS's Finder.

• Filtering, sorting, and paginating a data table widget.

Being able to import a server component into a child component (not just pass a server component to a child component) would enable these uses cases without have to do a cumbersome client-side fetch + API dance.

we've found that we can return RSCs on-demand from server actions, which might solve for this whole thing!

Unfortunately, server actions "are not recommended for data fetching". They use POST requests, are typically executed sequentially instead of in parallel, and their responses may not be cached.

In order to support importing a server component into a child component, there are some open questions that I think need to be answered. For example:

• How to handle a client component passing children to a server component? (It wouldn't be practical to serialize the children and send them to server along with the other props. Which means there needs to be some type of proxy object for the server component to reference when doing something like conditionally rendering children.)

• How do async server components fit into non-async client components? Does React automatically wrap them in use?

• "On-demand" server components are much more expensive to re-render than client components. How are re-renders avoided / controlled?

I would love to see more discussion about this. Like I said, I think it would be an incredible feature and would significantly boost the usage of server components.

[jonathanhefner]

I took a shot at a userland implementation of this functionality, which I termed "remote components". You can see it in action at https://next-remote-components-v1.vercel.app/.

It supports static typing, client components as children, suspense boundaries, and refs to elements.

To use remote components in your own project, copy lib/rrc-server and lib/rrc-client into your project, and then follow these steps:

1. Create a server component:

   // components/MyServerComponent.tsx
   
   export default async function MyServerComponent() {
     return <span>Hello from the server!</span>
   }

2. Create a remote component set that includes the server component:

   // components/my-remote-components.ts
   
   import MyServerComponent from "./MyServerComponent"
   
   export default {
     MyServerComponent,
   }

   (This step would likely be eliminated if React itself implements remote components.)

3. Create a single API endpoint that serves any remote component in the set:

   // app/api/remote-component/route.ts
   
   import myRemoteComponents from "@/components/my-remote-components"
   import { serveRemoteComponents } from "@/lib/rrc-server"
   
   export const GET = serveRemoteComponents(myRemoteComponents)

   (This step would likely be eliminated if React itself implements remote components.)

4. Create a client component that uses the remote component from the set:

   // components/MyClientComponent.tsx
   
   'use client'
   
   import type myRemoteComponents from "@/components/my-remote-components"
   import { useRemoteComponents } from "@/lib/rrc-client"
   
   const { MyServerComponent } = useRemoteComponents<typeof myRemoteComponents>("/api/remote-component")
   
   export default function MyClientComponent() {
     return <p>The server says: <MyServerComponent /></p>
   }

The current implementation has some caveats, but they are addressable. The most noticeable shortcoming is the lack of prerendering. If the implementation were in React itself (and/or Next.js) instead of userland, it would be straightforward to address these issues and further improve DX. For that reason, I am strongly in favor of implementing remote components in React itself. I think it would be a very compelling feature.

[revskill10]

This is easy if we have API to render a RSC from API route.

[jonathanhefner]

Unfortunately, I don't think it's quite that simple. As I mentioned in #70289 (comment), there are use cases that require special treatment. For example, passing children or ref to an "on-demand" server component.

Also, for a seamless developer experience, we would need more than just an API route. For example, we would need some kind of support from the bundler for "importing" a server component without actually importing it.

I put together a proof-of-concept that tries to address some of these issues, but a true solution needs more support from React itself / Next.js.