Apollo客户端缓存与Redux

Question

我正在尝试从 Redux Store 迁移，以使用Apollo Graphql Client随附的 Apollo Client Cache 。

使Apollo Client与其他数据管理解决方案区分开的关键功能之一是其标准化缓存。只需设置Apollo客户端，便可以立即使用智能缓存，而无需进行其他配置。

使用Redux，我们必须根据从副作用收到的响应来编写动作，类型和调度动作，并使用reducers设置存储中的数据，这是由Apollo Client自动完成的。

问题：

1）从Redux迁移到Apollo Client Cache有什么优势？

2）在迁移到Apollo客户端缓存之前，我有什么需要担心的事情？

Answer 1

您正在将苹果与桔子进行比较。是的，redux和apollo-client都为您提供了一种管理全局应用程序状态的方法。但是，redux允许您创建可预测的状态容器，该容器会根据您定义的操作而更改。这意味着redux提供：

• 可预测性。精简器是纯函数-给定相同的状态和动作，精简器将始终产生相同的结果。
• 可测试性。同样，由于reducer只是函数，因此对它们进行单元测试很简单。
• 可扩展性。因为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，因为在一天结束时，这两个库由于非常不同的原因而做了非常不同的事情。

Answer 2

我认为您在这里提出了一个好要点：“使用Redux，我们必须根据从副作用接收到的响应编写动作，类型和调度动作，并使用reducer设置存储中的数据，这由Apollo完成客户端自动。”

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

---

Daniel Rearden很好地指出，比较Redux和Apollo客户端缓存就像苹果和橘子一样。这里的苹果和橙子是不同的状态类型，特别是远程和 local 状态。不幸的是，Redux鼓励我们将所有状态都一视同仁。

我将利用Apollo缓存来获取需要在服务器上检索，更新和变异的状态。我可以找到更轻便的工具，例如React的Context API，以防止道具钻探，全局应用程序状态和业务逻辑挂钩（例如useReducer / useState）。

棘手的部分是远程状态和本地/全局应用程序状态混合时。因此，我将谨慎定义围绕它们如何相互作用的模式

Answer 3

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

也请阅读此blog，这是我们决定从此博客进行迁移的