簡單暴力！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 的賊船，那麼但願本系列文章能讓你少採一點坑。