状態管理 | octomblog

フロントエンドの状態管理が複雑になる根本的な原因の一つは、「どこで何を管理するか」の境界が曖昧になることにある。状態を適切に分類すると、UI状態（ドロップダウンの開閉・フォームの入力値等）・アプリケーション状態（ログインユーザーの情報等）・サーバー状態（APIから取得したデータ）・URL状態（検索条件やページ番号）の4種類に整理できる。これらを同一の状態管理ライブラリで一元管理しようとすることが、不必要な複雑さを生む原因になる。

サーバー状態はキャッシュ・再フェッチ・バックグラウンド更新・ローディング/エラー状態の管理という独自のライフサイクルを持つ。React QueryやSWRはこのサーバー状態管理に特化したライブラリであり、APIデータのキャッシュ・stale-while-revalidate戦略・楽観的更新（Optimistic Update）を宣言的に扱える。従来のReduxでAPIデータを管理していたコードの多くは、React Queryに移行することで大幅にシンプル化できる。

ZustandやJotai・Recoilはグローバルなクライアント状態管理に適したライブラリである。ReduxのFluxパターンは予測可能な状態遷移という価値を持つが、アクション・リデューサー・セレクターのボイラープレートが多い。Zustandはこのボイラープレートを大幅に削減しながら同様の予測可能性を提供する。Jotaiはアトム（Atom）単位で状態を定義し、必要なコンポーネントのみが再レンダリングされるきめ細かな最適化が可能である。

コードレビューで着目するポイント

サーバー状態がRedux等のクライアント状態管理ストアに格納されていないか（React QueryやSWRに移行すべき）
グローバル状態が本当にグローバルに必要なものか（コンポーネントのローカル状態で足りないか）
Context APIのProviderが不必要に高い位置に置かれており、関係のないコンポーネントの再レンダリングを引き起こしていないか
状態の正規化が行われているか（同じAPIデータが複数箇所に重複して保持されていないか）
URL状態（フィルター・ページネーション・タブ）がURL（クエリパラメータ等）で管理されているか（ブラウザバックで状態が復元できるか）
楽観的更新（Optimistic Update）を使用している場合、エラー時のロールバック処理が実装されているか

典型的なアンチパターン

サーバー状態をReduxで管理: APIから取得したデータをReduxストアに格納し、ローディング状態・エラー状態・キャッシュ無効化を手動で管理するコードは非常に冗長になる。React Queryが提供するキャッシュ戦略・再フェッチロジックをゼロから再実装することになり、バグも生まれやすい。

Context APIによる頻繁な更新: 高頻度で更新される状態（入力値・アニメーション等）をContextに入れると、Providerの子孫全コンポーネントが毎回再レンダリングされパフォーマンスが劣化する。頻繁に更新される状態はコンポーネントのローカル状態またはZustand等の選択的サブスクリプションができるライブラリで管理すべきである。

フィルター・ページ番号のステート管理: 検索条件やページ番号をuseStateで管理すると、URLを共有してもその状態が再現されず、ブラウザバックでも状態が失われる。このような状態はURLのクエリパラメータで管理することで、共有可能性と履歴管理を無料で得られる。

参考リソース

ツール: TanStack Query（React Query） - サーバー状態管理のデファクトスタンダード
ツール: Zustand - シンプルなAPIのグローバル状態管理ライブラリ
ツール: Jotai - アトムベースの細粒度状態管理ライブラリ
記事: Application State Management with React - Kent C. Doddsによる状態の分類と管理戦略の解説
ツール: Redux Toolkit - Reduxのボイラープレートを削減した公式ツールキット（Reduxが必要な場合の現代的なアプローチ）