Design Question regarding RTK Query support

[phryneas]

Heyo, I'm one RTK Query devs.

First let me say it's great to see this getting into active maintenance again - thank you @ckalika!
I've noticed RTK Query on the roadmap and I'm stoked to see that happening. Generally, if we can improve the way this works with Redux Toolkit that would be great and maybe even getting RTK into the examples, given that it's the default style of Redux we're teaching in the Redux docs by now.
If you're up for a chat with us maintainers, just ping me up on Discord (phryneas#4779) and I'll initiate a group chat.

That aside, that's not really the point of this ticket. I'm currently implementing an API that would allow for rehydration after SSR and theoretically that should also work for redux-persist rehydration, but I'm not 100% sure if the api is sufficient since I haven't used redux-persist in multiple years.

The ticket in question is https://github.com/reduxjs/redux-toolkit/pull/1277 and what it does is that it adds a extractRehydrationInfo option to createApi that would just allow to pick out any action containing rehydration info and thus trigger a rehydrate.

It is used this way: (full code here)

  extractRehydrationInfo(action) {
    if (action.type === HYDRATE) {
      return action.payload.api;
    }
  },

So what I would like to know from you: is this a viable approach? Is it possible to have Redux-Persist persist a reducer, but not rehydrate it through redux-persist?
I imagine that would need some kind of custom reconciler with a blacklist (assuming you want to just persist & rehydrate the rest of root normally, which most ppl probably do), but as I said, I'm not really experienced with redux-persist and I figured before I try around forever I'll just ask :sweat_smile:

Also mentioning #1334 for that ticket to link over here.

[ckalika]

Hey @phryneas.

I implemented RTKQuery + redux-persist for a demo project a few weeks ago, so it's definitely coming. And to you and your fellow maintainers, thanks a lot for all the hard work. 🥇

I'd very much like to look at how we might handle selective persistence/hydration, going forward. My expectation is that v7 will be a major rewrite (e.g. shifting from Flow to TypeScript) so there are a number of features I'd like to explore so we can prioritise them. Updated docs are definitely the first step, so we'll try to get those working ASAP.

I think it would likely be worthwhile to discuss how redux-persist could (should?) work in an SSR environment, as I've been thinking about how one might use Redis (for example) for shared state management across a host of servers. The specific reason for Redis in this instance is that it supports Pub/Sub and Streams, which mean there may be ways of doing server-side updates and maintaining state across applications. It's not just a redux-persist consideration, but it has massive implications with regards to how SSR works and how state is synchronised, both across devices and between client/server. It's purely a thought experiment right now, but I've implemented similar things before (the hard way), so I know that it can work, and I'm sure there's some overlap with what you guys are doing with RTKQuery.

As to your question about persisting a reducer and not rehydrating it, I'll have to do some digging in the current version. I'm fairly sure there are ways we could make it work, even if we have to add it as a feature without breaking the existing APIs.

I'll drop you a note and we can arrange a group chat. I appreciate you reaching out.

[llaver]

I'm looking for a way to whitelist or blacklist specific endpoints so that the entire api does not need to be persisted. Any suggestions?

[hevar]

Did this happen?

[abomblabrom]

I'm looking for a way to whitelist or blacklist specific endpoints so that the entire api does not need to be persisted. Any suggestions?

did you ever figure this out?

[bisak]

@ckalika Hey, It'd be hugely appreciated if you ever figured this out and wanted to share ^

[RRaideRR]

Hey @bisak @abomblabrom @hevar @llaver,

what did you end up doing?

[llaver]

Hey @bisak @abomblabrom @hevar @llaver,

what did you end up doing?

We ended up splitting them into separate API instances so that each one could have its own specific configuration, and then would just reference whichever was needed for whichever situation. We thought of it like a service. So you might have separate configuration for an auth service, a data service, an orders service, etc.

Ended up not being much extra work and didn't add any extra overhead after the initial refactor.

[bisak]

I was in early stages of implementation so just decided to switch to tanstack query, which has it's own way of doing persistence.

[RRaideRR]

Hey @bisak @abomblabrom @hevar @llaver, what did you end up doing?

We ended up splitting them into separate API instances so that each one could have its own specific configuration, and then would just reference whichever was needed for whichever situation. We thought of it like a service. So you might have separate configuration for an auth service, a data service, an orders service, etc.

Ended up not being much extra work and didn't add any extra overhead after the initial refactor.

You're talking about separate createApi calls - right? One persistedApi and one normalApi? I think that's a good solution that comes with a caveat: tag relationships across the different endpoints. But this would work for me :-) - thanks for the inspiration and your fast answer 🙏