renderLoader - a loader than runs on the render target

[jakearchibald]

A couple of times I've ran into issues where:

• The source of data must be async, to avoid downloading it when it isn't needed
• The result must server render, eg for LLM scrapers
• The data is not serialisable, eg a module in the graph that exports a component

An example is cases where one of 100s of components is needed depending on state such as URL or cookies. Doing the work async within the component tree is not acceptable, because that would require a suspense boundary, and therefore wouldn't server render.

Duplicating code between the loader and clientLoader doesn't work, because the tree is hydrated before the clientLoader data is available. Plus you need to use hacks to prevent the unserialisable data being serialised in the loader (eg mark it as not enumerable.

I feel like I need a loader that runs where the rendering will be performed.

Here's how I understand loading happens now, assuming a fresh tab load:

1. loader runs on the server
2. Rendering is performed on the server, and loader data is serialised.
3. loader data is deserialised on the client
4. Client is hydrated with loader data
5. clientLoader with hydrate = true runs on the client.
6. Client render with clientLoader data.

And here's what I'm looking for:

1. loader runs on the server
2. renderLoader runs on the server
3. Rendering is performed on the server using the renderLoader data. But only the loader data is serialised.
4. loader data is deserialised on the client
5. renderLoader runs on the client
6. Client is hydrated with renderLoader data
7. clientLoader with hydrate = true runs on the client.
8. Client render with clientLoader data.

In cases where it's an SPA navigation:

1. Client requests loader data
2. loader runs on the server, and the data is returned
3. loader data is deserialised on the client
4. renderLoader runs on the client
5. clientLoader with hydrate = true runs on the client.
6. Client render with clientLoader data.

I think it would be rare to use renderLoader and clientLoader together, but I wanted to be clear about the ordering.

An example of a render loader:

export const renderLoader = async ({ request, params, serverLoader }) => {
  const loaderData = await serverLoader();  

  return {
    ...loaderData,
    MainComponent: await import(`./components/${loaderData.componentToLoad}/index.tsx`),
  }
};

export default function Render({ loaderData }) {
  return <Whatever navStyle={loaderData.navStyle}>
    <loaderData.MainComponent />
  </Whatever>;
}

For the API above, I'm following the patterns of the clientLoader. Hopefully this demonstrates the use-case, as MainComponent need to be there in the server render, and having all possibilities of ./components/${loaderData.componentToLoad}/index.tsx in the route bundle would be unacceptable.

serverLoader in ClientLoaderFunctionArgs would need to be renamed, as it would be returning the result of the renderLoader if one is present, not the "server loader". Maybe a name could be found that works for both the renderLoader and clientLoader. loaderData might be good enough?