Is there a way to have an offline mode? requests queue?

[Victorien-T]

Hi, I'm working on a React Native app that needs to work offline and I'm looking for the best way to handle data fetching.

react-query seems to address a lot of problems I have encountered with redux based apps but I don't find how I could handle an offline mode?

What I'm trying to achieve is performing an optimistic update if offline and send the requests as soon as mobile reach network again.

Is it something I could do with react-query?

Thanks for your help!

[flipace]

I'm also interested in this. We currently use a very customized setup of redux + redux offline in combination with apollo client in order to achieve this. Does react query have any offline concept at all (eg mutations should only run in sequence when back online) or just "retry" whem failed?

[bogdan2510]

Also super interested in this use case. Maybe some overview example on how this can be archived in the best way possible using RQ alone or with some other tool. 💯 .
We plan to create a react native app that needs to be offline first and we are considering to use RQ. The issue is that until now we don't have a birds eye view on how to do it in RQ context.

[boschni]

V3 has support for offline queries and mutations: https://react-query-beta.tanstack.com/

[timothykrell-hb]

I don't see where in the beta docs it talks about this. Is it documented yet?

[TkDodo]

https://react-query-beta.tanstack.com/guides/migrating-to-react-query-3#retryoffline-mutations

[andrekovac]

This looks nice but still involves quite a few manual steps, e.g. checking the network whether the device is online/offline, dehydrating the client when offline etc. which I'd love to work out of the box

[kokoskiwi]

@andrekovac what do you use for this use case at the moment? or does reactquery already support that now?

[andrekovac]

@kokoskiwi I looked into react-query because I wanted to use it and investigating offline behavior was part of my proof-of-concept. I eventually settled for redux and redux-persist which automatically hydrates the store for me as soon as I'm back online.

[sakhmedbayev]

can anyone from the core dev team of react-query tell us what are your plans for offline support?

[PymZoR]

Also super interested in this. I have an offline-first cordova app, and the main issue preventing to use react-query is the handling of app craches. The hydrate/dehydrate API implies to know when to dehydrate in order to persist, where it would be far more convenient to maintain a persisted state in localForage / indexedDB (where storage is not limited to 5mb) during all the app lifecycle.

[TkDodo]

Have you seen the persistQueryClient plugin: https://react-query.tanstack.com/plugins/persistQueryClient

There is one example for localStorage, but you can write your own offline persistor to use any storage you like

[maksnester]

you can write your own offline persistor to use any storage you like

#1638 written here for indexeddb btw

[redbar0n]

Presuming you use GraphQL, then urql/graphcache or the Offix DataStore (forked from Apollo Client, and works similarly to AWS Amplify DataStore but without the cruft) currently looks like the best options. Offline turns out to be quite a bit more complex than people originally suspect (due to conflict resolution which requires server compatibility/strategies):

The Apollo Client caches GraphQL data and queries to provide state management and reduce the number of queries sent to the server. This begins to break down when the app goes offline and you need to make changes to the data.

This is where the Offix comes in. When the application goes offline, Offix schedules the mutations and adds them to an offline queue. The scheduler generates a client ID and an optimistic response is added to the optimistic layer of the cache. When the app comes back online, Offix handles the conflict resolutions and swaps out the client generated IDs for the server generated ones. All the optimistic responses are replaced with the actual data and the result is that none of the data that was created when the app went offline is lost.

https://gianlucazuccarelli.medium.com/offix-2-0-de59409b16d2

[TkDodo]

can anyone from the core dev team of react-query tell us what are your plans for offline support?

I'm happy to say that proper online / offline support will be one of the flagship features for v4, which I'm currently working on. please have a look at my api proposal in this issue:

• Clarify online support #2927 (comment)

I'm happy to take further input directly on the issue, if there are any cases that you think that I've missed. I have a draft PR already:

• 2927 offline queries #3006

but it's not too late to change the api, especially in terms of naming etc.

This looks nice but still involves quite a few manual steps, e.g. checking the network whether the device is online/offline, dehydrating the client when offline etc. which I'd love to work out of the box

regarding mutations, I don't have much changes planned for retry / offline mutations. The persist plugins will be come "stable" in v4, so we'll remove the "experimental" in the name, and it will then be the best way to achieve that functionality. I don't think there are many manual steps you need to do. You can dehydrate the client independent of if you are online or offline as only paused mutations will be persisted. If you need to check if you are online or not, you can use the exported onlineManager.isOnline() to do so. Persisting is opt-in so you'd always need to do it for yourself I think :)

[VividLiu]

I am also interested in offline mode in React-Query, can we have a rough idea when v4 is going to be released? I am evaluating if we should use React-Query for offline support or go for some other solution if the release is not going to happen in near future.

[TkDodo]

v4 alpha is already released - have you tried it out yet?

[VividLiu]

Thanks. Will try.

[AdlerJS]

Leaving this question here: Has anyone solved persisting mutations across hard reloads (closing the browser tab or the native application) by using something like indexDB. The current implementation for firing paused mutations when coming back online via resumePausedMutations works great when the user doesn't close the application / browser tab, but when you dehydrate then hydrate the mutations stored in indexDB when they get fired off a no mutationFn error occurs

[TkDodo]

but when you dehydrate then hydrate the mutations stored in indexDB when they get fired off a no mutationFn error occurs

It's a known caveat that we need to document better in v4. The mutationFn cannot be serialized because it is a function. When you re-open the application, the mutation doesn't exist anymore - only what we restore from indexDB. Also, the actual useMutation call might be in a component that is now not even mounted.

To work around this, you have to use a default mutateFn. This can best be done with queryClient.setMutationDefaults, where you can set a default per key:

queryClient.setMutationDefaults(['my-mutation'], variables => axios.post('/update-todos', variables)

then, you can just use:

useMutation({ mutationKey: ['my-mutation'] })

the defaults will also be picked up when continuing mutations from a restore.