You’re comparing apples to oranges. Yes, at a high level both
apollo-client provide a way for you to manage global application state. However,
redux allows you to create a predictable state container that changes in response to the actions you define. That means
- Predictability. Reducers are pure functions — given the same state and actions, a reducer will always produce the same result.
- Testability. Again, because reducers are just functions, it’s simple to unit test them.
- Scalability. Because redux forces you to organize your code in a specific way, it makes your code more maintainable. Even your as your code base grows, your code is still debuggable and understandable by other developers.
Dan Abromov points out several other benefits:
- Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors.
- Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.
- Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.
- Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD.
- Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps.
- Provide alternative UIs while reusing most of the business logic.
redux comes with a lot of boilerplate. However, both you, your application and your team can potentially reap a lot of benefits from using it beyond just having a way to manage global state. On the other hand, if you don’t see value in the features provided by redux, or don’t think they’re worth the indirection and complexity
redux adds to your code, then don’t use it. If all you need is a way to manage global application state, then you can utilize
apollo-client or some other library or just utilize the Context API and the
useReducer hook to roll your own solution.
Apollo Client’s use of the
@client directive to manage local state is very convenient, especially if you’r already using the library for querying a GraphQL API. Being able to easily decorate query results with derived fields is neat. Being able to utilize the same API for querying your server and querying local state makes for good DX. But
apollo-client cannot replace
redux because at the end of the day the two libraries do very different things for very different reasons.