大型 React 專案中 API 層的演進與分層設計
🤞 完整範例：Github Repo │ 👻 Live Demo：點我看 demo 專案被擴充得越來越大時，發現自己埋的坑越來越多。 為了讓示範更清晰，本文先略過 TypeScript。 前期 API 的呼叫方式 前期開發 React 專案時，我習慣將 API 請求統一集中在資料夾 /api 下，由每個 component 單獨呼叫使用。 專案規模擴大後出現的架構問題 隨著專案的規模愈來愈大，功能愈來愈複雜時，同一個 API 在多處被呼叫，我開始碰到以下問題： 每個 component 需各自維護 loading / error / data 等狀態，導致狀態管理分散、代碼冗餘 同一支 API 被多處重複呼叫，導致請求重複，造成不必要的 Network、後端壓力及 UX 延遲 資料 cache 的缺失，不同 component 中拿到的資料內容可能出現不一致，需額外處理 資料轉換邏輯分散，難以維護 錯誤處理容易不一致，難以維護，使用者體驗不穩定 跨 component 的資料共用困難，狀態同步成本高，可能需要不斷地通過 props 傳遞或使用 store ⋯⋯ 架構的重構：API / Service / Hook / Component 因此，我決定重新設計資料存取的架構。將原本由 component 直接呼叫 API 並處理所有相關邏輯的做法，依責任拆分為 API 層、Service 層、Hooks 層與 Component 層。透過職責分離，讓每一層專注於單一責任，進而提升整體的可讀性、可維護性與可擴充性。 ...