RSC: How to realize shared code with client-specific execution results about react

[sebmarkbage]

For the RTK Query example the idiomatic way would to be to fork the createQuery implementation into a “react-server” specific implementation.

exports: {
  “query/react”: {
    “react-server”: “./query/react-server.js”,
    “default”: “./query/react.js”
  }
}

The import and api can work the same way in both environments from the consumers perspective.

When calling the react-server version of createApi it can generate a stub version of the Hook which throws a helpful error when used in Server Components or just exclude it all together.

The principle that underlines this is static optimization of various combinations. In the ecosystem we shouldn’t have to boot code that includes all possible runtime branches. We will also move to use export conditions for production/development for example to support ESM for similar reasons.

This goes both ways that the client shouldn’t have to download server specific things for the branches that uses server-only things but the server also shouldn’t have to boot a bunch of code that isn’t relevant on the server.

So that’s why it’s worth having two separate implementations/entry points to the api that can each be optimal.

Yes, it’s a burden to library authors to optimize code but it’s a one time thing that helps the end user at the end of the day.

[sebmarkbage]

For the Apollo section questions:

how to have a piece of code that will definitely be executed per request on the server, and once on the client? An equivalent of just writing code in front of root.render?

const getSingleton = React.cache(() => {
  return new PerRequestThing();
});

This won’t necessarily give you a single one on the client since the client cache can be refreshed but that might actually be a feature you want. For other cases you can use a module level variable only on the client but it really depends on how you’re getting this because it has to be called inside React render for it to be contextual to a request.

Not sure how you’re thinking about the rest of the api.

how to create components that are meant to be rendered client-side, but not by importing a file, but by calling a method?

If the component is meant to execute during SSR and then hydrate, it’s a client component and it works the same. As long as it’s used in a client component scope.

It doesn’t work to have a library generate a client component from a server component on the fly thought. The code for them must be built by the bundler and we have to know to be build them before it happens. So this doesn’t really work in the general sense without the user placing its code somewhere behind a “use client” in the bundler graph.

is there a way of forcing a certain component to be rendered both on the server and on the client?

Not sure what this means. Is it referring to “SSR” then it’s just a client component.

[phryneas]

@sebmarkbage thanks for the Apollo-part answers, but I think we can ignore that part, which is why I collapsed it :)
The "Apollo" part has already been answered in depth and we have a RSC-ready Apollo Client companion package over here: https://github.com/apollographql/apollo-client-nextjs (also see the related RFC)