Support for React Server Components

[tobias-tengler]

Today you can't use Relay with React Server Components, because the RelayEnvironment is handed around using React Context.
Most of our components will still remain client-only, but there are some of our pages that would benefit greatly from being statically pre-rendered using React Server Components. In these components we'd also like to use Relay's useFragment to be able to re-use existing fragments and developer knowledge.

Since the Relay Environment context is basically just a dependency injection mechanism, it could also be replaced by React's cache API on the server. Maybe we could define that useRelayEnvironment consumes the environment from a React cache instead of context in server-components or on the server in general. This could be achieved through the react-server conditional export.

Are there any objections to this or other ideas? Otherwise I'll try to create a proof-of-concept over the coming weeks.

[tinleym]

It would be great to have a useFragment that just works everywhere. I've gotten fragments to work on the server w/ a server-specific useFragment and prop-drilling the environment, but having different fragment call signatures can mean having server and client versions of what should be the same components.

[tobias-tengler]

The proposed solution using the package.json export would not alter the signature of useFragment or useRelayEnvironment. Just a different implementation would be used whether the code is executed in Server Components or on the client.

[sibelius]

check this relayjs/relay-examples#270

[tinleym]

Do you have ideas on how to handle usePaginationFragment?

[alunyov]

Great question @tobias-tengler , and thank you for bringing this up!

Yes, your suggestion of building a different version of APIs designed to run on the server is correct - and that's what I did for our internal prototype for RSC and Relay. However, we don't have the same control over what modules to load using conditional flags in node.js, so we just built a different module for Relay on the server. Nothing fancy there - just a lookup a fragment in the store, and fetchQuery.

For the React's cache - yeah, you could do that, but you can also just use globals since cache is needed for kind of expensive computations you want to reuse. But for the Relay environment, we just added a module where you need to call a method to create an environment before you run any RSC rendering.

Basically, the server module of Relay will have 3 things: useFragment, loadQuery, and something to create/register an environment.

As for pagination and refetch - these have to be driven by your RSC framework (I don't think there is a good way now to share the state of the store between client and the server, so usePaginationFragment - a client-only hook won't be able to really work on the server).

An interesting aspect is the integration of fetchQuery and RSC streaming - in my prototype, I just added support for a single request-response format (where fetchQuery returns a promise), but it is possible to make fetchQuery with observables to stream RSC payloads (I think).

Anyways, it is a very interesting area to experiment with, so feel free to look into that and build a POC, and I'm happy to provide reviews (when available).

Thank you again for looking into this!

[sibelius]

I think usePagination and useRefetch can do the initial fetch on the server, and the refetch queries on the client

[alunyov]

The problem with refetching, is that it also need to re-render server components that use data from these hooks, so you need to referch the RSC not the graphql endpoint

[tinleym]

Could it be feasible to break up usePaginationFragment, where the initial fetch is done on the server, and the refetch is imported into a Server Action?

[edvinerikson]

I've started some work on a library that enables Relay in RSCs. https://github.com/Pokeyo-AB/relay-rsc