Any developments with experimental_createPersister?

[Jonathan-Walsh-Amey]

Hi,

We've been trying out the fine-grained experimental_createPersister in a mobile app as a way to avoid issues with QueryClientProvider and a persister (on expoFileSystemStorage). We wanted to avoid everything being stored in a single file for the persister, as this seems to be a contributing factor to battery drain issues with our app on mobile devices.

The experimental_createPersister achieves this, and seems to work well. We're grateful for all your efforts in creating it. Unfortunately, the lack of support for mutation persistence means we can't really use it currently. Our users can connect to a server, download tasks, then switch to offline mode so that they can work on those tasks. Later they can go back online and the app will sync their edits back to the server, but with no mutation persistence, whilst offline if they close and reopen the app, the mutations are lost.

setQueryData also doesn't update the persister, but we managed to work around that.

These issues have been discussed previously, like here, here and here but a few months have gone by and we just wondered if there had been any further developments or decisions with the fine-grained persister, particularly regarding mutation persistence?

Thanks.

[scott-so-sh]

setQueryData also doesn't update the persister, but we managed to work around that.

how did you manage to work around that?

[Jonathan-Walsh-Amey]

We use setQueryData, then we separately stringify and write the data to AsyncStorage to persist it.

[DamianOsipiuk]

There are a couple of ideas floating around, like exposing more functions from createPersister that would invoke setQueryData and parsist query in a form of a wrapper. Same goes for getQueryData. And maybe some persisterCleanup function that could be called periodically by the user.

As for mutation persistance i did not explore this too much yet.

You could potentially use experimental_createPersister for queries and use PersistQueryClientProvider for mutations by providing a filter that would exclude all queries from PersistQueryClientProvider for the time being.
This should still improve memory/battery usage significantly as queries are potentially much heavier than persisted mutations.

[James-Whitfield]

Thank you for this suggestion. We are looking for any way to be able to handle larger query and mutation caches sizes effectively (25mb+ query data, 100s of cached offline mutations).