はじめに
TalentXフロントエンドエンジニアの中村です。 フロントエンド開発では、UIの状態をどこで管理するかという判断に迷う場面がよくあります。 コンポーネントの state、URL など、技術的にはどれを選んでも成立するケースも多く、「明確な正解がない」と感じることも少なくありません。
本記事は、状態管理に関する一般的なベストプラクティスをまとめるものではなく、 あくまで自分自身が実務の中で判断するときに、どのような観点で考えているかを整理したものです。 同じ状況でも、チームやプロダクトによって判断は変わり得る、という前提で読んでもらえればと思います。
UIの状態にはいくつかの捉え方がある
状態管理を考えるとき、まず意識しているのは 「どの技術を使うか」ではなく、「その状態をどう捉えるか」です。
自分の場合、次のような問いを立てて整理することが多いです。
- この状態は、画面を再訪したときにも同じであるべきか？
- 一時的な操作の途中経過か、それとも画面を説明する情報か？
- ユーザーにとって意味のある状態か、実装上の都合か？
こうした問いを通して、 「この状態は画面の一部なのか、それとも操作の副産物なのか」 を言語化するようにしています。
// 一時的な操作の状態の例（画面を再訪して再現する必要がないもの） const [isOpen, setIsOpen] = useState(false); const [inputValue, setInputValue] = useState('');
状態をどこで管理するかを考えるときの観点
状態の捉え方がある程度整理できたら、 次に「どこで管理するのが自然そうか」を考えます。
判断するときに、自分がよく意識しているのは次のような点です。
- URLとして表現したとき、意味が伝わりそうか？
- 再読み込みや直リンクで再現されてほしい状態か？
- 将来、仕様が追加されたときに影響範囲が広がりそうか？
- この画面だけ例外的な実装にならないか？
どれも絶対的な基準ではありませんが、 「あとから説明しやすいかどうか」は特に重視しています。
// URLとして意味を持つ状態の例 const [searchParams, setSearchParams] = useSearchParams(); const keyword = searchParams.get('keyword');
具体例：検索条件・検索結果をどう考えるか
考え方を具体化するために、検索画面を例にしてみます。
検索条件や検索結果は、 まとめて「検索状態」として扱いたくなることがありますが、 自分は一度立ち止まって、次のように考えるようにしています。
- 検索条件は、画面を表す情報と言えそうか？
- 検索結果は、再訪時にも同じである必要があるか？
- URLとして共有されると嬉しいのはどちらか？
状況によっては、
- 検索条件は保持する
- 検索結果は毎回取得する
といった切り分けの方が自然に感じるケースもあります。
ここでも重要なのは、 「どの方法が正しいか」ではなく、 その画面にとってどうあるのが分かりやすいかだと思っています。
状態を「保持しない」という選択について
状態管理というと、「どう保持するか」に目が向きがちですが、 あえて保持しないという判断をすることもあります。
例えば、
- 常に最新の情報を表示したい場合
- 一時的な操作フローの途中でしか意味を持たない場合
- URLとして表現する価値があまりない場合
こうしたケースでは、 状態を無理に持たせない方が、結果的にシンプルになることもあります。
これは「何も考えていない」わけではなく、 不要な責務を持たせないための選択だと捉えています。
設計段階で意識していること
ここまで書いてきた内容は、 あくまで個人が判断するときの整理方法です。
ただ、
- 後から仕様が変わったときに破綻しにくいか
- 新しく入った人が読んで理解しやすいか
- 「なぜこうなっているか」を言語化できるか
といった点を意識することで、 状態管理を「実装の話」ではなく「設計の話」として考えやすくなった感覚はあります。
まとめ
UIの状態管理について、 自分は次のように考えています。
- 技術的に可能かどうかよりも、その状態が何を表しているか
- その状態がどこに存在するのが自然か
を先に考える。
本記事で書いた内容は、あくまで一つの考え方にすぎませんが、 状態管理に迷ったときの整理の仕方として、 何か一つでも参考になれば嬉しいです。
最後に
現在、TalentXでは一緒に働く仲間を募集しております。
talentx.brandmedia.i-myrefer.jp
カジュアル面談も行っておりますので、ぜひご応募ください！
