大概所有的 React 開發經常會遇到的問題是：
前端同學：後端又改欄位了，我好多地方都用了，我得一個一個改啊？
前端同學：你們幾個後端，都返回的啥啊？一個用駝峰式命名法；一個用下劃線命名法；還有用帕斯卡命名法的；能不能統一一下？
前端同學：怎麼這個介面資料包在 data 裡，另一個介面又包在 list 裡，有毛病啊？
...
後臺 API 返回值和元件數據結構很多時候並不是能很好地匹配。畢竟，前端和後端之間的開發是分開進行的，因此它們的數據結構不匹配是不可避免的。
雖然這也可以透過前端後端之間建立一些接口規範來解決。但很多時候，你又不能保證每個人都能貫徹到位。或者遇到一些比較奇葩的人，而你又是個弱勢的小前端，你也沒法去 battle 啊，那怎麼辦？只能自己動手，豐衣足食了唄。
這時，我們就可以應用名為介面卡（Adapter）的設計模式。介面卡是一種設計模式，它允許我們將某個物件 "適配" 到另一個物件的結構中。
這種設計模式有很多種實現方式。因此，無論你想採用哪種方法，都沒有問題。只要主要目的是接受輸入並在此基礎上產生新的輸出。這樣就可以了！
🤔 問題
假設我們有這樣一個後臺 API 響應：
然後我們就有了這個接受不同 props 的 React 元件。
在此示例中，通知元件接受不同的 props，並期望在 statusText 和 typeText 上使用不同的值。我們如何才能在不對元件或後臺 API 響應進行大量重構的情況下匹配它們呢？
💡 適配
爲了匹配或適配來自後臺 API 響應的 React 元件，我們可以這樣建立介面卡：
然後是通知介面卡：
正如你所看到的，我們現在正在 "調整 "後臺 API 響應，以適應通知元件。
我們還為 FE 新增了一些額外的邏輯對映，如 statusText、typeText。
由於筆者大多數專案中都使用了 react-query 這個服務端狀態管理工具，所以，上面演示的是如何將介面卡與 react-query 結合使用！我們使用 react-query 的 select 方法將原始資料 "適配" 為我們需要的資料。
當然，這並不侷限於 react-query，也可以應用於簡單的獲取 API 呼叫，或者任何你用來從後臺獲取資料的方法！這是一種靈活的處理資料對映的方式，而且不會在元件層面造成太多幹擾。
