你在比较苹果和橙子。是的，在较高的水平都redux并apollo-client为您提供了管理全球应用程序状态的方式。但是，redux允许您创建一个可预测的状态容器，该容器会根据您定义的操作进行更改。这意味着redux提供：

• 可预测性。Reducer 是纯函数——给定相同的状态和动作，reducer 将始终产生相同的结果。
• 可测试性。同样，因为reducer 只是函数，所以对它们进行单元测试很简单。
• 可扩展性。因为 redux 强制您以特定方式组织代码，所以它使您的代码更易于维护。即使随着代码库的增长，您的代码仍然可以被其他开发人员调试和理解。

Dan Abromov 指出了其他几个好处：

• 序列化用户操作并将它们与状态快照一起附加到自动错误报告中，以便产品开发人员可以重放它们以重现错误。
• 通过网络传递动作对象以实现协作环境，而无需对代码的编写方式进行重大更改。
• 维护撤消历史记录或实现乐观突变，而无需对代码的编写方式进行重大更改。
• 在开发中的状态历史之间穿梭，并在代码更改时从动作历史中重新评估当前状态，即 TDD。
• 为开发工具提供完整的检查和控制功能，以便产品开发人员可以为其应用程序构建自定义工具。
• 在重用大部分业务逻辑的同时提供替代 UI。

是的，redux带有很多样板。但是，您、您的应用程序和您的团队都可以从使用它中获得很多好处，而不仅仅是拥有一种管理全局状态的方法。另一方面，如果您没有看到 redux 提供的功能的value，或者认为它们不值得redux为您的代码增加间接性和复杂性，那么请不要使用它。如果您只需要一种管理全局应用程序状态的方法，那么您可以利用apollo-client或其他一些库，或者仅利用 Context API 和useReducer钩子来推出您自己的解决方案。

Apollo Client 使用该@client指令来管理本地状态非常方便，特别是如果您已经使用该库来查询 GraphQL API。能够轻松地使用派生字段装饰查询结果是很整洁的。能够使用相同的 API 来查询您的服务器和查询本地状态是一个很好的 DX。但是apollo-client不能替换， redux因为归根结底，这两个库出于非常不同的原因做了非常不同的事情。

我认为您在这里说得很好：“使用 Redux，我们必须根据从副作用收到的响应编写操作、类型和调度操作，并使用 reducer 设置存储中的数据，这由 Apollo Client 自动完成。 ”

对于副作用，Redux 是必要的，而 Apollo 是声明性的。声明性代码通常较短，因为您将逻辑委托给库/框架。

Daniel Rearden 提出了一个很好的观点，即比较 Redux 和 Apollo 客户端缓存就像苹果和橘子。这里的苹果和橘子是不同类型的状态，特别是远程状态和本地状态。不幸的是，Redux 鼓励我们一视同仁地对待所有状态。

对于需要在服务器上检索、更新和变异的状态，我会利用 Apollo 缓存。我会使用更轻量的工具，比如 React 的 Context API 来防止 prop 钻取、全局应用程序状态和业务逻辑的钩子（例如 useReducer/useState）。

棘手的部分是远程状态和本地/全局应用程序状态混合时。所以我会小心地定义围绕它们如何交互的模式

仅当您的后端允许进行 graphql 调用时，迁移到 apollo 才有意义，我们已将我们的项目从 redux 迁移到 apollo，并且结果非常好。

也请阅读此博客，我们正是从此博客决定迁移的