React 重構實戰：善用 Custom Hook 封裝邏輯，打造高可讀性的元件架構

前言：為什麼你的元件越寫越肥？

在開發大型 React 專案時，開發者常遇到的挑戰是元件（Component）過度膨脹。原本應專注於 UI 渲染的元件，若塞滿了 API 請求、複雜的資料轉換與定時器邏輯，將導致程式碼難以維護且難以閱讀。

要解決這個問題，最有效的方法就是透過 Custom Hook。它的核心目的在於：抽離可重用的邏輯、降低元件複雜度，並提升程式碼整體的維護性。

一、 什麼是 Custom Hook？

Custom Hook 是以 use 開頭的函式，專門用來封裝 React 的原生 Hook（如 useState, useEffect）或是特定的副作用邏輯。其核心原則是：Custom Hook 不負責畫面渲染（UI），只負責回傳資料與操作函式。

二、 決策標準：什麼時候該抽離邏輯？

並非所有邏輯都必須抽成 Hook，過度抽象反而會增加追蹤程式碼的成本。以下是判斷的準則：

✅ 建議使用的情境：

• 邏輯跨元件重複：避免重複的複製貼上，確保邏輯的一致性。
• 元件行數過多：當單一元件邏輯過於龐大（例如超過 200 行），建議進行功能抽離。
• 副作用過於複雜：當 useEffect 或 useMemo 的相依性過多且難以理解時。
• 可測試性需求：抽離後的 Hook 可以脫離 UI 進行獨立的單元測試。

❌ 不建議使用的情境：

• 單純的 UI 狀態：例如僅在單一元件使用的 Drawer 或 Tab 開關，直接留在元件內部即可。
• 強依賴 DOM 結構：若邏輯與特定的 JSX 結構高度耦合，不建議強行抽出。

三、 實戰案例：好的 Hook 設計

1. 行為邏輯封裝：usePopover

此 Hook 不僅管理開啟狀態，更精確處理了隱藏延遲（delay）與清理計時器（Timer）的生命週期。

• 設計重點：封裝了「滑鼠懸停 → 延遲關閉」的互動流程，讓 UI 元件只需專注於調用，不需管理計時細節。

2. 資料處理專家：useDescriptionData

將 API 獲取資料後的邏輯處理、i18n 多國語系翻譯，以及 useMemo 的效能優化完全隔離。這讓元件能直接獲得乾淨、格式化後的資料，達到邏輯與視圖解耦的目標。

四、 品質紅線：嚴格禁止「上帝 Hook」(God Hook)

為了維持程式碼的可維護性，應避免建立試圖解決單一頁面所有問題的「全功能型」God Hook。

🚫 如何辨識 God Hook？

• 職責過於龐大：同時處理 API 請求、全域狀態管理與複雜的業務資料轉換。
• 內部包含條件分支：Hook 內出現針對特定頁面的判斷（例如 if (isPageA)），這代表該 Hook 已失去通用的「去情境化」特性。
• 回傳屬性過多：一次回傳超過 5-7 個互不相關的屬性（例如同時控制側邊欄、表格與圖表）。

五、 設計原則：單一職責與組合 (Composition)

專業的設計應將邏輯拆解為職責單一的小型 Hooks，並在元件層級進行組合：

1. 數據層：負責獲取 API 原始資料。
2. 轉換層：負責將資料轉換為 UI 所需的配置（如圖表或表格設定）。
3. 功能層：負責處理特定的通用功能（如匯率轉換）。

核心規範：

• 單一職責：一個 Hook 只專注於完成一件事。
• 命名語意化：以 use 開頭，並描述「做什麼」（如 useSelectedStock）而非「怎麼做」（如 useLogic）。

結語

撰寫高品質的 Custom Hook 是一種職業素養的展現。透過將 UI 與複雜邏輯分離，我們不僅能降低 Bug 產生的機率，更能讓專案在長期維護下依然保持靈活與彈性。