You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of my favorite features of RTK Query (in the React ecosystem) is the ability to dynamically generate the key, based on the query results, right before it gets cached. For example, when fetching a list of Todos:
This way, when mutating a specific Todo (such as id: 5), I can invalidate any and all cached queries that contain { type: 'Todo', id: 5 }, while not, unnecessarily, invalidating any Todo caches that don't have that specific Todo.
The text was updated successfully, but these errors were encountered:
the ability to dynamically generate the key, based on the query results, right before it gets cached.
I don't think this is a good idea because when querying, you already have an id to use, not having the key ready before fetching wouldn't allow deduplication. In Pinia Colada, the entries with the state require the key to be computed before actually fetching the data, so it won't be possible.
This way, when mutating a specific Todo (such as id: 5), I can invalidate any and all cached queries that contain
You can already do that in mutations with the hooks (not yet documented). They get passed the variables passed to the mutation handler, which allows you to precisely invalidate queries.
One of my favorite features of RTK Query (in the React ecosystem) is the ability to dynamically generate the key, based on the query results, right before it gets cached. For example, when fetching a list of Todos:
This way, when mutating a specific Todo (such as id: 5), I can invalidate any and all cached queries that contain
{ type: 'Todo', id: 5 }
, while not, unnecessarily, invalidating any Todo caches that don't have that specific Todo.The text was updated successfully, but these errors were encountered: