Paused Queries/Mutations are not persisted

[KamyarP]

Describe the bug

I'm fairly new to React query and first of all I want to appreciate sharing such a cool library with the community.
I'm trying to make use of new offline capabilities introduced in v4. I'm facing some problems regarding queries/mutations' dehydration in localStorage which is reproduced here. If I set my connection to offline (using React query's built-in offline toggle), I expect the queries/mutations that are now in paused state to be persisted in local storage so I'll not lose them the user closes the window and then goes online. But in my code, the localStorage item is not created at all.

I tried updating an official demo to use the latest version of react query. The result is available here. This time the localStorage is created but is not populated with paused queries when I go offline.

• Regarding my first case, the localStorage item is not even created. I suspect the storage is initialised only when useQuery is involved and in my sample, I only used mutations.
• in my second sample, I believe the correct behaviour should be to have the paused queries in localStorage with a maximum of 1 second delay (based on what I read about createWebStoragePersister).

I have tried to use <PersistQueryClientProvider> as well as persistQueryClient method with <QueryClientProvider>. Both led to the same result.

Of course, this might not be a bug and I might have misconfigured the library and in that case, I'd greatly appreciate if you let me know about the correct way.

Your minimal, reproducible example

https://codesandbox.io/s/usemutation-demo-forked-fluu13

Steps to reproduce

• Open the sample
• Go offline using react query's dev tools toggle
• Make a query/mutation and watch REACT_QUERY_OFFLINE_CACHE localStorage changes

Expected behavior

When using createWebStoragePersister as the persister, React Query should dehydrate mutations/queries in paused state every 1 second.

How often does this bug happen?

No response

Screenshots or Videos

No response

Platform

• OS: macOS
• Browser: Chrome
• Version: 99.0.4844.83

react-query version

4.0.0-alpha.23

TypeScript version

4.1.3

Additional context

No response

[TkDodo]

Thank you for the feedback. There seems to be a slight misimplemention internally with persistQueryClient - it only subscribes to the queryCache, but it stores the whole client. I think we would have to subscribe to the mutationCache as well. However, it should work as soon as you add a useQuery call to any page, as that sets up the subscription. I think we should fix this internally though.

apart from that, for mutations to be resume-able, you need to use a defaultMutationFunction. This is a known limitation which I still need to document better: Your useMutation call is likely not mounted if you reload the page, so there is no mutationFn to resume. Using a default fixes that.

I have made an example for v4, it should be here: https://react-query-alpha.tanstack.com/examples/offline, but I think I messed up some imports so it's not working. I'll take a look at it asap.

[TkDodo]

this fork should be working now: https://clzyj4.csb.app/

also, per default, only successful queries will be included in storing. This means that if a query never had data, and is paused e.g. because of that, it will not be stored, as it doesn't make much sense, as there is nothing to store actually :) But that can be customized by passing dehydrateOptions.

[tannerlinsley]

🎉 This issue has been resolved in version 4.0.0-alpha.24 🎉

The release is available on:

• npm package (@alpha dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[tannerlinsley]

🎉 This issue has been resolved in version 4.0.0-beta.1 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[KamyarP]

Thanks for the lightning fast reply and fix! I'd say you react faster to feedbacks than many enterprise softwares.

Regarding defaultMutationFunction, it's a common scenario in medium/large solutions to have different modules that handle mutation hydration and one default mutation implementation at the start does not do the trick. Also, those modules might not be initialised at application startup.

Is there any resource/guide that can introduce some best practices on how to dispatch the dehydrated mutations to their appropriate modules?

[TkDodo]

You're welcome 😊

Is there any resource/guide that can introduce some best practices on how to dispatch the dehydrated mutations to their appropriate modules?

Not sure I understand the question. The problem is that mutations behave differently from queries, because the observer is only created when you call .mutate. For queries, hydration even without query functions is easier because we can just put the data in the cache, and then the observer will "pick it up" whenever the component mounts.

The data for mutations however just lies in the cache after hydration, and the components cannot pick it up / resume it, because a) .mutate is called imperatively and b) even if you'd call it in an effect or so, it would create a new observer, not using your previous variables.

Can you show an example of where a default mutation fn would not work well? My guess would be with many mutations, because you need to define them upfront for each key? We can't even do what we do with queries (inject the key) because we already pass variables to the function, so we can't even use the url for the key or so, as its unavailable in the defaultFn.

At the moment, I don't see a better way than defining defaults per key

[KamyarP]

My guess would be with many mutations, because you need to define them upfront for each key?

Exactly. And each mutation might need different headers/config in their httpClient. I'm thinking about storing those mutations along with the key/variables (e.g. in localStorage) at application startup and picking them up by their specific httpClient once it's ready to do the job.

[amerllica]

The offline example link has been changed to: https://tanstack.com/query/v4/docs/examples/react/offline