我正在尝试从 Redux Store 迁移到使用 Apollo Graphql Client 附带的 Apollo Client Cache。
将 Apollo Client 与其他数据管理解决方案区分开来的关键特性之一是其标准化缓存。只需设置 Apollo 客户端，您就可以获得开箱即用的智能缓存，无需额外配置。
使用 Redux，我们必须根据从副作用接收到的响应编写动作、类型和调度动作，并使用减速器将数据设置在存储中，这由 Apollo 客户端自动完成。
问题：
1) 从 Redux 迁移到 Apollo Client Cache 有什么优势？
2) 在迁移到 Apollo 客户端缓存之前我应该担心什么？
【问题讨论】：
标签： reactjs redux graphql apollo-client react-context
我认为您在这里提出了一个很好的观点：“使用 Redux，我们必须根据从副作用接收到的响应来编写动作、类型和调度动作，并使用减速器将数据设置在存储中，这是由 Apollo 完成的客户端自动。”
对于副作用，Redux 是命令式的，Apollo 是声明式的。声明性代码通常更短，因为您将逻辑委托给库/框架。
Daniel Rearden 提出了一个很好的观点，即比较 Redux 和 Apollo 客户端缓存就像是苹果和橘子。这里的苹果和橙子是不同的状态类型，特别是远程和本地状态。不幸的是，Redux 鼓励我们对所有状态一视同仁。
我会利用 Apollo 缓存来处理需要在服务器上检索、更新和变异的状态。我会使用更轻量级的工具，例如 React 的 Context API 来防止道具钻探、全局应用程序状态和业务逻辑挂钩（例如 useReducer/useState）。
棘手的部分是当远程状态和本地/全局应用程序状态混合时。所以我会小心地定义它们如何交互的模式
【讨论】：
您将苹果与橙子进行比较。是的，redux 和apollo-client 都为您提供了一种管理全局应用程序状态的方法。但是，redux 允许您创建一个可预测的状态容器，该容器会根据您定义的操作进行更改。这意味着redux 提供：
Dan Abromov points out several other benefits:
- 序列化用户操作并将它们与状态快照一起附加到自动错误报告中，以便产品开发人员可以重放它们以重现错误。
- 通过网络传递操作对象以实现协作环境，而无需对代码的编写方式进行重大更改。
- 维护撤消历史记录或实施乐观突变，而无需对代码的编写方式进行重大更改。
- 在开发中的状态历史之间穿梭，并在代码更改时从动作历史中重新评估当前状态，例如 TDD。
- 为开发工具提供全面的检查和控制功能，以便产品开发人员可以为其应用构建自定义工具。
- 在重用大部分业务逻辑的同时提供替代 UI。
是的，redux 带有很多样板文件。但是，您、您的应用程序和您的团队都可以从使用它中获得很多好处，而不仅仅是一种管理全局状态的方法。另一方面，如果您看不到 redux 提供的功能的价值，或者认为它们不值得 redux 为您的代码添加的间接性和复杂性，那么请不要使用它。如果您只需要一种管理全局应用程序状态的方法，那么您可以使用 apollo-client 或其他一些库，或者仅使用 Context API 和 useReducer 挂钩来推出您自己的解决方案。
Apollo 客户端使用 @client 指令来管理本地状态非常方便，特别是如果您已经使用该库来查询 GraphQL API。能够轻松地用派生字段装饰查询结果是很整洁的。能够使用相同的 API 来查询您的服务器和查询本地状态是良好的 DX。但是apollo-client 不能替换 redux，因为归根结底，这两个库出于非常不同的原因做了非常不同的事情。
【讨论】：
apollo-client 不能代替redux。我认为我们可以从基于 redux 的应用程序迁移到基于 apollo-client 的应用程序......所以我不确定你的意见。
仅当您的后端允许进行 graphql 调用时，迁移到 apollo 才有意义，我们已将项目从 redux 迁移到 apollo，并且效果非常好。
也阅读此blog，我们决定迁移此博客
【讨论】：