SSR fetches without data results going into store

[rpicucci]

Hi,
I know that I can use RTKQuery to do SSR fetches and have that information end up in the store but can I do a fetch on the server using RTKQuery and process the results myself without storing it? For every page get, we make an api call that results in some generic html which we stuff into a div as part of our page structure. Can you and are there any examples of doing fetches that don't end up in the store? I'd like one solution for data fetches and although we use redux as our primary caching for application state, we do occasionally make SSR fetches that end up being processed on the server by our code.

[phryneas]

That data needs to go into the store - how would the client be able to render it after hydration without it being in the store?
I could only tell you to maybe use two different api slices in that case and only rehydrating one of the two on the client?

[rpicucci]

It's not supposed to be treated like data. It's actual html so it gets shoved into a div. It becomes part of the SSR rendered page. In fact, I don't want it processed on the client because of various performance issues. I need it to be inserted into the page template and rendered on the server.

The sequence is as follows:

1. Make page get
2. On the server, fetch supplemental html from another service.
3. Insert that html into a tag
4. return the page with the rendered html

It's part of the rendered page and is not meant to go into the store. This isn't an option for us regardless of opinions of whether this should be done. My question is whether RTKQuery can be used without putting the result of step #2 into the store or do I need to use something other than RTKQuery. If so, then RTKQuery isn't optimal for us if we need to use RTKQuery for redux and ReactQuery for other fetch calls that result in various non-store targeted calls from the server.

[markerikson]

I'm genuinely not sure what kind of question you're asking here.

Can you create a meaningful example of what you want to do (like, a sample component with SSR logic)? even if it doesn't actually run.

I think the answer is "sure, you can use RTKQ to fetch that data in SSR, just don't send it back to the client at all", but I'm also not sure what you're doing overall, or what you're doing with the rest of the store state as part of this request handling.

[phryneas]

As I said: if you want some data to be rehydrated on the client and some not, then use two apis in two slices and only send one of the two slices to the client.

[rpicucci]

Hi Mark,
I'll see if I can create a sample in pseudo-code over the next day or so since our existing reactSSR code boilerplate is complex as it was written in the early days of react but to get a little bit more specific in the absence of that code, I'll see if I can explain.

When we do a page fetch, we are set up to do server side fetches for many of the REST as part of a page get like nextjs but using a different approach which results in a similar result. Those server side REST api call results go into redux store as you would expect and get hydrated on the client. We have a number of UI microservices which form our offering. The different UI microservices embed an instance of a common nav bar. Each service looks like it's part of the same service but they aren't IFramed into a container or anything like that. Every time a page get happens on the server, a copy of that nav bar code is fetched and embedded into the resultant page structure. As the user selects menu items from the nav bar menu, it may result in a change of the UI microservice but each service embeds that nav bar which is fetched when the page on the service is requested so other than the quick flash from changing services, it looks consistent. The nav bar html is dynamic based on target context which is carried though for every ui microservice.

A simplification of what we do in our legacy code (we actually do cache that nav bar html and don't always make the call on every page get), is make a REST call to a common service to retrieve the nav bar html in parallel to our call to "renderToString" on our react code while also making REST data calls in parallel. The result of nav REST call is actual HTML and not data - we are tied to legacy code on that one. So now we have the html returned from the nav bar REST call, we have html returned from the rendertostring call, and we have data returned from the data REST calls.

So we have 3 different things going on in parallel during a page get.

1. We are making REST calls that result in redux store data
2. We do rendertostring to get the html
3. We fetch the nav bar html

Once we get all of those back, we use a templating engine (dust) and construct the actual page with the appropriate insertions into the template to complete the page request. A simplied of page structure below

<body>
...
<header id='navbar' >
  <!-- nav bar html -->
</header>
<div id='root'>
<!-- rendered react -->
</div>

...
<script id="redux-script">
<!-- redux data -->
var __REACT_CLIENT_DATA__={"foo":"hello world"};
</script>
</body>

header=nav bar html
root=react html
redux_script= redux data
header=nav bar html

So that's how it works in the legacy code. Remember, this was written in the early days of react.

Now that I'm modernizing, I'm trying to reimplement it using nextjs/rtk and it makes sense to use RTKQuery in getServerSideProps to fetch the redux data for that page. It also makes sense to let nextjs do the normal rendertostring for the react code using its native code. That simplifies 2 out of the 3 parallel operations we do.

The one I'm struggling with is #3. I'm tied to legacy services which have no modern alternative but to get our nav bar html from a service. I don't want to fetch it from the client and I can't change it to let the application deal with the html and just fetch the data. It's designed for our services to just insert it into that header tag so it can be dynamically sync'd between our ui microservices.

This is where I am. I know RTKQuery is designed for the case where I'm fetching redux data but in this case, I'm not but I don't want to set up and use different fetch implementations for things that might not end up in the store like that navbar code.