本地優先：合理把控狀態共享邊界

在 React 應用開發過程中，開發者容易陷入一個認知誤區——過度追求狀態的全局化。許多新手開發者在項目初期就急于引入 Redux、Zustand 或 Jotai 等狀態管理工具，將一些本應屬于組件內部的瑣碎狀態（如簡單的 UI 切換、輸入框內容等）一股腦地塞進全局狀態中。這種做法不僅會使狀態存儲變得臃腫不堪，增加維護的難度，還可能對應用的性能產生負面影響，最終導致整個開發團隊陷入混亂的局面。

實際上，大多數狀態都應該保持本地化。在決定一個狀態應該放置在何處時，開發者需要問自己一個問題：“其他組件是否真的需要知道這個狀態？”如果答案是否定的，那么這個狀態就不應該被納入全局狀態管理，而應該通過 React 提供的?useState、useReducer?或?useRef?等鉤子，將其保存在與之相關的組件內部。

以下是一些適合采用本地狀態管理的場景：

• 表單輸入：例如用戶填寫表單時，各個輸入框的值通常只需要在表單組件內部進行管理，不需要全局共享。
• 模式切換：像暗/亮模式的切換，如果只是在某個局部組件或頁面內生效，就可以作為本地狀態處理。
• 選項卡選擇：在某個組件內部的選項卡切換狀態，一般也無需全局管理。
• 單頁分頁：對于單頁內的分頁邏輯，其狀態同樣適合保持在本地。
• 臨時視圖邏輯：一些只在當前視圖或組件生命周期內有效的臨時狀態，也應該采用本地管理方式。

當然，全局狀態在某些情況下是必不可少的。以下是一些適合使用全局狀態的場景：

• 用戶會話數據：如令牌、角色、用戶信息等，這些數據需要在整個應用的不同頁面和組件之間共享，并且在頁面切換后需要保持持久化。
• 購物車：購物車狀態需要跨頁面和組件進行共享，用戶在不同頁面添加商品到購物車后，其他頁面和組件應該能夠實時獲取到最新的購物車信息。
• 主題設置：例如暗/亮模式的全局設置，需要在應用的各個部分都能訪問和更新。
• 跨模塊的搜索過濾器：當搜索過濾器需要在多個模塊或組件中使用時，將其作為全局狀態管理會更加方便。

在這些情況下，使用 Zustand、Redux Toolkit 或 React Context 等工具會非常有用（關于這些工具的深入探討將在后續部分展開）。

除了使用?useState?和全局狀態管理庫之外，還有其他的狀態范圍管理方式可供選擇：

• React Context：適合用于輕量級的共享狀態管理，例如主題或語言設置等。
• URL 查詢參數：對于一些需要持久化或可分享的狀態，如過濾器、排序或分頁等，可以通過 URL 查詢參數來進行管理。

工具助力：簡化開發流程

在開發過程中，擁有一致的架構比單純記憶規則更容易執行。雖然工具的配置會因個人喜好和項目需求而有所不同，但在項目初期引入以下工具，可以顯著減輕后期的開發負擔：

• ESLint：通過配置導入順序、React 鉤子規則以及檢測未使用變量等功能，幫助開發者規范代碼編寫。
• TypeScript：能夠有效防止層間通信錯誤，提高代碼的健壯性。
• Prettier：統一代碼格式，使代碼風格保持一致。
• Husky + lint-staged：確保在提交代碼之前，代碼質量符合要求。

通過合理選擇狀態管理方式以及引入合適的開發工具，開發者能夠更加高效地構建出可維護的 React 應用。