【譯】爲 REST API 建立可複用的 React Query 組件

原文地址: medium.com/@TimKolb/cr…
譯文地址：github.com/xiao-T/note…
本文版權歸原做者全部，翻譯僅用於學習。

---

每次實現一個新的 UI 組件時，我都是先實現佈局，而後，mock 數據用於 defaultProps，並提供一個空的點擊監聽模擬用戶交互。而後，用真實的數據替換掉 mock 的函數和 props。

爲了實現那些須要從服務端獲取數據數據的組件，我一次次的重複着相同的操做。使用和配置 HTTP headers，反序列化邏輯、處理成功或者失敗的回調、loading 狀態等等，這就致使了代碼的重複。

通訊邏輯讓可複用的組件來處理，是否是更好呢？

💪 開始

React 應用中那些須要使用 API 的組件須要處理大量的問題。針對每一個請求，你都須要處理 loading、錯誤和成功的狀態。

把全部的功能整合到現有的組件中勢必增長組件的複雜度，這並不符合 React 組件化思想。

計算機科學再也不是新鮮事物，咱們也發現了一些舊時代的規則和工具。其中之一就是：分離。

編寫程序只作一件事情並作好 — Doug McIlroy

咱們把 Unix 管道發明者的這個理念引入到 React 組件中，React 的組件表明着 Unix 系統中的程序。經過 props 控制組件的行爲，實現萬能的組件。JavaScript 中通用的類型就是函數 — 這就引出了複合組件。

🔌 經過複合組件提供可複用的功能

複合組件模式是由 Kent C. Dodds 提出並推廣的。除了一物理念以外的另一種設計理念：控制權倒置，將非核心的功能轉移到另一個組件。

使用 Query 組件能夠經過 URL 獲取數據 — 這是基本功能。根據查詢結果，使用者有權決定如何渲染 jsx 元素。Query 組件不會與任何組件、任何 URL 或者其它預設屬性耦合。

無論在什麼地方使用，它徹底能夠定製。你能夠提供一個自定義的反序例化函數來處理不一樣的響應類型，好比：json、 text 或者 xml，而後，檢查響應狀態，並在適當的位置改變默認行爲。基於響應結果，state reducer 可讓你攔截狀態的更新狀況來改變 Query 組件的行爲。

Query 組件是一個複合組件，另外提供一個 React Context Provider 來包裝子組件。這有利於複合組件的使用。咱們來看看具體的操做：

若是，你深刻了解過 GraphQL，你應該看到過由 react-apollo 提供的 Query、Mutation 和 Subscription 組件。這些組件提供了簡潔明瞭的 API，以便在 React 組件中整合服務端的通訊邏輯，甚至，使用 apollo-link-rest 能夠處理 REST APIs。我很是喜歡這種良好的編碼體驗。可是，有些狀況下，你並不但願使用這些依賴庫。所以，咱們能夠嘗試爲咱們的 REST API 建立相似的方案。

咱們先來看看一個 Query 組件會傳入哪些額外的信息以便子組件使用，好比：loading 和請求的錯誤狀態。

⚙️ 自定義

Query 組件基本上就是一個組件，只是它提供了 fetch 的功能。React 應用中任何須要從服務器獲取數據的地方均可以使用它，這樣也保證了代碼的可讀性。

服務器通訊並非只有 GET 請求。有時，用戶交互也會觸發請求，以便建立、更新或者刪除一個實體。

根據用戶交互咱們能夠改變 Query 組件的行爲。好比，咱們能夠改變每一個 fetch 的選項，以便處理不一樣的 HTTP 方法，好比：POST、DELETE 或者改變 URL。

🛍 外賣

在組件中整合服務器通訊代碼會讓你的代碼變得混亂。把重複的請求邏輯提取到一個複合組件中，能夠提升應用中代碼的複用率。這種模式可讓你的代碼 DRY，並利用基於組件的 React 方法和關注點的分離核心思想。

✍️ CodeSandbox 演示

Queyr Component Demo

👋 你們好！我是 Tim Kolberger。我是一名全棧 web 開發者，在德國，達姆施塔特的 Incloud 公司工做。我喜歡 React、GraphQL 和 JavaScript。