【ITニュース解説】Your Global Store Is a Junk Drawer. Sort State Into Four Boxes First

アプリケーション開発において、データの状態をどのように管理するかは非常に重要な課題である。特に複雑なアプリケーションでは、この状態管理の方法がアプリケーション全体の品質や開発効率に大きく影響する。多くの場合、アプリケーションの様々なデータ（ユーザー情報、フォームの入力値、UIの表示状態など）を、いわゆる「グローバルストア」と呼ばれる一つの場所にまとめてしまう傾向が見られる。しかし、これは「ジャンクドロワー（ごちゃ混ぜの引き出し）」のように、必要なデータを見つけにくく、管理を困難にしてしまう原因となる。開発経験が豊富なエンジニアであっても、この一つのグローバルストアにすべてを詰め込むアプローチを推奨することがあるが、これは現代のアプリケーション開発においては最善の選択とは言えない。

アプリケーションの状態管理を考える上で最も重要なのは、「多くのデータは、本来アプリケーション開発者が直接管理すべきものではない」という視点を持つことである。例えば、サーバーから取得したデータは、実際にはサーバーのデータベースの一部を一時的に手元に置いているに過ぎない。WebブラウザのURLに含まれる情報も、ページ間の連携や共有のための無料の仕組みとして既に利用できるものである。また、特定の画面要素の開閉状態のようなUIに関するデータは、その要素が使われる場所でのみ存在すれば十分な一時的な変数に過ぎない。この本質的な考え方を理解すれば、状態管理の具体的な手法は自然と見えてくる。つまり、まずはデータをその性質によって分類し、その分類に応じた適切な管理方法やツールを選択することが重要であり、グローバルストアは多くのデータの出発点ではなく、最終的に配置されるべき特定のデータの置き場であると考えるべきである。

具体的には、アプリケーション内のすべてのデータを、その性質に応じて以下の四つのカテゴリ、すなわち「四つの箱」のいずれかに分類する方法が提唱されている。この分類ルールはシンプルで、多くの状態管理の問題を解決する基礎となる。

一つ目の箱は「サーバー状態」である。これは、Web APIなどを通じてサーバーから取得されるデータ全般を指す。例えば、ユーザーリストや商品情報などがこれに該当する。サーバー状態の本質は「キャッシュ」であり、アプリケーションが一時的に保持しているに過ぎない。そのため、開発者がこのデータを手動で更新したり、複雑な管理ロジックを実装したりするべきではない。最新のデータが必要な場合は再度サーバーに問い合わせる、あるいは一定期間は古いデータを使用しつつバックグラウンドで新しいデータを取得する「stale-while-revalidate」（古くなったデータを使いつつ新しいデータを取り直す）のような戦略をサポートする「クエリライブラリ」を利用するのが現代的なアプローチである。手動でサーバーから取得したデータを更新するようなコードを記述することは、ライブラリが提供する便利な機能を適切に活用できていないことを意味する。

二つ目の箱は「URL状態」である。これは、WebページのURLに含まれるクエリパラメータなどに格納されるデータである。例えば、検索結果の絞り込み条件、現在選択されているタブ、ページネーションの現在のページ番号などが該当する。URL状態の大きな利点は、リロードしてもデータが失われず、また特定の状態のページへのリンクを簡単に他の人と共有できる「ディープリンク」の機能を提供する点である。これは、追加のコードを書くことなく得られる無料の機能と考えることができる。もし、アプリケーションの特定のページが、現在の状態を反映したURLで共有できない場合、それは設計上の問題ではなく、バグとして捉えるべきである。

三つ目の箱は「ローカルUI状態」である。これは、アプリケーションの特定の部品（コンポーネント）やその配下でのみ有効で、他の部分とは共有する必要がないデータである。例えば、モーダルウィンドウの開閉状態、ドロップダウンメニューの表示・非表示、フォーム入力の一時的な値などがこれに当たる。これらのデータは、JavaScriptのuseStateフックなどの機能を使って、そのデータを利用するコンポーネントの内部で直接管理するのが最も適切である。わざわざグローバルストアに「何を開くのか不明なisOpenという真偽値」のようなデータを置くことは、そのデータの意味を不明確にし、管理を複雑にするだけである。

四つ目の箱は「永続化状態」である。これは、Webブラウザを閉じたり、アプリケーションをリロードしたりしてもデータが失われずに残っていてほしいデータである。例えば、ユーザーのログインセッション情報、テーマ設定（ダークモードなど）、あるいは一時的に保存しておきたい設定値などがこれに該当する。このようなデータは、Webブラウザが提供するlocalStorageやIndexedDBなどの仕組みを利用して保存する。しかし、永続化状態もまた、過去のセッションのデータという観点からは「キャッシュ」の一種と考えることができる。そのため、アプリケーションが起動したときにデータをどのように読み込むかという初期化処理や、そのデータがいつまで有効であるかという有効期限を適切に設計し、必要に応じて更新または破棄する仕組みを設ける必要がある。

この四つの分類を踏まえた上で、アプリケーション開発における決定ルールは非常にシンプルである。もし、あるデータがこれら四つの箱のいずれに属するのか明確に判断できない場合、そのデータはまだグローバルストアに入れるべきではない。この一つのルールを徹底するだけで、アプリケーションの状態管理における肥大化の約80%は未然に防ぐことができると言われている。

では、残りの20%のデータはどこに置くのか。それが、真にグローバルストアに置かれるべきデータである。これは、サーバーデータでもなく、URLに含めるべきものでもなく、特定のUIコンポーネント内部でのみ有効なものでもなく、単に永続化すれば良いものでもない、本当にアプリケーション全体で共有され、クライアント側でそのライフサイクルを管理すべきデータを指す。このルールを適用してみると、グローバルストアに入れるべきデータの量は驚くほど少ないことに気づくだろう。結果として、アプリケーションのデータ構造は非常に整理され、どこにどのデータがあるのか、どのように扱われるべきなのかが明確になり、開発効率とメンテナンス性が大幅に向上する。

このアプローチは、アプリケーションの設計や面接での質問に対する回答にもそのまま応用できる。つまり、「状態を四つの箱に分類し、適切なツールを後から選ぶ」という基本的な考え方を理解していれば、どんな複雑なアプリケーションの状態管理の課題にも論理的かつ効率的に対処できるのである。