Redux cache in apollo-client >= 2.x.x

[vankop]

Will you implement official support for cache in Redux store in apollo-client >= 2.x.x?

For example, if I have react-redux app and I want to time travel between data/loading state for debugging or development reasons using cache in memory will make state of my app inconsistent. So, it will be great if redux cache will have official support.

Version

• apollo-client@2.x.x

[Panoplos]

Yes! It is terrible that this was not supported in release of 2.0, as I have several breaks that are hard to track now. Stuff that worked in 1.x now has odd behaviour in 2.0 and no way to see how or what is updated.

[lancygoyal]

Its a much needed feature for react developer's.

[vankop]

@Panoplos Actually you can access cache directly by window.__APOLLO_CLIENT__.cache, in my post I point on much more big problem as app state inconsistency, that makes your app depending on 2 states: redux and apollo cache state

[Panoplos]

@vankop My point was that with Redux you can clearly see what updates/queries happen and when, conveniently seeing past states, etc. This is all lost with memory cache, unless I console.log everything out, which is terrible. Yes, I also agree with you that two app states is a bad idea.

[arendjr]

I too am hoping for an official apollo-cache-redux package. For me, the fact that Apollo used Redux internally was one of the main reasons I adopted it in the first place. I am currently migrating a large codebase towards both Redux and GraphQL and it is easy to see how Apollo was an excellent fit there... but with version 2 no more.

I was even contemplating whether I could create a "bug recording" feature for customers based off Redux' state logging as sometimes they run into issues that are hard to reproduce for us and due to data sensitivity it is sometimes hard for us to get access to their environment for reproducibility purposes. A state logger and serializer with anonymization could provide a way around that which, after sending the log to us with the bug report, could provide us a way to reproduce issues happening "in the wild". But the only way that has a chance of working is when sufficient data is available in the Redux store, and not including the GraphQL cache would certainly be a deal-breaker.

[michaelknoch]

What was the reason to drop redux? Maybe the inmemoryCache is much more performant than the old redux cache was?

[SkReD]

Think this is related to #2484

[Panoplos]

@michaelknoch Documents related to this state that moving away from Redux gives them more "flexibility", but I wonder if it would have been better to discuss with the community before foisting this one on us. :-D It may have also been the case that apps/frameworks that do not utilise redux were keeping adoption down? It certainly is better to have a more abstract interface to a store, but probably would have been a good idea to include the most used implementation...

[jbaxleyiii]

Hey everyone! @jbaxleyiii from the Apollo team here. I'd love address the change from redux and our future plans around this 🤗

note: I'm working on a blog post about this too

Why we moved off of redux

From the very beginning, the call to use redux under the hood was a practical and positioning decision. Most react apps used redux (even in they didn't need to haha) and the excitement / tooling around the project was excellent. Integration was straight forward and it brought some nice features to the early builds which allowed Apollo to build quite a lot very quickly. I am still a HUGE redux fan btw 😉

As the 1.0 line grew, we started seeing less and less usage of redux and more using it as a event dispatcher for other application usage. Since the store as essentially not usable outside of direct apollo usage due to normalization, we weren't using redux to its intended purpose. We also wanted to support other stores (including redux) so the call was made (after discussion in a couple places (for example #1432)) to abstract the store usage into a formal API to allow new possibilities.

The cache API is also designed to make integration pretty easy. @kamilkisiela has already implemented an rxjs cache on top of the inmemory cache for ngrx with Angular. I think something extremely similar would work for redux.

As for the features missing with the move, most can be replicated with other hook points into Apollo but I do admit we didn't get to building all of that out prior to 2.0 going live 😢 I'm truly sorry if it seems like we left redux devs out in the cold that was not the intention at all!

Whats next

I would love for this issue to become a feature spec for what ideal redux integration would look like. Projects like redux-persist should come into play which can be used now, but take more manual wiring. Would everyone comment with what they need with the redux integration and we can work together to build it?

Apollo still does ❤️ redux I promise 👍

[ignivalancy]

@jbaxleyiii i think its best to have apollo-cache-inmemory alternative which should be configureable with redux. for instance apollo-cache-redux.

[maplion]

@jbaxleyiii I think @ignivalancy 's idea would work for me as well. I just need a way to tell Apollo 2.0, "I'd like you to use redux for your local cache and I'm going to use it too -- both outside of your reach and directly with GraphQL."

Here is how I am using Apollo, as an FYI: I am currently utilizing apollo-client 1.9.2 in Angular 5 with the @angular-redux suite (/store, /router, /form) and I let apollo do it's thing and use it when I need it with GraphQL, but then manage all of my local state in redux by applying my own reducers within the combineReducers function. For example:

 export const rootReducer = composeReducers(
    defaultFormReducer(),  // @angular-redux/form
    navigationReducer,
    combineReducers({
        apollo: getClient().reducer() as any,  // apollo-client
        router: routerReducer, // @angular-redux/router
        myStuff: myStuffReducer,  // my own reducer for managing local states
    })
);

I also utilize this with the redux-dev-tools and the console logging tools. It works very well and I am glad to hear you haven't forgotten about us!

[jasonmorita]

https://github.com/apollographql/apollo-client/blob/master/Upgrade.md#immediate-wins

This seemed to me to indicate we would be able to use Redux as a store option.

[maplion]

@jasonmorita I think a closer reading is that it makes the default store faster than their old redux store and they have the "ability to build stores for things like mobx, redux, ng-rx, vuex, and more!", but they haven't done it yet; hence this thread.

[jasonmorita]

@maplion Yeah, I think I was being delusional

[maplion]

@jasonmorita Or hopeful, which was where I was at...

[rportugal]

I have been working on a Redux cache implementation: https://github.com/rportugal/apollo-cache-redux
Would appreciate some testing, hopefully it will solve this issue. Thanks

[billnbell]

@rportugal can you send over an example of using this with nextJS and redux?

[waynelai614]

Any updates?

[gardner]

Any updates?

[n1ru4l]

@waynelai614 @gardner Is https://github.com/rportugal/apollo-cache-redux not enough?