Questions about experimental_createPersister

[hverlin]

I like this new createPersister and seems much more performant than the previous approach.

Some general questions about it:

• Any ideas what will change until it becomes stable?
• Would it be ok to have an official example using IndexedDB like here: v5, createPersister and IndexedDB: absolutely amazing! #6213 (comment) (for example, there was one here)
• Would it be possible to have a built-in way to restore the cache ahead of time (maybe using a filter to only restore important queries), see v5, createPersister and IndexedDB: absolutely amazing! #6213 (comment) or document it?
• Show in documentation how to not use a persister for a given query (e.g. by using persister: undefined)

[frederikhors]

Can you PR? 😆

[hverlin]

Happy to help once I know what can be added to docs vs. in the library

[DamianOsipiuk]

Before we mark it as stable, we need a confirmation that it works as it should and that there are no gaps in the functionality.

So far we have identified following gaps, that might change the interface:

• setQueryData does not store new data in persister
• getQueryData/getQueriesData does not attempt to read the data from persister since it's a synchronous function, while persister might be async
• there is no way to restore persisted queries ahead of time to avoid initial hard loading state
• no mutation support (it will probably end up as createQueryPersister and createMutationPersister)

[hverlin]

Thanks!

setQueryData does not store new data in persister
getQueryData/getQueriesData does not attempt to read the data from persister since it's a synchronous function, while persister might be async

What do you think is the solution here?
These functions will need to stay synchronous so would it make sense to have a new async functions if you want it from the async store (indexedDB)? Or indicate that you need to manually restore the cache before calling these functions?

there is no way to restore persisted queries ahead of time to avoid initial hard loading state

I think having a function like I shared to fully or partially restore the cache would be great. Otherwise documenting a workaround might be good enough for most applications?

no mutation support (it will probably end up as createQueryPersister and createMutationPersister)

👍

Would it also make sense to have native/ official support for indexedDB? I feel that for web applications, it might be a better default choice vs. local storage (https://caniuse.com/indexeddb)

[TkDodo]

we're discussing on this issue:

• setQueryData() should be persisted too, right? #6310

[mleister97]

@DamianOsipiuk @TkDodo Any updates for the listed gaps?

[DamianOsipiuk]

There is an in-progress MR that breaks down the code to smaller more reusable utils - #8062

It still needs some tests and docs update, but it should be easier to achieve the desired functionality in user-land.

I do not think there is an agreement on plugging it in directly to the core, so maybe some kind of setup function that would patch QueryClient might be an option.

[mleister97]

Hi everyone,

First of all, I want to express my gratitude for the new feature, the Persister. It’s incredibly useful, and I appreciate all the hard work that went into developing it.

I also wanted to ask if there’s a way to track the current status of this feature. Is there a place where updates or progress can be followed?

Thanks again for this fantastic addition!

[galangel]

We are holding back because it is still experimental,
Is there a plan to include it in the next release?