React 18 shim about react-ssr-prepass HOT 3 OPEN

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.

from react-ssr-prepass.

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

from react-ssr-prepass.

@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.

from react-ssr-prepass.