为什么我们不能将GraphQL与Redux一起使用

Question

我想知道为什么人们似乎没有使用Redux的GraphQL jus.

我之前从未使用过GraphQL,但我想开始一个新项目,但Apollo和Relay都没有说服我.目前我正在创建一个使用react和redux以及"旧时尚"休息api的应用程序.我喜欢redux的想法,它在一个地方存储关于我的应用程序的整个信息.

而现在,据我所知,Apollo和relay都做了类似的事情,但他们使用单独的存储,在我们混合逻辑和视图甚至更多只是React,这些东西(另一个存储和混合代码)似乎是有点乱.优点是缓存,我是对的吗？

那么为什么我们不能像以前那样只使用普通的rest api发送查询并将数据放到redux存储中(可能会尝试存储有关同步的某些信息以进行优化).

对不起,如果有我错过的东西,我是新来的,我不是专业人士,这就是为什么我问一些人可能有更多的经验,我:)

Answer 1

"当存在大量相互依赖的实体时,存储关于同步以进行优化的某种信息"会成为一个非常难的问题.

此外,构建客户端状态是大型应用程序中的难题.在redux社区中被视为最佳实践的经验法则是,在组件中使用时,在插入和非规范化时,需要规范化并删除redux状态树中的冗余.

像relay和apollo这样的库希望拥有他们管理的状态,这样他们就可以消除这种规范化/非规范化数据的责任,并在很大程度上从最终用户那里管理缓存(尽可能多),同时仍然提供低级别控制何时需要.

这是一个相当复杂的问题,因为不同的组件可能依赖于部分模型,例如.NoteSummary组件可能只需要title和tags领域,NoteDetails组件将需要description与comments过.

如果您自己管理redux状态,则在显示NoteDetails组件时,您必须编写以下代码:

1. 如果redux树中尚未存在Note,请使用graphql查询获取必需的字段.

2. 如果已经存在Note,但并不存在所有必需字段,则为缺少的字段创建graphql查询,然后通过查询graphql server获取它们.

3. 如果已经存在Note并且具有所有必需字段,则只需使用本地版本.

当我们拥有彼此依赖的实体,或涉及实时协作或订阅时,这会变得更加复杂.

GraphQL库试图解决上述所有的在一个非常网络有效的方式.使用react-apollo或relay你的组件可以声明它所需要的东西和底层库,将智能地确定要获取的内容和数量.

这在哲学上类似于编写反应组件的方式:在渲染方法中,您声明最终组件层次结构应该是什么样的(给定当前状态),库(反应)指出要对DOM进行哪些更改.

您应该评估您的用例是否受益于这种网络效率,如果是这样,您是否愿意投入时间投入学习GraphQL及其周围生态系统所需的工作.

如果redux存储和一些ajax调用足以满足您的使用情况,那么它可以是一个更简单的设置.

如果您决定使用GraphQL和Apollo,那么您可能根本不想使用redux.您可以使用apollo-link-state并使用graphql查询和突变管理所有数据(本地或远程).然后从组件的角度来看,无论某些数据是远程数据还是本地数据都无关紧要.

说了上面的,如果你真的想只是与graphql终极版一起使用而不会像接力任何额外的库可以使用阿波罗客户端直接.您可以从组件调度thunk,然后在thunk中,您可以使用Apollo客户端直接创建graphql查询,一旦收到响应,您可以使用另一个操作调度将该数据放入树中的树中.

如果这听起来更复杂,那是因为它就是这样.