RTK Query ServerSideRendering

[barnabasJ]

I'm trying to have serverside rendering together with rtk-query. I read through the issue on the old repository but I'm not using NextJs nor do I know exactly which components are rendered on the page because this can change depending on a config that I do not control.

I would like to propose the implementation of a similar feature to the getDataFromTree function from Apollo. In order to do this, it would be necessary to dispatch the action on the server. This does not happen at the moment because useEffects aren't exercised on the server.

It could be possible to add a ssrMode flag to createApi like the one on the ApolloClient which leads to the queries being fired once on the server.

I created an example of how I think this could work after the events are also fired once on the server https://github.com/barnabasJ/redux-ssr-example

I also create an example of how it works with apollo here: https://github.com/barnabasJ/apollo-ssr-example

[markerikson]

FWIW, anything resembling getDataFromTree is almost definitely not something we would do:

• The RTK team has no real SSR experience ourselves
• My understanding is that approach requires some very hacky and unsupported techniques built around hijacking the React rendering process
• Long-term, React's Suspense APIs are going to be the "right" way to handle data fetching in a server environment

I'm open to proposals here, but given our own lack of experience in this area, this is something that would likely require significant involvement by the community - requirements, design, and implementation.

[phryneas]

Hmm. Generally, I'd try to keep the "collecting" part out of the hooks, and I think getDataFromTree might be the wrong analogy here, since this is very bound to react, which RTKQ itself is not.

I have another angle, hear me out:

Right now, we can't support Suspense because of one icky little timing detail: The promise returned by dispatch(someEndpoint.invoke()) may resolve with a "this call is currently in progress" action. That makes that promise pretty un-usable for Suspense (and also frustrating to deal with when iteratively invoked in sagas or thunks).
So I will have to create a central place where all currently running promises will be tracked so I can piggy-back that promise onto the one that's currently running anyways.
I could expose those "running queries" via api.getRunningOperationPromises() or something.

I think that would solve the getDataFromTree question, but more as a side-effect of providing a better user experience.

The other problem would be triggering those useEffect calls. And there we could just allow overriding useEffect itself maybe? Then a SSR scenario could override useEffect with a "just call this" implementation for the hooks.

[ryota-murakami]

@phryneas useEffect() doesn't run while SSR.

[phryneas]

Yes, but "overriding" would also mean "override it with (cb) => cb() - meaning a function that just immediately executes

[phryneas]

Based on what I've seen in #1270, I have added another PR in #1277 with my suggestion. Do you think that direction could work?

[Ephem]

If I understood correctly getDataFromTree could also work with the suspense implementation as it only listens to the dispatched actions inside the store and I assume they would still be dispatched with suspense.

I think so!

I think it would make total sense to have getDataFromTree as a third party library, it just was easier for me to show you what I was trying to accomplish doing this all inside the one repo.

Oh yeah, it was a great proof of concept, totally get why you made the PR like that. 😄 If RTK Query would rely on Suspense/throwing promises, one such third party library is react-ssr-prepass as I mentioned, but nothing would stop other implementations, or trying out React 18 alphas etc.

So I will have to create a central place where all currently running promises will be tracked so I can piggy-back that promise onto the one that's currently running anyways.

This definitely sounds like the missing piece of the puzzle!

The other problem would be triggering those useEffect calls. And there we could just allow overriding useEffect itself maybe? Then a SSR scenario could override useEffect with a "just call this" implementation for the hooks.

I'm not quite sure about this part mostly because I'm not that familiar with the RTK Query implementation, depending on what happens it might not be as easy as just running the same effect, it could mean problems in SSR mode and perhaps a separate "immediateEffect" would be needed. I left a more detailed comment about this with a bunch of questions on the PR (which I think looks good overall!).