Unable to clear persisted queries
I'm using the
experimental_createQueryPersister to persist query data in indexedDB.
Unlike PersistQueryClientProvider and createAsyncStoragePersister which deletes the persisted data when queryClient.clear() is triggered, the data is not deleted when using the experimental persister.
Is there a solution to this while maintaining the experimental persister.4 Replies
genetic-orange•7mo ago
You need to manually remove it, we expose all the methods for that
Since the cache isn't "synced" this doesn't work out of the box
@MrMentor i just had an idea: could we set up an additional provider that subscribes to the cache and listens to events like when a query is removed and then removes it from the storage if the query has a persister attached?
We could sync updates from setQueryData in a similar way 🤔
useful-bronze•7mo ago
Well this is framework specific integration at this point.
Sure we could do it, but some might not want this as a default behavior, since query might be
removed due to GC timer which not always needs to clear persisted data.
Do we have a way to tell if query was removed manually by the user?
I was also thinking about some kind of patch functionality to override prototype of QueryClient and hook persister functionality there, which would work in framework agnostic way. But not sure if that is the best idea.
Hmm I think we did not expose something like clear storage, only gc storage, but this should be an easy addition.rival-blackOP•7mo ago
As @MrMentor mentioned, there is no method provided to manually clear all persisted data.
The only alternative I can think of is having a separate function which directly clears the indexeddb by using "idb-keyval"'s clear() and passing it a store with exact values used to create the persister storage.
Using an inbuilt method instead would be more convenient.
genetic-orange•7mo ago
if we do
queryCache.subscribe(event => ..) we get all events, that includes removed events, no matter if it's done automatically or manually by the user.
I think this can all live within the core, and then we'd only need framework specific ways to subscribe/unsubscribe. In react, this would usually be in an effect.
the only thing we can't help with I think would be queryClient.getQueryData because that's a synchronous method that reads from the in-memory cache only, and it can't trigger an async read from the persister