SPAで状態管理ライブラリが必要になった背景 - Web開発における知見共有系ページ

ReduxやVuexのような状態管理ライブラリは、最初に触れると「なぜこんなに大げさな仕組みが必要なのか」と感じがちです。小さな画面ならローカル変数やコンポーネントのstateだけで動きます。

それでも多くのSPAが最終的に状態管理へ進むのは、SPAでは“画面”ではなく“アプリケーション”を作ることになるからです。

この違いが、設計の難しさの正体です。

従来のWebアプリ（MPA）では、ページ遷移のたびにサーバがHTMLを返していました。つまり画面の状態はサーバにありました。

これらはセッションに保存され、ページを開くたびに再描画されます。ブラウザは単なる表示装置です。ページ遷移は「状態のリセット」でもありました。

そのためフロントエンドは複雑な状態管理を必要としませんでした。

SPAではページ遷移がありません。アプリは1ページ上で動き続けます。つまり状態がブラウザに残り続けます。

ここで次の問題が発生します。

例えば商品一覧画面から詳細画面へ移動したあと、戻ったときにスクロール位置や検索条件を維持したい場合があります。これは「画面の状態」が必要です。

つまりSPAでは、サーバが持っていた状態をブラウザが持つようになりました。

ReactやVueでは、UIを小さなコンポーネントに分割します。これは再利用性を高めますが、副作用があります。

親コンポーネントが取得したデータを、深い子コンポーネントへ渡す必要が出ます。

<App>
  <Layout>
    <Sidebar>
      <UserMenu />
    </Sidebar>
  </Layout>
</App>

ログインユーザー情報をUserMenuで表示したい場合、上位からpropsを渡し続けます。これを「props drilling」と呼びます。

コンポーネント階層が深くなるほど、関係ない中間コンポーネントまで修正が必要になります。

さらに難しい問題が起きます。同じデータを複数箇所で保持し始めることです。

どこかで更新したとき、他が更新されない現象が起きます。これが「状態の不整合」です。

SPAのバグの多くは描画処理ではなく、この同期失敗から発生します。

Reduxのようなライブラリは、状態を一箇所に集約します。

dispatch({ type: "USER_UPDATE", payload: user });

これにより、どの画面から更新しても同じデータが反映されます。状態の「唯一の真実の場所（Single Source of Truth）」を作るのが目的です。

小規模アプリでは状態が少なく、問題が顕在化しません。しかし機能が増えると次が起きます。

この段階でローカルstateでは破綻します。後から導入すると大規模改修になります。

Reduxを入れるとコード量は増えます。単純なフォーム中心アプリでは過剰設計になることもあります。

最近はReact Queryのように「サーバ状態」と「UI状態」を分ける考え方も広がっています。すべてをグローバルにする必要はありません。

状態管理はパフォーマンス改善のためではありません。主目的は整合性です。描画速度より、バグの発生率を下げるための仕組みです。

SPAで状態管理ライブラリが必要になる背景は、ページ遷移がなくなったことでアプリケーションが長時間動き続けるようになったためです。状態の寿命が伸び、複数画面で共有されるようになりました。

サーバが担っていた「状態の一元管理」をブラウザ側で再現する仕組みが状態管理ライブラリです。Reduxは複雑さを増やす道具ではなく、複雑さを制御するための枠組みと捉えると理解しやすくなります。