React 狀態管理的另一種思路：用 Singleton Service 優雅解耦 UI 與資料邏輯
React 狀態管理的另一種思路：用 Singleton Service 優雅解耦 UI 與資料邏輯 在開發 React 應用時，狀態管理永遠是核心議題。當應用變得複雜，例如需要一個元件（如 Tree View）的選擇去連動另一個元件（如 List View）的內容時，我們常會陷入 props 逐層傳遞（Prop Drilling）的困境，或是需要引入像 Redux、Zustand 這樣功能強大的狀態管理庫。 然而，對於中等規模的應用，或是在想保持輕量、減少依賴的場景下，有沒有更簡潔、更優雅的作法？ 答案是肯定的。透過結合兩種經典設計模式—— 單例模式（Singleton） 與 觀察者模式（Observer） ——我們可以打造一個獨立於 React 框架的資料服務層，並透過自定義 Hook（Custom Hook）將它與 UI 元件無縫接軌。 本文將帶你一步步實現這個架構，讓你看到一個 UI 與邏輯徹底解耦的清爽世界。 架構設計：三大核心角色 這個模式主要由三個部分組成，各司其職，完美分工： Singleton Service (大腦 🧠) 這是一個純粹的 TypeScript/JavaScript 類別，負責管理應用的核心狀態資料。 單例模式 確保整個應用中只有「一個」資料實例，成為唯一的「真實來源 (Single Source of Truth)」。 它同時扮演「發布者」的角色，提供 subscribe 方法讓外部訂閱資料變更，並在資料異動時（如新增、刪除），透過 notify 方法通知所有「訂閱者」。 Custom Hook (橋樑 🌉) 這是連接「非 React 世界」的 Service 與「React 世界」的 UI 元件之間的關鍵橋樑。 它封裝了訂閱與取消訂閱的生命週期邏輯。在元件掛載時向 Service 註冊，在卸載時自動取消，完美避免了記憶體洩漏。 當 Service 發出變更通知時，這個 Hook 會更新自身的 state，從而觸發使用它的 React 元件進行重新渲染（re-render）。 React Components (演員 🎭) UI 元件變得非常「單純」。它們不再需要自己管理複雜的共享狀態。 只需呼叫自定義 Hook，就能輕鬆取得最新的資料來進行...