SSR - traverse the tree and prefetch all data #3270

zsolt-dev · 2022-02-06T15:43:22Z

zsolt-dev
Feb 6, 2022

Hi,

I am new to react-query, so not sure I understand it correctly.

This is the SSR example from your documentation:

 import { dehydrate, Hydrate, QueryClient, QueryClientProvider } from 'react-query';
2 
3 function handleRequest (req, res) {
4   const queryClient = new QueryClient()
5   await queryClient.prefetchQuery('key', fn)
6   const dehydratedState = dehydrate(queryClient)
7 
8   const html = ReactDOM.renderToString(
9     <QueryClientProvider client={queryClient}>
10       <Hydrate state={dehydratedState}>
11         <App />
12       </Hydrate>
13     </QueryClientProvider>
14   )
15 
16   res.send(`
17     <html>
18       <body>
19         <div id="root">${html}</div>
20         <script>
21           window.__REACT_QUERY_STATE__ = ${JSON.stringify(dehydratedState)};
22         </script>
23       </body>
24     </html>
25   `)
26 }

As you can see, the current SSR implementation requires to manually prefetch all the data:

await queryClient.prefetchQuery('key', fn)

It would be nice to have it like apollo-client, that walks down the entire tree and executes every required query it encounters:

import { getDataFromTree } from "@apollo/client/react/ssr";

// This function walks down the entire tree and executes every required query it encounters (including nested queries). 
getDataFromTree(App).then((content) => {
  // Extract the entirety of the Apollo Client cache's current state
  const initialState = client.extract();

  // Add both the page content and the cache state to a top-level component
  const html = <Html content={content} state={initialState} />;

  // Render the component to static markup and return it
  res.status(200);
  res.send(`<!doctype html>\n${ReactDOM.renderToStaticMarkup(html)}`);
  res.end();
});

Is there a plan to implement a function like getDataFromTree() in react-query ?

Thank you

Answered by Ephem

Feb 6, 2022

I think this is already possible today using React Query with Suspense + react-ssr-prepass, which is a more performant implementation of a prepass render step than Apollo's one (at least last I checked). 🎉

When React 18 is released, while it wont have official support for Suspense data fetching, I think it might work out of the box with React Query as long as you are not streaming the response (or at least, as long as you don't hydrate the markup until you have the full response). If it does not work out of the box, I think that's where we should spend our effort instead of adding a prepass step, which is usually terrible for SSR performance.

Also, even with Suspenseful SSR, for the best …

View full answer

TkDodo · 2022-02-06T16:04:03Z

TkDodo
Feb 6, 2022
Maintainer

I have no idea how this is implemented in apollo, but it's a very cool concept. If you know how to so it, let's talk about a contribution :) I'm guessing since this is server side code, it wouldn't even affect client bundle size, right?

@Ephem fyi

4 replies

zsolt-dev Feb 6, 2022
Author

Yes bundle size will not be affected.

Here is how its implemented in Apollo:
https://github.com/apollographql/apollo-client/blob/main/src/react/ssr/getDataFromTree.ts

I do not know react-query at all so I would not know how to implement it.

This would essentially solve the SSR problem everyone is asking about in the discussion.

Thank you

TkDodo Feb 6, 2022
Maintainer

Right, I don't really see how apollo is doing it. It looks like it just renders the static markup, but I don't see how it knows which queries to execute. If we do that with RQ, I think we would have our cache prefilled with optimistic results - mostly empty loading states. So we would then need to pick those up and execute the queryFns.

It seems doable, however, I have one concern:

fetching on the server doesn't have to be the same as fetching on the client. I would argue that a lot of the time, it shouldn't be. We don't really communicate this in the docs, as our example is:

 export async function getStaticProps() {
   const queryClient = new QueryClient()
 
   await queryClient.prefetchQuery('posts', getPosts)
 
   return {
     props: {
       dehydratedState: dehydrate(queryClient),
     },
   }
 }
 
 function Posts() {
   const { data } = useQuery('posts', getPosts)
 }

where we use the same queryFn (getPosts) on the server and on the client. However, on the server, it could be a different thing, like:

await queryClient.prefetchQuery('posts', getPostsDirectlyFromDB)

all that matters is that the result shape is the same. On the frontend, we have to go and point to our api endpoint that then goes to the database. Maybe it's irrelevant, but that tree-walking mechanism would basically be forced to execute the function from the client also on the server. Maybe that's irrelevant, but maybe it isn't ...

zsolt-dev Feb 6, 2022
Author

Good points.

Everything was already sorted out by the apollo team:
Avoiding the network for local queries

Also skipping queries that should be only executed on the client etc...

TkDodo Feb 6, 2022
Maintainer

Everything was already sorted out by the apollo team:

yes, for graphQL specifically :) while ssr: false is something we could also adopt, I don't see how we could solve the first example where we want completely different queryFns. But maybe it's just a limitation we could accept

Ephem · 2022-02-06T17:33:53Z

Ephem
Feb 6, 2022
Collaborator

I think this is already possible today using React Query with Suspense + react-ssr-prepass, which is a more performant implementation of a prepass render step than Apollo's one (at least last I checked). 🎉

When React 18 is released, while it wont have official support for Suspense data fetching, I think it might work out of the box with React Query as long as you are not streaming the response (or at least, as long as you don't hydrate the markup until you have the full response). If it does not work out of the box, I think that's where we should spend our effort instead of adding a prepass step, which is usually terrible for SSR performance.

Also, even with Suspenseful SSR, for the best performance you will still want to start fetching those queries as soon as possible to avoid request waterfalls, so those prefetches will still be the best practice going forward, it's just that you can also start rendering earlier on the server. 😃

10 replies

Uttu316 Mar 10, 2022

Is there any tutorial that can help to use react-ssr-prepass with React query for multiple api calls?

TkDodo Mar 13, 2022
Maintainer

I was hoping that @zsolt-dev could contribute something to the docs or examples :)

zsolt-dev Mar 17, 2022
Author

@TkDodo Will prepare it during the weekend :)

PrescottJRynewicz May 22, 2022

Did we ever get around to this @zsolt-dev?

zsolt-dev Sep 16, 2022
Author

@PrescottJRynewicz

Submitted a PR just now :)

KATT · 2022-03-17T09:48:08Z

KATT
Mar 17, 2022

If someone wants a reference implementation, I have one in tRPC here which works alright (and isn't using suspense. It's heavily based on urql's prepassing but isn't using suspense either.

0 replies

dosco · 2022-06-15T13:33:40Z

dosco
Jun 15, 2022

This is pretty simple to implement and does not have to do with react-query or any additional package just use React.renderTo... functions.

await new Promise((onAllReady, onError) => renderToPipeableStream(el, { onAllReady, onError }));

const queryClient = new QueryClient();
const el(state) = <App queryClient={queryClient} dehydratedState={state} />;

await new Promise((onAllReady, onError) => renderToPipeableStream(el(), { onAllReady, onError }));
const dehydratedState = dehydrate(queryClient);

And the next time you call any of the React.renderTo... functions to do the real render then just pass back in the state by calling el(state) so that data fetch does not happen a second time. Any fetches trigged via a useEffect will be done client side and rest will be done server side

4 replies

TkDodo Jun 19, 2022
Maintainer

Any fetches trigged via a useEffect will be done client side and rest will be done server side

not sure I understand that. basically, useQuery uses useEffect under the hood - so how would this do anything on the server then?

dosco Jun 19, 2022

My bad. useEffect by itself does not enforce client side it will run server side as well. I use enabled: typeof window !== "undefined" on the useQuery to ensure it runs only client side.

Ephem Jun 20, 2022
Collaborator

useEffect definitely does not run on the server (even with the new APIs), so unless you are using Suspense, this wouldn’t work. Also, if you are using Suspense and the new APIs that support it, why do a prepass at all? You can just wait for the renderToPipeableStream and you’ll have your markup in the first pass. 😄

dosco Jun 20, 2022

If I recall correctly the reason was because the dehydration data is set in the <script> tag for the client to consume using the bootstrapScriptContent: option on the ReactDOM.renderToPipeableStream function itself so if the data it not available before renderToPipeableStream is called then you get empty values <script>window.__REACT_QUERY_STATE__={"mutations":[],"queries":[]}</script>. And yes suspense needs to be enabled.

Uh oh!

SSR - traverse the tree and prefetch all data #3270

Uh oh!

zsolt-dev Feb 6, 2022

Replies: 4 comments · 18 replies

Uh oh!

TkDodo Feb 6, 2022 Maintainer

Uh oh!

zsolt-dev Feb 6, 2022 Author

Uh oh!

TkDodo Feb 6, 2022 Maintainer

Uh oh!

zsolt-dev Feb 6, 2022 Author

Uh oh!

TkDodo Feb 6, 2022 Maintainer

Uh oh!

Uh oh!

Ephem Feb 6, 2022 Collaborator

Uh oh!

Uh oh!

Uttu316 Mar 10, 2022

Uh oh!

TkDodo Mar 13, 2022 Maintainer

Uh oh!

zsolt-dev Mar 17, 2022 Author

Uh oh!

PrescottJRynewicz May 22, 2022

Uh oh!

zsolt-dev Sep 16, 2022 Author

Uh oh!

KATT Mar 17, 2022

Uh oh!

Uh oh!

dosco Jun 15, 2022

Uh oh!

TkDodo Jun 19, 2022 Maintainer

Uh oh!

Uh oh!

dosco Jun 19, 2022

Uh oh!

Ephem Jun 20, 2022 Collaborator

Uh oh!

dosco Jun 20, 2022

zsolt-dev
Feb 6, 2022

Replies: 4 comments 18 replies

TkDodo
Feb 6, 2022
Maintainer

zsolt-dev Feb 6, 2022
Author

TkDodo Feb 6, 2022
Maintainer

zsolt-dev Feb 6, 2022
Author

TkDodo Feb 6, 2022
Maintainer

Ephem
Feb 6, 2022
Collaborator

TkDodo Mar 13, 2022
Maintainer

zsolt-dev Mar 17, 2022
Author

zsolt-dev Sep 16, 2022
Author

KATT
Mar 17, 2022

dosco
Jun 15, 2022

TkDodo Jun 19, 2022
Maintainer

Ephem Jun 20, 2022
Collaborator