RTK Query: Is there a way to find out cached queries parameters related to specific tag/id to help manual updating the cache??

[henkkasoft]

I have understood that if you want to manually update cache you can do it with updateQueryData. You need the API endpoint parameters used in the query to update this specific response.

There are two problems I am facing here.

1. I need the know the exact parameters used for this query to be able to manually update the response.
2. There might be several different cached queries that should be updated.

When I update some item with useUpdateItemMutation, it gives the updated item as response. Now if I want to update the cache manually instead of invalidating the id to prevent unnecessary API calls it is hard to perform.

Whereas invalidating id can be done by giving the tag and id and all the cached queries related to that are handled.

My application has list of items (as responses for searches with different kind of query parameters) and the same item can be in many of them. When I am performing the update I would need to make sure that the item is updated to all lists where it is.

I don't know if this is possible without invalidating?

I understand that RTK Query is not normalized and therefore I cannot update the tag/id directly but
could it be possible to add a way to get all cached API calls (including used parameters) related to spesific tag/id?
Then I could manually update the caches everywhere when needed.

This issue is related to this #1529 (comment)

EDIT: Just noticed RTKQ uses the query name for the updateQueryData call, although it uses tags for query invalidation. react-query uses the equivalent of tags for all of these operations. I wonder if the invalidatesTags array could also just use the query name. Or alternatively if updateQueryData could just use tags. Anyway, this is a totally different conversation. I was just kind of thinking out loud. I suppose it's likely there are limitations that prevent this sort of thing.

[phryneas]

We really need to add api.util.selectInvalidatedBy to the docs. Sorry, totally our fault.
You are looking for this:

redux-toolkit/packages/toolkit/src/query/core/buildSelectors.ts

Lines 200 to 207 in f7a8282

	function selectInvalidatedBy(
	state: RootState,
	tags: ReadonlyArray<TagDescription<string>>
	): Array<{
	endpointName: string
	originalArgs: any
	queryCacheKey: QueryCacheKey
	}> {

If you have the time and energy, a PR adding this to our documentation would highly be appreciated.

[zvolcsey]

Hi, can I help add this to the docs?

[phryneas]

Sure, that would be very welcome!
Make yourself a fork of this repository and start editing the documentation over in the /docs/rtk-query folder.

You don't even need to check it out locally for the most part - just press the . key on your keyboard once you are in your fork.

Once you're done, create a PR from your fork :)

[dutzi]

Hey @phryneas, is there a recommended way to make RTK Query maintain a normalized cache?

For example, if I have 2 queries for listItems, with different arguments, that for some reason overlap (some of the items returned are the same in both queries), RTK would store the overlapping items twice.

Is there a way to make it store them only one, in a cache where the key would be comprised of the items' Tags and ids?

[phryneas]

@dutzi RTK Query is per design not a normalized cache, it's a document cache.
There is no recommended way to do that with it - it's just not a design goal.

[dutzi]

Thanks @phryneas.

For anyone wondering why that is, I found this and this.

[talatkuyuk]

Your objective is really hard @henkkasoft.

According to my experience, even if you get the cached queries to be updated using selectInvalidatedBy util, you need to parse the queryCacheKey for each cached query, and you need to decide to delete, update or add the record into/from the cached query according to the mutation context. It is very error-prone approach.

Let me give an example. For instance, you've disabled a user in a mutation (you toggled user.isDisabled in the database). Think about you made several user queries before, including the filter key isDisabled or not with different filter keys and also with several sorting parameters.

According to your mutation (user.isDisabled is toggled), this user may needed to be inserted into a cached query which does not include that user before. If there is also some sorting parameters, the user may needed to be inserted in a right place according to sorting params. Or, this user may needed to be deleted from a cached query since the query param may consist isDisabled field as true or false, etc. Or, this user may needed to be only updated but if there is a sorting param affected, you should change the order of the user record in the cached query etc. I don't even want to mention pagination, makes it even more complex.

Given example is for only mutating one field. Think about more than one fields are updated in the mutation. The situation goes more and more complex. So, the updating the related cached queries manually is hard, and error-prone.

The only reliable way seems to provide invalidatesTags for the mutation.

But, I had a feature request from the authors, saying that, while providing the invalidatesTags, give us an option for not invalidating the latest query just before this mutation; or give us an option not invalidating (skip/omit) the queryCacheKeys (string or string[]) provided in an option in order to the developer can update manually without invalidating automatically. The related discussion is here.

[markerikson]

The docs were updated, so I'm closing this.

If there are further feature requests, please file a new issue!