在我們團隊使用 Nx 建立新專案後，經過多方考量，我們決定從 Redux 轉向 Zustand 作為我們的狀態管理工具。這個轉變不僅讓開發更輕量、簡單，也讓我們的開發體驗大幅提升。
如果你也正在考慮是否要從 Redux 轉換到 Zustand，這篇文章將會幫助你了解這兩者的差異，以及為什麼我們選擇 Zustand。 官方網站：Zustand 官網
1. 簡單易用，開發效率更高
- Zustand：API 設計簡潔直觀，只需要一個 create 函數就能快速定義狀態與行為，不需要額外學習太多概念。
- Redux：即使有 Redux Toolkit 來簡化流程，仍然需要定義 actions、reducers、action types，對於小型應用來說，這些步驟顯得有些繁瑣。
我們團隊在使用 Zustand 之後，發現開發時間明顯縮短，因為我們不需要再寫一堆樣板代碼來管理狀態。
2. 省去繁瑣的樣板代碼
- Zustand：直接在 store 內定義狀態與變更方法，不需要單獨建立 actions 或 reducers，開發體驗更加直覺。
- Redux：強調單一來源的真理（Single Source of Truth），但代價是需要額外定義 action types 和 reducers，使得程式碼量變多。 如果你的專案需要快速迭代，這些樣板代碼會讓開發變得拖沓，而 Zustand 則讓我們能夠更靈活地管理狀態。
3. 更靈活的狀態管理
- Zustand：允許在不同的地方自由定義和管理狀態，並且可以輕鬆整合到 React 以外的環境。
- Redux：有比較固定的架構，需要嚴格按照 actions -> reducers -> store 的模式來組織邏輯，靈活性相對較低。 這讓 Zustand 特別適合我們這種模組化開發的團隊，我們可以根據不同的模組需求自由管理狀態，而不會受限於 Redux 的架構。
4. 簡單處理副作用（async）
- Zustand：可以直接在 store 內使用 async / await，不需要額外的中間件來處理異步邏輯。
- Redux：通常需要搭配 redux-thunk 或 redux-saga 來處理異步邏輯，這增加了學習門檻與實作的複雜度。 在日常開發中，狀態管理與 API 請求的搭配非常重要，而 Zustand 讓我們的 API 請求邏輯更加直觀，減少了 Redux 中需要額外設定 dispatch 的麻煩。
5. 輕量且功能強大
- Zustand：核心程式碼只有幾 KB，但提供了完整的狀態管理功能，包括懶加載、多 store 支持，以及 React DevTools 整合。
- Redux：相較之下 Redux 體積較大，並且通常還需要搭配 react-redux、redux-toolkit 等額外套件來提升開發體驗。
在我們團隊的實測中，Zustand 的 store 在應用初始化時的載入速度明顯比 Redux 快，這對於效能要求較高的應用來說是個不小的優勢。
6. 更貼近 React 的開發方式
- Zustand：與 React hooks 風格高度契合，可以將狀態管理當作 React 組件的一部分，邏輯清晰簡潔。
- Redux：雖然可以透過 react-redux 來與 React 集成，但它本身是框架無關的狀態管理工具，使用方式與 React hooks 思維不太一致。
*這意味著我們可以在 Zustand 中更直覺地使用 **useStore 來獲取狀態，而不用像 Redux 一樣使用 **useSelector 和 *useDispatch 來間接操作狀態。
如何定義 Zustand store
這裡是一個使用 Zustand 定義 store 的範例：
如何使用 Zustand store
這裡提供一個 Zustand 的使用範例，展示如何在組件中調用：
這個範例展示了如何在 Zustand 中管理 API 請求與狀態變更，並且使用簡單的 setParams 來更新狀態，而無需像 Redux 一樣定義額外的 actions 和 reducers。
總結：我們為什麼選擇 Zustand？
在經過比較後，我們選擇 Zustand 作為我們新專案的狀態管理方案，主要是因為：
✅ 簡單易用，不需要額外學習 Redux 的樣板代碼 ✅ 靈活性高，可以根據專案需求自由管理狀態 ✅ 處理副作用簡單，不用額外安裝中間件 ✅ 輕量高效，比 Redux 更適合我們的應用需求 ✅ 貼近 React 開發模式，與 hooks 的搭配更加自然
當然，這並不代表 Redux 不好。如果你的應用需要更嚴格的狀態管理規範，或是需要大型團隊協作，Redux 依然是很好的選擇。但對於我們這次的新專案來說，Zustand 更符合我們的需求。