Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding a util function to remove a specific cache entry #2820

Open
markerikson opened this issue Oct 26, 2022 · 1 comment · May be fixed by #4216
Open

Consider adding a util function to remove a specific cache entry #2820

markerikson opened this issue Oct 26, 2022 · 1 comment · May be fixed by #4216
Labels
enhancement New feature or request rtk-query
Milestone

Comments

@markerikson
Copy link
Collaborator

We've got utils to add and update cache entries, but we don't have one that would remove a specific cache entry by key.

We've had a couple requests for something like this recently, so worth discussing.

Lenz had these thoughts in chat:

Two different use cases though:

  • delete on invalidate with refetch
  • manually delete

For the first, we could add something like invalidationBehaviour: 'refetch' | 'remove-and-refetch' - both globally and on endpoints.

And the second... yeah, I guess we could add that as well, but the user story there is not exactly clear yet tbh.

Either way: the hooks would still hold on to the value, but of course currentData would be available

What specific use cases do people have for wanting to manually remove a cache entry?

@ggaabe
Copy link

ggaabe commented Oct 26, 2022

I think having an option to invalidate tags without refetching for subscribers would be great.

I work on a cardano wallet and was looking for something like this for our adahandle support (adahandles are basically shortcodes for addresses that are minted / powered by NFTs).

A user could type an adahandle to send their coins to in the receive bar. That dispatches an initiate call to our api, which we await for the result.

All is well at this point. The problem arises that ownership of these shortcodes can change from minute to minute, or they can be created on-chain if they didn't exist before. Therefore, we don't want to cache the result for very long. However, we also don't want to continuously requery all handles that were ever searched, as this would bog down the server that indexes these handles.

At first, I tried setting a timeout to invalidate the tags after awaiting onQueryFulfilled. However, this would immediately trigger a refetch for that handle (even if the user was no longer searching for that handle's underlying crypto address).

The solution I resorted to was basically along the lines of

const dispatchObj = dispatch(api.addressForHandle.initiate(handle))
let unsubscribeMethod = dispatchObj.unsubscribe
const data = await dispatchObj
unsubscribeMethod()

And then the onQueryFulfilled callback had a setTimeout that invalidated the tags result for that handle after a certain amount of time.

I had to handle the subscriptions like this, because otherwise invalidateTags triggers an infinite loop of refetches for a potentially irrelevant query since the invalidateTags creates a subscription to cleanly await it. However, if I set subscribe to false, awaiting the dispatch does not await the actual data from the response.

My desired behavior was:
Query handle
Cache that handle for 5 minutes
Remove from cache after 5 minutes
If user requeries that handle, refetch.

My guess is useQuery with a pollingInterval would have been best suited for this, though my app totally crashed when I tried using this arrangement so I had to revert to dispatching initiate calls.

@markerikson markerikson added this to the 2.x bugfixes milestone Dec 6, 2023
@markerikson markerikson added the enhancement New feature or request label Feb 6, 2024 — with Volta.net
@riqts riqts linked a pull request Feb 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request rtk-query
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants