为什么我们不能使用GraphQL只是Redux

Question

我想知道为什么人们似乎不使用GraphQL jus与Redux。

我以前从未使用过GraphQL，但我想开始一个新项目，但阿波罗和继电器都不能说服我。目前，我正在创建一个使用react和redux以及“老式”RESTAPI的应用程序。我喜欢redux的想法，它将我的应用程序的全部信息存储在一个地方。

现在，据我所知，阿波罗和中继都做了类似的事情，但它们使用单独的存储，在这两者中，我们混合了逻辑和视图，而不仅仅是反应，这两件事（另一个存储和混合代码）似乎有点混乱。优点是缓存，对吗？

那么，为什么我们不能像以前使用普通的rest api一样发送查询，并将数据放入redux存储（也许可以尝试存储一些关于同步的信息以进行优化）。

对不起，如果我错过了什么，我是新来的，我不是专业人士，这就是为什么我问一些可能比我更有经验的人：）

Answer 1

当您有许多相互依赖的实体时，“存储有关同步的某种[信息]以进行优化”成为一个非常困难的问题。

此外，构造客户端状态在大型应用程序中也是一个难题。在redux社区中，被视为最佳实践的经验法则是，在组件中使用redux状态树时，需要在redux状态树中规范化和删除冗余，并对其进行反规范化。

像relay和apollo这样的库希望拥有它们所管理的状态，以便它们能够从最终用户那里卸下规范化/非规范化数据的责任，并在很大程度上管理缓存（尽可能多），同时在需要时仍然为他们提供低级别的控制。

这是一个相当复杂的问题，因为不同的组件可能依赖于部分模型，例如，notesummmary组件可能只需要title和tags字段，NoteDetails组件也需要description和注释。

如果你自己管理redux状态，你将不得不为以下内容编写代码：

>

如果注释已经存在，但并非所有必填字段都存在，请为缺少的字段创建graphql查询，然后通过查询graphql服务器获取这些字段。

如果注释已经存在，并且包含所有必需字段，则只需使用本地版本。

当我们有相互依赖的实体时，或者当涉及实时协作或订阅时，这会变得更加复杂。

GraphQL库试图以一种非常有效的网络方式解决上述所有问题。使用react-apollo或中继您的组件可以声明它所需要的一切和底层库，将智能地找出要获取的内容和数量。

这与编写react组件的原理类似：在渲染方法中，声明最终组件层次结构的外观（给定当前状态），库（react）确定要对DOM进行哪些更改。

您应该评估您的用例是否从这种网络效率中受益，如果受益，您是否愿意投入时间学习GraphQL及其周围的生态系统。

如果一个redux商店和几个ajax调用足以满足您的用例，那么它可以是一个简单得多的设置。

如果您决定全面使用GraphQL和Apollo，您可能根本不想使用redux。您可以使用apollo链接状态，并使用graphql查询和转换管理所有数据（本地或远程）。然后，从组件的角度来看，某些数据是远程的还是本地的变得无关紧要。

综上所述，如果您真的想只使用redux和graphql，而不使用任何其他库（如Relay），那么您可以直接使用Apollo客户端。您可以从组件中分派Thunk，然后在Thunk中，您可以直接使用Apollo客户端进行graphql查询，一旦收到响应，您可以使用另一个动作分派将该数据放到树中的树中。

如果这听起来更复杂，那是因为它确实如此。