3 ms·

Question for Apollo Client users. I've been using Apollo Client. When I add or delete data, I need to update the local store on Apollo. How have you found you

Question for Apollo Client users. I've been using Apollo Client. When I add or delete data, I need to update the local store on Apollo. How have you found your experience using the local store on Apollo versus Redux?

wmdmark 9y ago
The local store in Apollo (at least the current version) is actually Redux (and a good use case for it IMO). In our experience it hasn't been to hard to manage and it's nice that you can still use the Redux DevTools to inspect the state.
- eknkc 9y ago
  I don't think it is anymore, latest version depends on a custom cache implementation which does not seem to be based on redux.
- atom_arranger 9y ago
  I wish that was still the case.
leetbulb 9y ago
Since version 2.0, Apollo Client no longer uses Redux. A large application I am currently working on uses both Redux and Apollo. They are two tools that serve different purposes, Apollo just happens to have built-in state management, an important feature that provides the ability to compose components directly from query HOC's and their children from their fragments. That said, these components inherit their state from Apollo, but many of them also share overall state with Redux. As far as creating and deleting data, I'm assuming you're referring to updating Apollo's cache, primarily collections? My mutation payloads provide the fields necessary to update the cache in a way similar to a re-fetch. When you perform a re-fetch, you're simply updating the cache, so why not just do it in one query -- as the result of your mutation. For example, let's say I have a query that provides a collection and I call a mutation that adds or removes an element. The mutation payload fields will simply re-query that collection, and once Apollo sees that response, it will update its cache accordingly. Apollo's API also provides some very nice methods for fine grain control over its cache. Another important feature that helps update your cache upon change are subscriptions, which of course have plenty of other benefits.

wmdmark 9y ago

The local store in Apollo (at least the current version) is actually Redux (and a good use case for it IMO). In our experience it hasn't been to hard to manage and it's nice that you can still use the Redux DevTools to inspect the state.

eknkc 9y ago
I don't think it is anymore, latest version depends on a custom cache implementation which does not seem to be based on redux.
atom_arranger 9y ago
I wish that was still the case.

leetbulb 9y ago

Since version 2.0, Apollo Client no longer uses Redux. A large application I am currently working on uses both Redux and Apollo. They are two tools that serve different purposes, Apollo just happens to have built-in state management, an important feature that provides the ability to compose components directly from query HOC's and their children from their fragments. That said, these components inherit their state from Apollo, but many of them also share overall state with Redux. As far as creating and deleting data, I'm assuming you're referring to updating Apollo's cache, primarily collections? My mutation payloads provide the fields necessary to update the cache in a way similar to a re-fetch. When you perform a re-fetch, you're simply updating the cache, so why not just do it in one query -- as the result of your mutation. For example, let's say I have a query that provides a collection and I call a mutation that adds or removes an element. The mutation payload fields will simply re-query that collection, and once Apollo sees that response, it will update its cache accordingly. Apollo's API also provides some very nice methods for fine grain control over its cache. Another important feature that helps update your cache upon change are subscriptions, which of course have plenty of other benefits.