Apollo-angular: Deprecating NGRX Cache

[kamilkisiela]

If someone is interested to maintain it, please let me know.
The whole idea behind that package and using ngrx with Apollo in general, makes no sense to me.
If anyone has any objections please comment here.

[ciekawy]

The reason to use ngrx is same as for using any other redux implementation. In particular using ngrx-store with angular-apollomakes sense in case of some part of an app would need to use ngrx/store and to avoid having two different redux implementation in the app (to my understanding that was general idea behind making new apollo client independent on redux implementation).

As for me for now I would like to relay fully on Apollo and hope to have no need to access directly underlying redux implementation.

[kamilkisiela]

What having a normalized cache inside of ngrx gives you? Do you use it inside ngrx as part of selectors? Having one single store that is a single source of truth makes sense only if one data relies on another, if they are totally independent you can have multiple of them.

[ciekawy]

Main reason would be the size of an app and avoid pulling in one more dependency (well set of deps). Also just to minimize amount of dependencies we need to keep up to date.

[wesselvdv]

Also, when you're using ngrx/router-module in combination with apollo graphql that package is rather useful.

[christianrondeau]

I was just exploring this library, here's what I _thought_ the library was doing, maybe that'll be helpful.

Typically, most usages of ngrx store will look something like:

1. Ask to load some data using an action
2. Have an effect do the actual loading, and dispatch an action when the data has been loaded
3. Have a reducer update the store with the loaded data (and more specifically, resolve updating v.s. adding to lists, e.g. using ngrx entity)
4. Use a selector to get the updated data, if it was updated

Since with Apollo and GraphQL it's possible to identify entities, it would be possible to normalize the returned data in a store any time a query is made. Then I can simply use a selector to get it from the "cache". It would remove a lot of boilerplate for most use cases, and for any use cases where the store has more complex logic, the apollo ngrx store would only be used as a cache.

I agree that using ngrx store as a simple cache does not make a lot of sense by itself, but making it easier to update complex models in a store automatically could be very useful, at least in simpler apps.

This however would require "breaking down" the response in separate Entity lists, and to be useful you'd have to map these entities to a type (e.g. using graphql-code-generator). Then it would look something like:

1. Same
2. Same, except my service would use a graphqlquery, AND it would update the apollo store.
3. No reducer required (except if you need to do something fancy, you can alway use the response and do something with it but it's not necessary)
4. Use a selector to get the data (and it could be possible to generate those too for most cases, like "selected entry in a list", "all items in a list", etc.)

Hope that helps!

[kamilkisiela]

If someone wants to take care of apollo-angular-cache-ngrx then feel free to message me, do pull requests, I will merge all of that, right away.

Since I don't use it, I see no point of me maintaining it.

[ceelian]

@kamilkisiela what's your suggested apollo, angular local state management stack?

Just a few thoughts: if you use just apollo client as ngrx replacement, how do you implement effects?

If you use apollo-client and ngrx than you have decent router and effects support but you have to transform the graphql responses into the ngrx store.

Is there any approach I am missing which solves these disadvantages?

[ciekawy]

IMO you should just use apollo for state management. What would be the case where you may need to access store directly?
effect in Apollo are just GraphQL queries/mutations and if you need i.e. access geolocation then you still can do this with @client resolvers

[ceelian]

@ciekawy interesting approach. But isn't the idea of redux/ngrx to separate pure reducers from effects with side effects. With the approach you mentioned, it feels a bit like these two concepts are not clearly separated anymore.

[ciekawy]

Apollo is supposed to fully take over the state management. I moved to Apollo with similar concerns initially and now I am using only Apollo. Biggest benefits for me:

• no more need for verbose boilerplate of reducers and effect. Initially I really liked the concept of redux for state management. Now I love Apollo even more :)
• there are various integrations available for non-graphql data sources @client for anything client-side, @rest for REST endpoints you cannot move to GraphQL, also you can define your own as well.

here you can read more

https://blog.apollographql.com/the-future-of-state-management-dd410864cae2

[ciekawy]

another important value is that Apollo do also data normalization when keeping it in local store

[ceelian]

Thx @ciekawy I will dig into that one more time.

Actually I thought that loonajs will be the solution to fill the gap between the redux approach and apollojs/graphql. But based on the inactivity of the project it seems like that the guild lost its confidence in the loonajs approach as well. I would be really interested what the guild (@kamilkisiela, @urigo,...) is suggesting as best approach.

[onemvictor]

A usecase I have come across is about synchronisation of cache/store. I have a dumb component that emits two events in certain cases on a single browser UI event. The handler for first event mutates the client state, then second handler picks that state and performs server mutation. With ngrx store, the store update by first handler by action dispatch appears synchronous, and the effect for action from second handler gets the updated state. However, with apollo, the client only mutation is not synchronous, possibly because it uses promise api internally. Therefore, the mutation from second handler does not get updated data from cache.

[kamilkisiela]

If someone wants to maintain NGRX cache for Apollo I would be happy to see a fork so I could give an access to the package on npm.