Future Planning: Offline Support?

[grumpyTofu]

Would the project team be interested in adding first class offline support to the roadmap?

Given that RTK is making api integration really simple, could there be room for some enhancements to make redux toolkit ideal for PWAs and other offline activities as well. A few ideas might include:

• absorb redux persist functionality by allowing a "persist" or "rehydrate" property to be specified in createSlice, or list of reducer paths to persist, which if true would auto-save to local storage so data persists across refresh.
• purge listener property for createSlice/store that would allow slice/store to "listen" for specific actions using a matcher (similar to extraReducers) and clear state from local storage (i.e. logout).
• "persistFn" & "rehydrateFn" property on createSlice/store that would allow override of rehydrate functionality for custom hydration and persistence logic (i.e. cloud/db state storage backups).
• Make it easy to prefetch data in createApi meanwhile RTK could store this data in cache/local storage so that if a user goes offline, they could still use the application to an extent.
• built-in use of setupListeners in baseQuery where if client goes offline, save the history of api usage to state/local storage and retry when back online (could also apply to polling and streaming updates).

Several of these items may be entirely possible now or through the use of libraries like redux-persist, but it would be really cool to only use redux-toolkit for it or have sections for how to accomplish these in the docs.

[markerikson]

First reaction would be a tentative "yes", but I'd be very curious to see more technical details as far as API design, implementation details, and effect on the complexity of our types.

[euclides-jr]

I'm looking forward to having offline support, as a starting point the keepUnusedDataFor config parameter could accept Infinity to disable the garbage collection and an option to fetch data on every component subscription. This seems to be simple changes and would not break existing functionality.

[phryneas]

@euclides-jr I'm pretty sure you already can already use Number.MAX_VALUE or some other very large value already. The option to fetch on subscription also exists.

[euclides-jr]

@phryneas Of course, but I guess would be interesting to avoid having a stale setTimeout for each query.

[jsancho]

One option to consider could be to make enough adjustments so that redux-offline can be optionally plugged. Those changes accompanied with some docs with best practices would be ideal.

I'd adventure myself and say main pain points could probably be

• selectors that read from persisted cache when offline and from endpoint when online
• action dispatchers that allow to configure the use the optimistic updates and rollback behaviour

My thinking is that, if possible, it would less work for RTK devs while providing a viable migration path for the redux-offline community.

There are a couple of past issues from folk who seem to have managed to integrate RTK with redux-offline already. https://github.com/reduxjs/redux-toolkit/issues/555 https://github.com/reduxjs/redux-toolkit/issues/583

Redux-offline has been a great help for us in building a react-native app that can perform optimistic updates and buffer the dispatch of endpoint calls until the network is available. It allows a user to keep working as per usual when accessing the application from locations with patchy connectivity, which is very common in our use case.

We've managed to remove an incredible amount of boilerplate from our react web app by migrating to RTK and RTK query. However, in the case of the react-native client, we've not been able to tackle the migration yet due to all the logic handled by redux-offline.

[markerikson]

I think the biggest issue here is that none of us maintainers have any experience working with redux-offline, or offline apps in general. So, we don't know what redux-offline actually does, how offline apps are supposed to behave, or what APIs are needed.

Given that, I honestly don't see us actually implementing this. Any changes here would have to be initiated and contributed by the community.

[jsancho]

That's absolutely fair. We're going to have a go at trying to integrate it, would be happy to contribute whatever we come up with. Whether it's actual code in a PR, issues, or a wiki article to help others along the way.

thanks

[jpcody]

@jsancho Did you all make headway on this? How's your experiment going?

[jsancho]

@jsancho Did you all make headway on this? How's your experiment going?

So far we've managed to integrate RTK alongside redux-offline.

That in itself was a sizeable migration, for the time being the RTK components lack offline support, but that's still something in our roadmap for when we can prioritise it.

[markerikson]

@jsancho Curious to hear the details on what kind of work you had to do!

[jsancho]

@jsancho Curious to hear the details on what kind of work you had to do!

Well, the problem is that we're stretched pretty thin and I am a .NET backend dev who dabbles in js/react when needed. So this kind of low-level redux work goes a bit over my head.

For the time being, we've disabled the offline functionality in the app sections that we've migrated to use RTK. The rest of the app is using vanilla redux boilerplate so we can keep using the offline functionality.

I'm planning to eventually get back at this, but I was probably a bit too ambitious when I started this piece 😅

[rubentlc]

I have already saw that the RTK Query is already detecting if the user goes offline and online.

When the user goes offline, there is at least a way to don't clear the cached queries automatically?

[adbs1]

@jsancho Curious to hear the details on what kind of work you had to do!

Well, the problem is that we're stretched pretty thin and I am a .NET backend dev who dabbles in js/react when needed. So this kind of low-level redux work goes a bit over my head.

For the time being, we've disabled the offline functionality in the app sections that we've migrated to use RTK. The rest of the app is using vanilla redux boilerplate so we can keep using the offline functionality.

I'm planning to eventually get back at this, but I was probably a bit too ambitious when I started this piece 😅

Made any progress there @jsancho?

[jsancho]

Made any progress there @jsancho? Afraid not :/

This is completely out of my coding comfort zone and seeing how redux-offline is largely a stale project, we have moved on from integrating RTK with redux-offline.

Our app is currently a mix of

• handcrafted redux boilerplate in some sections in which we leverage redux-offline.
• some newer sections with RTK but no offline mode.

Eventually we are going to need to have offline functionality for the app as a whole, so we are considering a complete overhaul of how we handle data. For example with AWS AppSync or Firebase Realtime database.

This would probably mean removing redux usage altogether and even changing the backend. So quite a re-platforming effort if you will.

[alexanderblackh]

~~First class support would be great, however, you can get basic usage by simply adding enhancers: [offline(config) as StoreEnhancer] to your configureStore.~~

It kind of works, but isn't the most reliable.

[markerikson]

I don't see anything concrete for us to do here atm, and this issue appears to be stale.

If folks do have specific changes they'd like us to consider making, we can discuss further!