概要

状態管理とは「変数に値を持たせること」ではない。
それは**“状態の意味・遷移の可能性・UIの整合性を制御するための構造的制約”**である。

状態が「自由すぎる」ことで、**「ローディング中にボタンが押せる」「エラーなのに結果が表示されている」「完了後に再度送信される」**といった 「状態爆発」 が発生する。

この問題を解決するには、状態を 列挙・制御・可視化可能な構造として設計することが重要である。

1. 状態遷移の定義と「状態爆発」の理解

// NG: 多値フラグによる組み合わせ爆発
const [loading, setLoading] = useState(false);
const [error, setError] = useState(false);
const [completed, setCompleted] = useState(false);

❌ フラグの組み合わせが無限に広がり、UIとの整合性が崩壊

2. 列挙型による状態の一元管理

type FormState = 'idle' | 'loading' | 'error' | 'success';

const [state, setState] = useState<FormState>('idle');

✅ 状態は「意味のある列挙値」で持つ
✅ フロー上の状態遷移図に従った移行のみを許可

3. 遷移を制御するステートマシン的構造

const transition = {
  idle: ['loading'],
  loading: ['success', 'error'],
  error: ['loading'],
  success: [],
};

function canTransition(from: FormState, to: FormState) {
  return transition[from].includes(to);
}

✅ 不正な遷移（例: success → loading）を防ぐ
✅ 状態と遷移を構造として宣言

4. UIは状態ごとのレンダリング責務を分離

switch (state) {
  case 'idle':
    return <SubmitButton />;
  case 'loading':
    return <LoadingIndicator />;
  case 'error':
    return <ErrorBanner onRetry={submitAgain} />;
  case 'success':
    return <ThankYouMessage />;
}

✅ 各状態ごとに UI責務を切り分ける
✅ if-elseや条件フラグではなく、状態 = UI の構造を明示

5. 状態モデルの単位とスコープ設計

- ページ単位（例: 読み込み状態, 完了状態）
- セクション単位（例: 投稿フォーム, 検索結果）
- エンティティ単位（例: 各ユーザーのローディング / フォロー状態）

✅ 状態モデルはスコープごとに設計
✅ 複数コンポーネントに影響を与えるものは store管理やstate machine導入

6. ステートマシンライブラリの導入（例: XState）

import { createMachine } from 'xstate';

const formMachine = createMachine({
  id: 'form',
  initial: 'idle',
  states: {
    idle: { on: { SUBMIT: 'loading' } },
    loading: {
      on: {
        SUCCESS: 'success',
        FAILURE: 'error',
      },
    },
    error: { on: { RETRY: 'loading' } },
    success: {},
  },
});

✅ 宣言的に状態と遷移を定義可能
✅ 実行不能な状態遷移が構造的にブロックされる

設計判断フロー

① 状態は列挙型で表現されているか？ → 多フラグの爆発を防げているか？

② 状態間の遷移が意図的に制御されているか？

③ UIの各部品は状態と責務が1対1で対応しているか？

④ 状態が変更されたとき、他UIに破壊的影響が出ない設計か？

⑤ 状態の定義と遷移ルールがコード上で明示されているか？

よくあるミスと対策

❌ 複数のフラグで状態を表現し、矛盾したUIになる

→ ✅ 状態を列挙型で一本化し、単一の責務を持たせる

❌ 状態遷移が暗黙的で、何が起きているかわからない

→ ✅ ステートマシン or トランジション定義で明示化

❌ UIで「完了後に再送信できてしまう」などの不整合が発生

→ ✅ 遷移元・遷移先の制限を構造的に設計

結語

状態管理とは「状態を持つこと」ではない。
それは**“変化を制御し、流れを制限し、UIと機能の整合性を守るための設計戦略”**である。

状態を列挙型で管理し
遷移を定義し、構造的に制約を与え
UIと状態を1対1で対応させ
ステートマシンを使い、爆発する組み合わせを制御する

JavaScriptにおける状態遷移設計とは、
“UIとロジックの整合性を保証し、複雑性に耐えるアプリの設計基盤”である。