-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for React Server Components #4599
Comments
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. |
The proposed solution using the |
check this relayjs/relay-examples#270 |
Do you have ideas on how to handle usePaginationFragment? |
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 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 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! |
I think usePagination and useRefetch can do the initial fetch on the server, and the refetch queries on the client |
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 |
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? |
I've started some work on a library that enables Relay in RSCs. https://github.com/Pokeyo-AB/relay-rsc |
Looks like there's some movement to get server components back from a server action: https://sdk.vercel.ai/docs/ai-sdk-rsc/streaming-user-interfaces Addendum: It turns out that server actions can return components, even suspense wrapped components. Pretty neat! However, if you're using Next, you'll probably want to familiarize yourself with this issue and workaround: vercel/next.js#58125 |
I am also working on creating a PoC. Here are the key points:
Unresolved issues:
Feedback on relay maintainers:
|
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 thatuseRelayEnvironment
consumes the environment from a React cache instead of context in server-components or on the server in general. This could be achieved through thereact-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.
The text was updated successfully, but these errors were encountered: