简单暴力!21 分钟学会 apollo-client + redux

apollo-client 是一个比较难用的 GraphQL 客户端,本系列带你集成 redux,趟平深坑,钻入原理,让你在 21 分钟内学完 apollo-client。

NOTE: 阅读过程中如果产生任何不适,请及时拨打 120 自行抢救,谢谢。

本系列的目标:

简单

  • 选型建议(是否值得使用 apollo-client)
  • 搭建 Apollo client 端,集成 redux
  • 使用 apollo-client 来获取数据
  • 修改本地的 apollo store 数据

进阶

  • 提供定制方案

    • 请求拦截
    • 封装修改 client 的 api
  • apollo store 存储细节
  • 写入 store 的失败原因分析和解决方案

前置技能

  • 了解 React + Redux
  • 了解 GraphQL 的基础概念
    对怎么写 Query 等 GraphQL 基础问题不会提及,请查看官方文档Queries and Mutations | GraphQL

限定提示

  • 本方案目前仅使用了 Query 功能,不涉及 Mutation

背景

我司本来采用 RESTful api,但是完全遵循 RESTful 以来,随着业务不断扩展,api endpoint 简直多到爆炸。
对于前端来说,api 太多也难以维护,尤其是设计初期没有提前介入,会导致返回类似的 model,其 Schema 可能不同,这种不一致导致了很多脏代码的产生;
后端也懒于一遍遍地提供类似的接口。

于是,我们就采用了 GraphQL 来解决这个问题。

这里要跟大家明确下我们的项目背景,在采用 GraphQL 前:

  • 后端已经基于 RESTful api 搭建了一套很完善的工作流,GraphQL 必须要与 RESTful 共存
  • 前端基于 Redux + redux-saga + Immutable.js,并做了不少定制化,引入 GraphQL 必须要与之前的数据存储方案不冲突

后来,后端决定只使用 GraphQL 的 query 功能,也就是只 GET,其它 http 动作仍然走 RESTful api。

如果你的项目是全盘采用 GraphQL 的,下面的实践分享可能不适合你,仅供参考。

client 端选型

GraphQL 总体还是比较前后端分离的,不强制你使用某一种 client 方案。从 awesome-graphql 这个库,进入我们视野的主要有两个

  • Relay
  • Apollo

Relay

先说说 Relay。
Relay 是官方出品和推荐的,也是默认的配套方案。文档和解决方案更齐全一点。

我粗略扫了一下 Relay 的文档,从它提供的 api 推测,Relay 不仅仅处理 GraphQL,还接管了状态管理等等,理论上用了 Relay 可以不用 Flux 、Redux 了。
考虑到可能和我们现存的 Redux 方案可能冲突,就放弃了。

Apollo

然后是 Apollo。
Apollo 在 github 上 star 也不少,文档乍看也还不错,除 React 外还适配多个框架。
而且有专门提到和 Redux 集成的章节:Integrating with Redux | Apollo React Docs
时间紧迫,没有想那么多,我就用了(手动捂脸哭)。

事后来看,Apollo 的坑不少。而且最终 Apollo 与其说是和 Redux 集成起来,不如说是隔离开来了,因为 Apollo 也相当于单独维护自己的一个 store。这让我反思是否最初使用 Relay 也会得到同样甚至更好的结果。

不管怎么说,如果你也上了 apollo-client 的贼船,那么希望本系列文章能让你少采一点坑。

相关推荐