Mutations aren't dehydrated when closing tab or navigating away

[PabloRomanH]

So this is my situation: I have an event listener on 'beforeunload' so the frontend can update the backend on the status before the tab is closed (specifically on the time the user spent watching a video). I'm using a mutation to do so.

This works okay when the user is online, as the HTTP call succeeds. However, if the user is offline and the tab is closed or the user navigates away, the HTTP call fails, and the mutation is not dehydrated and persisted, so it's not retried when the user loads the website again, and the mutation is lost.

Is there any way I can get this to work?

[TkDodo]

Are you using the persistQueryClient plugin? If so, paused mutations are also persisted. For that, you need to turn on retries, because only after one failed attempt the query will be paused. This makes sense because if the mutation is still in loading state, there is no way of knowing if it will succeed or not.

When the user comes back to the page, there are a couple of things you need to do:

1. restore the persisted state via the persistQueryClient plugin.
2. call queryClient.resumePausedMutations() if you want to resume them. This must happen after restoring, but restoring is async.
3. you need to use a defaultMutationFn for mutations that need to be restored. That is because the mutationFn itself cannot be persisted, and the mutation doesn't really exist if we want to resume it that way. So to decide how to actually do the mutation, we need a mutateFn , and the defaults are the best way for that.

1. is straight forward. 2) is possible but not so easy because we don't return the promise from the restore function. This will get better in v4 where we have a different approach with a dedicated Provider. 3) is a caveat we have to live with I believe, but it needs proper documentation.

I plan on updating the docs for v4 and also include an example.

[PabloRomanH]

Are there any examples using IndexedDB? I'm working off of the example in this thread: #1638

From what I can tell, I'm already doing 2 and 3, but I'm not doing it through persistQueryClient but rather directly calling dehydrate and hydrate like in the example I linked to. Will the persistQueryClient do something differently?

[TkDodo]

Will the persistQueryClient do something differently?

reading from indexDB is async, so you have to make sure that rendering your component waits until hydration is finished, or you might get into weird race conditions.

Also, the peristQueryClient subscribes you to change and syncs them back to the storage. If you only dehydrate, you can load from the storage, but you also need to write back to it. Have a look at the IndexDB Persister proposal, where we have basically concluded that the AsyncStoragePersister should be usable for IndexDB as well.

In v4, we'll ship a PersistQueryClientProvider that should address both issues.