react-query and New Suspense SSR Architecture in React 18

[artem-malko]

First of, I want to recap, how it works right now, with React 17 and older. I mean React + react-query + SSR. The main idea is described here, in the docs — Prefetch the query on the server, dehydrate the cache and rehydrate it on the client.

This approach works well with sync version of React render. But, new suspense SSR architecture is quite different. The base idea is the same — prefetch, dehydrate and rehydrate. The main question is about timings. So, I think, that I have a solution, that I'd like to discuss.

There is a link to a repository and a link to this project in action.

If you will open the last link, you will see, that where is a loader on a place, where newsList component has to be. After several seconds, the component source code and a data for it will be loaded. The whole document will be ready. React-query is used here as a data-fetcher and store, React.lazy for code-splitting. The main guy is React.Suspense.

As you can see from that demo, there is no useless requests from the client side. Dehydrate and rehydrate works perfectly, even renderToPipeableStream is used. So, how it's made?

renderToPipeableStream returns just two methods right now: pipe and abort. Abort is used to abort current request (obviously). Pipe is the most interesting guy here. We can pass any writeable stream into that pipe. It can be res writeable from ExpressJS in my implementation. In that case, there will be a useless request for the data for newsList, cause there is no any dehydrated data in a response. So, how to fix it? How to add a dehydrated data to the stream?

I've started with that discussion — Library Upgrade Guide: <style> (most CSS-in-JS libs). Yeap, it is about CSS) But, there is quite interesting idea. We can wrap a response writeable with our own wrapper, where we can add any data to that stream. So, I've created my own wrapper for CSS in JS. And I added some logic to append all data from react-query cache into the stream. You can check out it here.

Every time, when React tries to write some HTML into the stream, we will try to dehydrate query into the stream, if there is anything in the react-query cache. The data will be wrapped with a script, which will be executed as soon, as it will be on a page. React won't render anything at that moment. So, there won't be any errors about server and client HTML mismatch. There won't be a general dehydratedState, but each query will have its own object inside the HTML.

Now, let's talk about client side. Right now, with React 17, we must use component with dehydratedState to start the client side version of the app. But we can not use it with after renderToPipeableStream, cause there is no any general dehydratedState. There is one simple approach, how to fix it.

I've created a simple wrapper around react-query — useCommonAppQuery. It has several purposes. The main is to read a dehydratedState for the current query. There is a function for it — getDehydratedQueryStateFromDom. We will just read the data from window and hydrate the query by calling hydrate method from react-query for the current query. And voila, everything works like a charm!

So, what do you think about that approach? Do you have any other ideas, how to hydrate/dehydrate with new Suspense SSR Architecture in React 18?

[TkDodo]

hydration per query looks like a cool thing for the new React 18 Suspense SSR approach. Do you have a proposal on how to integrate this directly with react-query ?

One question: Is it "safe" (= allowed by the rules of react with regards to concurrent mode) to call hydrate during render, like you're doing in useAppQuery here?

[artem-malko]

About the proposal.

It is quite early to create a final implementation in react-query right now, cause React 18 is still in alpha. Something can be changed in the future. But I'm ready to implement it in the future) I'll think about performance too, cause as I think, there a lot of I can do. Maybe my idea is totally incorrect from the React-core team's point. As I understand, they are thinking about server components as a solution. It's just my guess)

By the way, as I understand, you can start a new discussions in reactwg. So, you can discuss this idea there.

About safety.

First of, there is no any warnings from React, even in a Strict mode) Actually, I do not have much expertise in the concurrent mode internals. But, as I can see, there is no any explicit taboo to do it. I think, this is a theme to discuss with the React-core team.

[artem-malko]

By the way, I think I can call @acdlite right here) As a React-core team member, he would be able to shed some light on this. May be this concept to insert a query cache data into the stream (like in css-in-js proposal) is not a good idea? I'm sorry, Andrew, I know, you are really busy. But your opinion is quite important. I just need a right direction to continue with my proposal)

[Ephem]

I don't have time to dive into the details right now, but I think the basic approach you are describing is the correct one when it comes to supporting Suspense+Streaming SSR. There's some notes about this in the pretty new Library Upgrade Guide: <script> (e.g. SSR frameworks)
under "Hydrating Data".

First:

You don't just need code to hydrate. You also need the data that was used on the server. If you use a technique that fetches all data before rendering you can emit that data in the bootstrapScriptContent option as an inline script. That way it's available by the time the bootstrap script starts hydrating. That's the recommended approach for now.

I think this is what we should aim for when it comes to initial React 18 support. I think this is a matter of capturing an immutable snapshot of the initial React Query cache on the client and passing that as the getServerSnapshot-argument to useSyncExternalStore. I think we also need to take a hard look at the current hydration API when it comes to concurrency..

Note that this would not support the current RQ Suspense-API with streaming and progressive hydration. The Suspense API with streaming but without progressive hydration should work though, since the entire cache would then be available before React hydration starts on the client.

Later:

The real trick is when you use Suspense to do you data fetching during the stream. In that case you might discover new data as you go. This isn't quite supported in the React 18 MVP. When it's fully supported this will be built-in so that the serialization is automatic.

However, if you want to experiment with it. The principle is the same as the lazy scripts. You start hydrating as early as possible with just a placeholder for the data. When the placeholder is missing data, and you try to access it, it suspends. As more data is discovered on the server, it's emitted as script tags into the HTML stream. On the client that is used as a signal to unsuspend the accessed data.

This is probably worth experimenting with when step 1 is in place, knowing that experimentation might be superseeded by an official solution later.

[artem-malko]

Hi, @Ephem!

I've seen that doc (I mean "Hydrating Data"). It makes me feel more confident in my proposal) But, in other hand, there is a Cache API, which won't be in the initial React 18 release (check out this discussion).

I'm absolutely agree, that we have to upgrade react-query first. I mean getServerSnapshot and useSyncExternalStore usage inside react-query.
So, I think, my proposal should be implemented as an approach, rather than hardcode inside react-query's codebase. The main reason is that experimentation might be superseded by an official solution later, as you said before. So, we won't block anybody to use that brand new React 18 SSR API.

Right now, my plan is:

1. I'm going to switch to react-query alpha in the project from proposal. I'm adding more usecases (mutation hydration/dehydration, infinityQueries, more options and so on).
2. I'm expanding current react-query API with hydrate/dehydrate methods per each query. These methods won't break anything. Correct me, if I'm wrong)
3. After that I'm updating my project, to use the new hydration/dehydration methods.
4. And the last step is to describe the approach in the docs.

This plan will work perfectly for experiments with the new React SSR API and it won't block the official solution. So, what do you think?)

@TkDodo fyi)

[Ephem]

I think this sounds great! 💯

I'm super happy that you are experimenting with this and sharing it and I'm very curious to follow along. 😃 I think there's a lot of value in trying out the Cache API early as well to see what's feasible there as well as give feedback on it.

[artem-malko]

I think this sounds great! 💯

🎉

I think there's a lot of value in trying out the Cache API early as well to see what's feasible there as well as give feedback on it.

I'm agree, but, unfortunately, where is no any docs for Cache API with SSR( May be somebody from React work group has a context about it, but not other developers) By the way, do you know such people?

[Ephem]

I'm not aware of any such docs either, I think it's still early experimentation days for that API. I have a feeling this is one of the things that will be discussed over in the Server Components Working Group when that gets off the ground. 😃

[artem-malko]

Thx for the link. Will be watching for this)

[artem-malko]

@TkDodo hi)

As I can see from https://github.com/tannerlinsley/react-query/blob/master/src/core/hydration.ts there is a dehydration process for mutations. Do you know any cases, where mutations intended dehydration?

[TkDodo]

We use hydration for the persistence plugins, and paused mutations get persisted as well.

[nitedani]

This works well for me:
https://gist.github.com/nitedani/85a7a9c8f80740537fe2fdef836d2bfb

[artem-malko]

Thx) Looks like we have the same thoughts) I've done a quite similar implementation.