Is cache done by tag or by query & tag?

[LoyalPotato]

Say I have two queries that can return the same data. One is a single get that returns a single resource, while the other receives an id list and returns a resource list.

If I make a request on the single get with id: 1 and provide the tag:

{type: "Foo", id: 1}

And then in the list query, I do a get with only the same id and provide the same tag:

{type: "Foo", id: 1}

Does the list query return the cached item or does it perform a new request since it's a different query with different params and endpoint.

[phryneas]

Tags have no influence on cache entries. You can have 200 cache entries with completely different contents and the same tag. Tags are like labels you slap onto something to later say "invalidate everything with a red label".

Cache entries are a combination of endpoint name and the argument you put into it.

So useSomeQuery(3) would end up with a cache entry some(3) and useSomeQuery(5) would give you some(5). There is a little bit of sanitizing going on, so useSomeQuery({foo:1, bar:2}) will have the same cache entry as useSomeQuery({bar:2, foo:1}).

There is no consolidation of similar contents over multiple cache entries. RTK Query is a document cache and every cache entry is completely individual.

[LoyalPotato]

Can I ask why RKT Query behaves like this? In the sense as to why this and not something else.

Also, I'm not sure if this is a valid question based on how RTK Query is implemented, but is there a way to integrate a caching system like I described with RTK Query? Like some sort of middleware that checks the cache first before forwarding the request to the specified endpoint.

Thanks for the quick answer btw :)

[phryneas]

Because it is almost impossible to do so on a "generic, works for everything" approach.
If you need something like that, it will end up being a solution that is very much tailored to how your api works. It's very hard to write a library that gives you abstractions for that that just work for everyone.

Luckily, it's usually just not necessary.
Api requests are extremely cheap - if you don't have an application on the level of google, it's much cheaper to just get data from the server than pay a developer find a "clever" solution for it.
See it that way: 20 years ago, every single click of every user reloaded the full web page, making every database request for that internally - that's essentially every click refetching all apis.
Servers 20 years ago could handle that gracefully, and PCs have pretty much doubled in speed every year since then.

There might be some rare cases - and either you just look into the list yourself and sometimes skip the useSingleItem hook or you really need to implement your own cache for your use case.

[LoyalPotato]

Makes total sense. Thank you for your input!