Unable to clear persisted queries

[white haven]

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.

[thick hull]

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

@raw canyon 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 🤔

[raw canyon]

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.

[white haven]

As @raw canyon 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.

[thick hull]

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.