state 構造の選択

state 構造の原則

state を格納するコンポーネントを作成する際に、いくつ state 変数を使うのか、データ構造をどのようにするのかについて選択を行う必要があります。最適とはいえない state 構造でも正しいプログラムを作成することは可能ではありますが、より良い選択をするために役立つ原則がいくつか存在します。

1. 関連する state をグループ化する。2 つ以上の state 変数を常に同時に更新する場合、それらを単一の state 変数にまとめることを検討してください。
2. state の矛盾を避ける。state の複数部分が矛盾して互いに「衝突する」構造になっている場合、ミスが発生する余地があるということです。これを避けてください。
3. 冗長な state を避ける。コンポーネントの props や既存の state 変数からレンダー時に何らかの情報を計算できる場合、その情報をコンポーネントの state に入れるべきではありません。
4. state 内の重複を避ける。同じデータが複数の state 変数間、またはネストしたオブジェクト間で重複している場合、それらを同期させることは困難です。できる限り重複を減らしてください。
5. 深くネストされた state を避ける。深い階層構造となっている state はあまり更新しやすくありません。できる限り、state をフラットに構造化する方法を選ぶようにしてください。

これらの原則の背後にある目標は、ミスを入りこませずに state を容易に更新できるようにすることです。state から冗長で重複するデータを取り除くことで、すべての state が同期した状態を保てるようになります。これは、データベースエンジニアがバグを減らすためにデータベース構造を “正規化 (normalize)” しようとする考え方と似ています。アルバート・アインシュタインのもじりですが、「state はできる限りシンプルにすべきだ、だがシンプルすぎてもいけない」ということです。

これらの原則が実際にどのように適用されるか見てみましょう。

関連する state をグループ化する

ときに、単一の state 変数を使用するか、複数の state 変数を使用するかで迷うことがあるかもしれません。

こうすべきでしょうか？

const [x, setX] = useState(0);
const [y, setY] = useState(0);

それともこうでしょうか？

const [position, setPosition] = useState({ x: 0, y: 0 });

技術的には、どちらのアプローチを採用することも可能です。しかし 2 つの state 変数が常に一緒に変更される場合は、それらを単一の state 変数にまとめると良いでしょう。そうすれば、常に両者を同期することを忘れる心配がありません。例えば以下に、カーソルを動かすと赤い点の両方の軸の座標が更新されるという例を示します。

state をオブジェクトや配列にグループ化する別のケースとして、state の数が事前にわからない場合があります。たとえば、ユーザがカスタムフィールドを追加できるフォームがある場合に、これが有用です。

state の矛盾を避ける

以下は、isSending と isSent という state 変数があるホテルのフィードバックフォームです。

このコードは機能しますが、「ありえない」state になってしまう余地を残しています。たとえば、setIsSent と setIsSending を一緒に呼び出すのを忘れた場合、isSending と isSent が同時に true になってしまう状況に陥るかもしれません。コンポーネントが複雑になればなるほど、何が起こったのか理解しにくくなります。

isSending と isSent は同時に true になることはないため、それらを 1 つの status という state 変数に置き換えて、typing（初期状態）、sending、sent という 3 つの有効な状態のうちの 1 つになるようにする方が良いでしょう。

読みやすくしたければ定数を宣言することはいつでも可能です。

const isSending = status === 'sending';
const isSent = status === 'sent';

これらは state 変数ではなくなったので、互いに同期がとれなくなる心配をする必要はありません。

冗長な state を避ける

レンダー中にコンポーネントの props や既存の state 変数から情報を計算できる場合、その情報をコンポーネントの state に入れるべきではありません。

例として、このフォームを見てみましょう。動作はしていますが、冗長な state がないか探してみてください。

このフォームには 3 つの state 変数があります。firstName、lastName、そして fullName です。しかし、fullName は冗長です。レンダー中に fullName は常に firstName と lastName から計算できるので、state から削除しましょう。

以下のようにします。

これで fullName は state 変数ではなくなっています。代わりに、レンダー中に計算されます：

const fullName = firstName + ' ' + lastName;

結果的に、これを更新するために change ハンドラは何も特別なことをする必要がなくなりました。setFirstName や setLastName を呼び出すと、再レンダーがトリガされ、次の fullName は新しいデータから計算し直されます。

function Message({ messageColor }) {
  const [color, setColor] = useState(messageColor);

function Message({ messageColor }) {
  const color = messageColor;

function Message({ initialColor }) {
  // The `color` state variable holds the *first* value of `initialColor`.
  // Further changes to the `initialColor` prop are ignored.
  const [color, setColor] = useState(initialColor);

state 内の重複を避ける

このメニューリストコンポーネントでは、旅行に持っていくお菓子を複数の選択肢から 1 つだけ選ぶことができます。

現在、選択した項目を selectedItem という state 変数にオブジェクトとして格納しています。しかしこれは良くありません。なぜなら、selectedItem の内容は、items リスト内の要素のうちの 1 つと同一のオブジェクトになっているためです。これは、その項目に関する情報が 2 つの場所で重複していることを意味します。

なぜこれが問題なのでしょうか? それぞれの項目を編集可能にしてみましょう。

いずれかの項目の “Choose” をクリックしてから編集すると、入力欄は更新されますが、下部のラベルは編集内容を反映していません。これは、state に重複があり、selectedItem 側の更新を忘れたためです。

selectedItem 側も更新するようにしても良いのですが、簡単な解決策は重複を解消することです。この例では、items 内のオブジェクトと selectedItem オブジェクトを重複させる代わりに、state では selectedId を保持するようにし、その ID を持つアイテムを items 配列から検索することで selectedItem を取得するようにします。

（または、選択されたインデックスを state に保持することもできます。）

以前は state がこのように重複していました。

• items = [{ id: 0, title: 'pretzels'}, ...]
• selectedItem = {id: 0, title: 'pretzels'}

しかし、変更後は以下のようになります。

• items = [{ id: 0, title: 'pretzels'}, ...]
• selectedId = 0

重複がなくなり、必要な state だけが残っています！

これで、選択された項目を編集すると、下のメッセージもすぐに更新されるようになります。これは、setItems が再レンダーをトリガし、items.find(...) がタイトル更新後の項目を見つけてくるためです。選択された項目のデータ全体を state に格納する必要はありませんでした。なぜなら選択された項目 ID だけが本質的なものだからです。残りはレンダー時に計算することができます。

深くネストされた state を避ける

惑星、大陸、国々で構成される旅行計画を想像してみてください。以下のようにして、state をネストしたオブジェクトと配列を駆使して構造化することが魅力的に思えるかもしれません。

ここで、既に訪れた場所を削除するボタンを追加したくなったとしましょう。どのようにすればよいでしょうか？ ネストされた state を更新すると、変更された部分より上のすべてのオブジェクトのコピーを作成する必要が出てきます。深くネストされたところにある場所情報を削除するためには、親として繋がっている場所データをすべてコピーする必要があります。そのようなコードを書くのはとても大変です。

state が簡単に更新できないほどネストしている場合は、「フラット」にすることを検討してください。ここでは、データを再構築する方法の 1 つを示します。place のそれぞれに子となる場所情報そのものの配列を持たせるのではなく、それぞれの場所が子となる場所情報の ID の配列を持つようにします。次に、それぞれの場所 ID と対応する場所情報のマッピングを格納します。

このようなデータ再構成を見ると、データベーステーブルを思い出すかもしれませんね。

state が「フラット」な（別名「正規化された (normalized)」）状態になったので、ネストされた項目の更新が簡単になります。

場所を削除したい場合、state を 2 レベルにわたって更新するだけで済みます。

• 親の場所情報を更新して、childIds 配列から、削除された場所の ID を除外する。
• ルートの「テーブル」オブジェクトを更新して、上記の更新された親の場所情報を含むようにする。

以下がやり方の一例です。

state は好きなだけネストさせることができますが、「フラット」にすることで多くの問題を解決できます。state の更新が容易になるだけでなく、ネストされたオブジェクトのさまざまな部分で重複がないことを保証するのにも役立ちます。

ネストされている state の一部を子コンポーネントに移動することで、state のネストを減らすことが可能な場合もあります。これは「アイテムがホバーされているか」といった、保存する必要のない一時的な UI 関連の state で適しています。