透過 xstate 解決UI 狀態問題

一般寫法進行 UI 狀態管理的困境

1. React useState + useEffect 進行處理會有過多的旗標變數

2. 若狀態過多難以理解當前畫面有多少種狀態

3. 長期下來程式碼混亂、條件多、邏輯散、難以維護

4. 各種參數混雜可讀性很差

介紹 Sstate

XState 是一個狀態機函式庫，基於 狀態圖理論（statecharts），它讓你可以：

• 明確定義應用的「狀態」與「事件」

• 像流程圖一樣組織 UI 邏輯

• 把副作用（像 API 呼叫）放進狀態的生命週期中

• 將複雜邏輯抽象成一個可視化的結構

狀態機是什麼？

簡單來說，狀態機（finite state machine, FSM）是一種模型，定義了一個系統會處在哪些「狀態」，以及「事件」觸發時如何從一個狀態跳到另一個。

例子：一個開關

import { createMachine } from 'xstate';

const toggleMachine = createMachine({
  id: 'toggle',
  initial: 'inactive',
  states: {
    inactive: {
      on: { TOGGLE: 'active' }
    },
    active: {
      on: { TOGGLE: 'inactive' }
    }
  }
});

這個機器有兩個狀態：inactive 和 active。只有一種事件 TOGGLE，在兩者之間來回切換。

使用 XState 的實務場景

你可能會問：這個比 useState 好在哪？答案是當 UI 狀態變得複雜時，XState 幫你：

• 避免條件地獄：不再用大量 if/else 判斷多個旗標（如 isLoading, isError...）

• 將狀態與邏輯集中管理：不讓副作用散落在元件中

• 可視化與測試：狀態圖可以可視化，測試只需驗證狀態轉移正確與否

常見應用：

• 表單送出流程（填寫 → 驗證 → 提交 → 成功/失敗）

• 登入流程（輸入帳號 → 驗證 → 登入成功 / 失敗）

• 多步驟 wizard（step1 → step2 → summary → done）

• Modal/Dialog 狀態控制

• 複雜的 async flow（如 WebSocket、輪詢、多重 API 呼叫）

XState 的優點

• 明確結構：所有狀態與轉移都集中管理

• 可視化：幫助團隊理解流程

• 可預測性：每個狀態只能做該做的事

• 易測試：狀態轉移可獨立測試

• 型別支援好（TypeScript）：防呆效果好

• 包含可視化工具 https://stately.ai/viz