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

React 18 shim #80

Open
klarstrup opened this issue Mar 30, 2022 · 3 comments
Open

React 18 shim #80

klarstrup opened this issue Mar 30, 2022 · 3 comments

Comments

@klarstrup
Copy link

Now that react-dom/server support data fetching and suspense as of react-dom@18, I was wondering how much work it would be to replace react-ssr-prepass and it turned out to be pretty blissful. So I'm writing this issue to share a cheeky drop-in replacement, I came by this repo earlier looking for such a thing so I figured I would provide it now that I figured it out:

import { renderToPipeableStream } from "react-dom/server";
await new Promise((onAllReady, onError) => renderToPipeableStream(<App />, { onAllReady, onError }));

Here's the diff in my app
image

@danielzlotnik
Copy link

Thanks for this @klarstrup !

This is still an opt-out of SSR-streaming though as we await for onAllReady.

Really hope Urql & React will sort out Suspense for data-fetching soon, that could be a real performance game-changer.

@kitten
Copy link
Contributor

kitten commented May 29, 2022

There's nothing for us to sort out 😅 Either you fetch during rendering or you don't, and that's outside of what urql can decide to do as it's in the Realm of what React guides everyone to do.
That said, with data dependency composition and hoisting using fragments you'd typically have one query per page on average and there'd then be less of a need to do a prepass, except for when starting a new codebase and such

@danielzlotnik
Copy link

danielzlotnik commented May 29, 2022

@kitten I may have completely misunderstood Suspense for data-fetching then :)

The way I understood / imagined it - once Suspense is ready to handle any async operation and not just code-splitting, there won't be a need to await all and any part of the HTML that is ready will be sent immediately, along with the Suspense fallback HTML, which will then be replaced by the "real" HTML once the data is fetched.

This approach will probably be more performant than running one blocking query per page, since you'd be able to immediately respond with a static above-the-fold HTML and then stream the data-dependant below the fold parts (for example).

This is at least how I understood the above article + the following comment in Dan's post:

Note: for this to work, your data fetching solution needs to integrate with Suspense. Server Components will integrate with Suspense out of the box, but we will also provide a way for standalone React data fetching libraries to integrate with it.

"Integrate" is a bit vague but as I understand it, the missing part is providing a way for data-fetching libraries such as Urql to tell React wether the Suspended content is ready or not.

Something like having useQuery integrate with a not-yet-existing React API and updating React with the state of the data-fetching, so that for the end-user of React + Urql - handling the loading state is encapsulated within React.Suspense + useQuery.

Close to what they did with Relay I suppose.

On next-urql's side it'd mean ssr-prepass will no longer be needed but it also shouldn't block the response by awaiting for onAllReady in getInitialProps.

But maybe it was all just wishful thinking on my end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants