Reactのusereducerとusestateの違い！状態管理の基本

Reactでコンポーネントに状態（state）を持たせる際、非常に使われる二つのフックにuseStateとuseReducerがあります。コードを書くとき、どちらを選ぶべきか迷う方も多いでしょう。この記事では、それぞれの基本的な仕組みと長所短所、使い分けの実際の場面をふんだんに取り上げ、Reactを使う開発者が迷わず最適な選択をできるように解説します。

React usereducer usestate 違いを理解するための基礎

Reactで状態管理をするとき、useStateとuseReducerはそれぞれ異なる特徴を持っています。まずはその土台となる基本的な仕組みと、それがどうReactの状態管理に影響するのかを整理します。両者がどのように動作し、どのような観点で比較されるかを学ぶことで、後の使い分けが明確になります。

useStateとは何か

useStateは、Reactの関数コンポーネントで単純な状態を持つための基本的なフックです。初期値を与え、現在の値とそれを更新するための関数が返されます。更新は直接値を設定するか、あるいは前の状態を引数に取る関数で行うことができます。比較的少ない行数で導入でき、読み手にも処理が直感的に伝わりやすい点が大きな特徴です。

具体例で言えば、ボタンを押すたびに数を増やしたり、入力欄のテキストを管理したりするような場面で非常に有用です。状態が単一で依存関係が少ないケースでは、余計な構造を導入せずに済むため、コードがシンプルになるというメリットがあります。

useReducerとは何か

useReducerは、状態遷移のロジックをreducer関数として分離し、dispatchという関数を通じてアクションを送ることで状態を更新するフックです。reducer関数は現在の状態とアクションを受け取り、次の状態を返す純粋関数でなければなりません。状態の初期値を設定するための引数も取り、複雑な状態や複数の関連する状態を一括で扱うことが得意です。

また、内部でのmutationを避け、新しいオブジェクトや配列を返すことで状態変更を安全に行います。複数の状態が密接に関連していて、一貫した更新ロジックをまとめて管理したい場面で、保守性や予測性が向上します。

共通点と根本的な違い

useStateとuseReducerはいずれもコンポーネントが再レンダリングされるたびに状態を保持し、更新できる仕組みを提供します。Reactはこれらを最適化し、レンダリングのバッチ処理等を行うため、パフォーマンスに関して極端な差が出ることは稀です。

根本的な違いは、状態の更新の**記述場所と方法**にあります。useStateは更新処理を呼び出し元（イベントハンドラなど）に書くことが多く、状態の変化が分散しがちです。一方useReducerは更新の責任をreducer関数に一元化するため、ロジックのテスト性や整理性が高まります。

React usereducer usestate 違い 比較：使い分けの判断基準

実際にプロジェクトでuseStateとuseReducerをどのように使い分けるかを判断するためには、具体的な基準が必要です。ここでは開発者が状態管理の選択時に確認すべきポイントをまとめます。それぞれのケースでどちらがより適しているかが見えてきます。

状態の単純さと複雑さ

状態が単一の値（文字列・数値・真偽値）で、他の状態と依存が薄ければuseStateの方が簡潔です。例えばチェックボックスのオンオフやモーダルの開閉などでは、set関数を呼ぶだけで十分です。

反対に、多数のフィールドを持つフォームや入れ子になったオブジェクト・配列の状態、複数の状態が互いに影響し合うような場合はuseReducerを使うことで状態遷移のロジックを整理できます。このようなケースでは、reducerがあることでコードの一貫性やバグの発生率が下がります。

更新ロジックの複雑さ

更新処理に条件分岐が多数ある・アクションごとに複数の状態を書き換える・前の状態を参照して次の状態を導く必要があるようなロジックがある場合、useReducerの利用が適しています。action.typeによるスイッチ構文でcaseごとに処理を整理できるからです。

逆に更新が非常に単純で、直前の状態を参照することが少ないなら、useStateでsetState関数を使うスタイルの方がコードは読みやすくなります。このように、ロジックの分岐の度合いが判断の鍵となります。

テスト性、再利用性、保守性

useReducerを使う最大の利点の一つはreducer関数の**純粋性**です。副作用を含まず、引数によって出力が決まるので、ユニットテストが非常に書きやすくなります。大規模プロジェクトではこの点が重要です。

また、複数のコンポーネントで同じ状態遷移ロジックを共有したい場合、reducer関数を外部に切り出してimportして使うことが可能です。useStateでは各コンポーネントがそれぞれset関数を持つため、重複が生じやすくなります。

パフォーマンスへの影響

更新ごとに呼び出すset〜関数やdispatch関数の数はパフォーマンスに関係します。useStateを複数使うと各更新が個別に処理されるため、大規模な状態更新や多数の子コンポーネントへのprops伝搬があると再レンダリングが多くなる可能性があります。

useReducerではdispatch関数を使って更新をまとめやすく、重いロジックを外部に出すことでレンダリングに関連する重さをある程度抑えることができます。ただし、過度な最適化はかえってコードを複雑にするため、まずは読みやすさと正確性を優先します。

React usereducer usestate 違い 実践例とコードで比較

ここまで述べてきた理論を踏まえて、実際にコードでどのように使い分けるかを見ていきます。具体例を参照することで、どちらがどの場面で有利かをよりリアルに理解できます。簡単なカウンター、複雑なフォームなどを比較します。

単純なカウンターをuseStateで実装

まずはボタンを押すとカウントが1増えるような非常に基本的なカウンターをuseStateで書く例を考えます。初期カウントとして0を設定し、クリックイベントで値を更新します。

このケースでは
・状態は数値一つ
・更新ロジックは「+1」だけ
・他の状態と依存関係なし
こうした条件ならuseStateの方がコード量が少なく直感的です。性能上の問題も発生しにくいでしょう。

複数の状態を持つフォームをuseStateで管理する例

名前、メール、パスワード、同意チェックボックスといった複数の入力欄を持ち、各フィールドを別々のuseStateで管理する例があります。各入力に対応するset関数を記述し、submit時にまとめて処理します。

この方法は状態の初期化や更新は分かりやすいですが、複数フィールドの相互依存（例えば、パスワード強度や入力の整合性など）が入ると処理が分散して複雑になります。どのフィールドが更新されたか追うのが大変になることがあります。

複雑なフォームや状態をuseReducerで整理する例

複数の入力フィールドがあり、それぞれのバリデーション、エラーメッセージ、入力項目の相互依存があるようなフォームを考えてみて下さい。フォームの状態をオブジェクトとしてまとめ、更新ロジックをreducerに定義します。

例えばaction.typeを「CHANGE_FIELD」「VALIDATE」「RESET」などに分け、それぞれの処理として入力値の更新やエラーチェックの実行などを一箇所に集約します。これにより、イベントハンドラではdispatchのみを呼び、状態遷移の見通しが非常に良くなります。

テスト可能で再利用可能なreducer関数の構造

useReducerを用いると、reducerを外部ファイルに出してユニットテストを書きやすくなります。stateとactionの入力を与えて出力が期待通りになるかをテストできます。この構造は複雑な状態ロジックを持つコンポーネントで特に有効です。

また、dispatch関数をReact Contextと組み合わせて深い階層の子コンポーネントに渡す場合、props drillingを避けることができ、アプリ全体の構造がシンプルになります。こうした実践での利点がuseReducerを選ぶ理由になります。

React usereducer usestate 違い：性能と最適化の視点から

状態管理の選択は読みやすさやメンテナンス性だけでなく性能にも影響します。ここでは最新情報をもとに、パフォーマンスの観点からuseStateとuseReducerの違い、注意すべき点について解説します。

再レンダリングの最小化

useStateを複数使っていると、それぞれの状態の変更が個別に関連する子コンポーネントに影響を与えることがあります。多数のuseState呼び出しは、propsの受け渡しが多くなり、変更検出のコストが上がることがあります。

useReducerでは状態遷移をreducerで一元管理し、dispatchを介して状態を更新します。これにより、状態のまとまりを意識的につくり、必要な再レンダリングの回数を制限できることがあります。深いコンポーネントツリーでも効果を発揮します。

メモ化・コンテキストとの組み合わせ

useReducerをContextと組み合わせて、dispatchとstateをプロバイダーで共有するパターンがあります。このパターンでは子コンポーネントにsetState関数を渡す代わりにdispatchのみを渡せるため、State更新ロジックの重複を避け、コンテキストの更新による再レンダリング制御を工夫できます。

また、必要に応じてReact.memoやuseMemoを使って、子が受け取るpropsが変化しなければレンダリングを飛ばせるように設計することでパフォーマンスの最適化が可能です。特にuseStateで多数の状態を扱っている場合にはこうした最適化が効いてきます。

過度な複雑化のリスク</

ただし、useReducerを使えば必ず良いというわけではありません。actionオブジェクトの定義、スイッチ文などの記述が増えるので、小規模な状態管理には冗長になりがちです。チームメンバーにとって理解の敷居が上がる場面もあります。

また、reducerの中で副作用を扱ってはいけません。外部データ取得やタイマーなどの処理はuseEffectやイベントハンドラで行う必要があります。副作用をreducerに含めると予測できない挙動につながる可能性があります。

React usereducer usestate 違い：最新のベストプラクティスと注意点

Reactの状態管理で近年見られるトレンドやベストプラクティスをもとに、今後のコード設計で役立つポイントをまとめます。最新情報を取り入れ、トラブルを避けていきましょう。

複数のuseStateとuseReducerの混在

多くの開発者は、状態が完全に単純か複雑かで判断するのではなく、必要に応じてuseStateとuseReducerを混在させる設計を採用しています。主に入力のトグルやUI の表示非表示などシンプルなものにはuseState、それ以外のフォームや状態更新ロジックが混み合う部分にはuseReducerを使うという形です。

この組み合わせにより、各部分が過度に重くならず、読みやすさとメンテナンス性のバランスを取ることができます。状態を管理する責任の分割が明確になるので、特に中規模以上のUIでは有効です。

Context APIや外部ストアとの組み合わせ

状態を深い階層の子コンポーネントにも渡したい場合、Context API を使いdispatchだけを流すというパターンがあります。これによりpropsを何重にも渡す必要がなくなり、状態の更新ロジックを中心化できます。

また、外部ストアと組み合わせることでローカル状態とグローバル状態の境界を明確にし、必要な部分だけをuseReducerやContextで制御し、他の部分は専用の状態管理ライブラリを活用する構造が増えています。

型安全性とリスク管理

TypeScriptを使う場合、useReducerではactionの型とstateの形を明確に定義できるので型安全性が高まります。スイッチケースで処理漏れをコンパイル時に検出できるようにする設計が望ましいです。

また、状態の初期値を外部から求める場合にはinit関数を使い、初期化ロジックを分離することが推奨されます。状態を表すオブジェクトを更新する際には浅いコピーを忘れず、新しいオブジェクトを返すことが副作用の予防になります。

React usereducer usestate 違い：表で見る比較

これまでの内容を整理し、useStateとuseReducerの特徴を表形式で比較します。見た目に違いが分かりやすくなるようセルごとに背景色を変えてメリット・デメリットを比較します。

項目	useStateの特徴	useReducerの特徴
状態の単純さ	数値・文字列・真偽値など単独で扱える単純な状態に適する	複数のフィールドを持つオブジェクトや入れ子構造を扱いやすい
更新ロジックの複雑性	単純で少ない分岐の場合に読みやすい	分岐や条件付きロジックが多い処理を整理しやすい
コードの可読性／保守性	簡潔で直感的。チームにとって学習コストが低い	ロジックの一元化・テスト可能性が高い構造をもつ
パフォーマンス	少ない更新で十分なら問題は少ない	レンダリングの最小化や重いロジックの切り出しで有効な場面あり
使い分けの目安	UIのトグル・単一の入力欄・カウンターなどシンプルなもの	フォーム全体・複数の状態が関連・Contextで共有などの状況

React usereducer usestate 違い 注意すべき落とし穴

使い分けが適切であっても、実装時に陥りやすい誤りがあります。最新情報を踏まえて、トラブルが起こる典型例とその予防策を紹介します。これらを知ることで後からの改修コストを減らせます。

reducerでの副作用の扱い

reducerは純粋関数であるべきで、副作用（例えばAPI呼び出し、タイマー設定、ログ記録など）を含めてはいけません。これらはイベントハンドラやuseEffectなどに移すべきです。副作用をreducerに含めると予期せぬタイミングで実行されたり、テスト時に混乱が起きたりする原因になります。

また、状態の更新時にオブジェクトや配列を直接変更することは避け、新しい参照を返すように設計することでReactの再レンダリング機構が正しく動作します。ミューテートによってバグが発生した例は多数報告されています。

actionタイプの増加と可読性の低下

useReducerを使い始めると、アクションタイプが増えてswitch文が長くなっていくことがあります。名前の命名規則を統一する、定数化する、また可能な場合はaction creatorsをつかうなどの工夫が有効です。

さらに、reducer関数をあまり大きくしすぎないようにモジュール分割を検討することも重要です。複数の小さなサブreducerに分け、それらを組み合わせる形にすることで管理しやすさが向上します。

無駄な再レンダリングとdispatchの誤用

dispatchをpropsとして子コンポーネントに渡す際、子が常に再レンダリングされる状況が発生することがあります。特にContextを使う場合は、contextの提供する値が変わるたびに消費側が再描画されるため注意が必要です。

このような場合、React.memoやuseMemoを併用し、propsの浅い比較を活かす設計にすると良いでしょう。またdispatch関数自体は安定しているため、それをキーにしない再レンダリング防止策をとることが可能です。

React usereducer usestate 違い まとめ

useStateとuseReducerはどちらもReactで状態を管理するための強力なツールです。それぞれ得意な領域があり、単純な状態や独立した更新ではuseStateが有効であり、複雑なロジックや複数の状態・関連性がある場面ではuseReducerの方が強力になります。

どちらかを選ぶというよりは、プロジェクトやコンポーネントの性質に合わせて使い分けることが重要です。状態が増えてきたと感じたり、バグが状態管理のせいで発生したりしたら、useReducerへの切り替えを検討すると良いでしょう。

最後に、コードの可読性保守性を常に意識し、純粋な関数設計とテスト可能な構造を設けることが、Reactで書くアプリケーションの品質を上げる鍵となります。