useReducerを使うべきとき、使うべきでないとき

useReducerを使うべきとき

複数の状態が「従属」になっているとき。

useReducerを使うべきでないとき。

複数の状態が「独立」になっているとき。

useReducerを使うべき

• ソート可能なテーブルのソートボタンをクリックした（列をクリックするというのが多いか）とき
  • いまどの列が昇順か？ほかにどの列が対象になっているか？などの複数の状態が「従属」になっているため。
• 都道府県のプルダウンと市区町村のプルダウン。
  • 都道府県を変えたら市区町村の選択をリセットするときは「従属」
  • 都道府県を変えても市区町村の選択は保持され、バリデーションエラーになるだけなら、「独立」
• ビデオプレーヤーの音量バーとミュートボタンの組。
  • これは操作感による。ちょっと短文じゃ簡潔に書けない。
  • 「独立」のつくりでも全然アリ。

useReducerを使うべきでない

• 新規パスワードの入力フォームと、そのパスワードをもう一度入力するフォーム
  • 「関連するから」というような理由では「従属」にはならない。これらは「独立」。
  • 新規パスワードの値を変えたらもう一度入力するフォームを空にする、新規パスワードの値によってもう一度入力するフォームの入力を制限する（そんな馬鹿げたことがあるだろうか）、そういった仕様にして「従属」にすることはできるが、不自然であろう。

「従属」と「独立」の定義をしないと。

イメージ
「独立」＝「結果」が今回の入力だけで決まる
「従属」＝「結果」が以前の入力と今回の入力で決まる

例

「従属」の例。
ソート。名前、年齢、出身地を一覧にしたテーブルがあるとする。それぞれの列をクリックするとその列での昇順・降順が切り替わる。
その場合、名前の列をクリックしたときどういう「結果」になるか、つまり名前の昇順・降順はどっちになるか、それ以外の列のソートはどうなるかは、クリック直前にソートがどういう状態だったかによるはず。
名前列が昇順だったら、クリックで降順になるだろうし、降順だったら昇順になるだろう。

同じアクション（つまり入力）なのに「結果」が異なっている。
以前の入力が「結果」に影響している。

「独立」の例
新規パスワードとその繰り返しフォーム。
繰り返しフォームのほうに "baz" と入力したら、繰り返しフォーム内の値は "baz" になるはず。
新規パスワードを "bar" としているかといって、繰り返しフォーム内の値が入力できなかったり、"bar" と "baz" の一致部分である "ba" になったりするのは、不自然。

"baz" と "bar" だとバリデーションはもちろんNGだが、「バリデーションNG」は単独の状態ではなく導出可能なものなので、バリデーション状態とパスワードの値の「独立」「従属」は考えない。

・・・そうだな、「状態」の定義も必要だ。