Skip to content
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

RFC: @defer server + client hydration #3628

Open
gluonfield opened this issue Jun 30, 2024 · 1 comment
Open

RFC: @defer server + client hydration #3628

gluonfield opened this issue Jun 30, 2024 · 1 comment
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release

Comments

@gluonfield
Copy link

Summary

@defer queries are absolute game changer allowing quick partial UI rendering and simple developer experience. However, currently @defer queries can only be meaningfully used on the client side. Apollo implements a method to "await" when the query with @defer statements is executed on the server side. While this allows to reuse a single query in both server and client side, it is a suboptimal solution since the whole goal of @defer is to be able to render your data incrementally as it comes.

Proposed Solution

What would be great if when executing a query containing @defer fields on the server side the non deferred fields are queried on the server side as expected, while @defer fields should not block the the server and querying propagates to the client side. As the deferred data is incrementally fetched on the client side, it gets merged and becomes available for the components.

Advantages

  • Single query definition that can be reused on the server/client side
  • Developer does not need to split the query into two "server query" and "client query with deferred fields"
  • More compact and simple code

As far as I know no libraries support such hybrid approach yet, but it would be incredibly useful.

Requirements

@gluonfield gluonfield added the future 🔮 An enhancement or feature proposal that will be addressed after the next release label Jun 30, 2024
@JoviDeCroock
Copy link
Collaborator

JoviDeCroock commented Jun 30, 2024

Hey, 👋

Do you mean like #1408 where we have a function that checks the fragment and when there is no data it suspends? In React/Preact this is already a thing where suspense boundaries can function as stream flushes. As long as #1408 is implemented I think this RFC is completed as well.

I have made an attempt at this in the past #3570, however we discovered there that there's two options to make this work:

  • a direct subscription of useFragment to the cache.
  • in the root useQuery we replace the deferred bits with Promises that resolve.

The second option would be cache independent and probably desirable. The reason being that React needs a stable Promise and does not adhere to the normal rerender flow during streams.

IIRC, Relay has supported suspenseful fragments for quite a while.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release
Projects
None yet
Development

No branches or pull requests

2 participants