[RTKQ] How to set initial data for the query?

[khrykin]

Hi everyone!

Maybe I've missed something, but I haven't found this case in the docs:

Let's say I already have some data that I want to put in the cache upfront and use it on the first render from the same useSomeQuery hook. In short, I'm looking for something like https://react-query.tanstack.com/guides/initial-query-data in React Query. What would be an equivalent way of doing this in RTK Query? Or is this pattern isn't a good choice for RTK Query?

[khrykin]

@markerikson, could you please take a look? I've been hoping to get some pointers for this for quite a while now. Or is it not the right place for this kind of question?

[phryneas]

Yeah, the rehydration approach is not explicitly meant for that, but it could be used for that.

[khrykin]

@markerikson, @phryneas, thanks for the replies!

@phryneas, maybe it's just me, but it's not immediately obvious how to use extractRehydrationInfo for this case. Do I have to use Redux Persist? I so, it's a bit unfortunate - it kind of undermines RTK as the all-in-one Redux solution. Could you please provide an example? It seems that this strategy - using initial data to populate the cache - doesn't have first-class support in RTKQ - I'm also very curious about why it's the case?

Thanks!

[markerikson]

@khrykin fwiw, RTK is not quite a "100% all-in-one solution". It's more like an "80% common use cases" solution.

Redux-Persist is a separate library and has been for years. It is fairly widely used, but I wouldn't want to try to copy-paste it over into RTK directly. We RTK maintainers have never worked on that library, and it would add a significant level of complexity we'd have to keep track of ourselves.

[phryneas]

const rehydrateMe = createAction("rehydrate me!")

// ...
  extractRehydrationInfo(action, { reducerPath }) {
    if (rehydrateMe.match(action)) {
      return action.payload
    }
  },

// ...
dispatch(rehydrateMe({ /* object that you just snapshotted or pre-filled with the contents of your api slice */ }))

[phryneas]

As for "populating state" not being a very first-class feature: a lot of RTK-Q defaults towards "safe, even if inconvenient or unintuitive".

Many devs intuitively want to persist api state so that on a refresh less requests to a server are made. But they miss the point that the user hitting "F5" literally means that they don't trust what's on screen and are requesting new data.

So I'm leaning towards providing a way of doing this, but not making it too convenient - because it could actually be unwanted in the end.
Of course I also see that especially in app development, ppl want to sometimes keep stuff locally to speed up app start or allow for offline use - so we added the feature in a way that can also be used for stuff like that. But not as something "super-straightforward".

The primary, 100%-always-valid use is using it for rehydration after SSR, so that's what it was primarily designed for.