もうひとつ、覚えておかなければならないことがある。 Reactキー 属性を使用する場合、レンダリングされるリストの各要素はこの属性を持たなければなりません。この概念は、フロントエンド開発者が最初に学ぶことのひとつです。 React 旅のスタート地点ででは、なぜそうなのか、どんなときに近道ができるのか、もう少し掘り下げて考えてみよう。
なぜこのキー属性が必要なのか？
ここでの最も単純な答えは「再レンダリングを最適化すること」だろうが、より完全な答えは、少なくとも以下の概念に言及しなければならない。 React照合.これは、最も効率的な方法でUIを更新する方法を見つけ出すプロセスだ。それを素早く行うために React は、要素ツリーのどの部分を更新し、どの部分を更新しないかを決定しなければならない。DOMにはたくさんの要素があり、どれを更新すべきかを決定するためにそれぞれの要素を比較するのは、かなり手間がかかる。これを最適化するには React は、2つの仮定に基づくdiffingアルゴリズムを実装している：
- 2つの異なるタイプのエレメントは決して同じにはならない。
- 開発者は、キー属性を介して手動でそのプロセスを最適化することができるため、要素の順序が変わったとしても、より速くローカライズして比較することができる。
このことから、次のように結論づけることができる。 Reactキー また、（グローバルではなく、要素のリスト内で）一意でなければならず、（変化してはならない）安定したものでなければならない。しかし、もしそれが一意でなかったらどうなるだろうか？
一意性、安定性、配列インデックス
前にも述べたように、 Reactキー は安定して一意でなければならない。これを実現する最も簡単な方法は、（例えばデータベースから）一意なIDを使用し、配列をマッピングする際に各要素にそれを渡すことです。しかし、各要素に渡すIDや名前などの一意な識別子がない場合はどうすればいいのでしょうか？キーとして何も渡さなければいい、 React はデフォルトで現在の配列のインデックスを取り（リスト内で一意であるため）、それを処理してくれるが、コンソールに素敵なエラーメッセージも表示してくれる：
なぜそうなるのか？答えは、配列のインデックスが安定しないからだ。要素の順番が変われば、それぞれのキーも変わってしまい、問題が発生する。もし React 要素のリストの順番が変更された場合でも、キーで比較しようとするため、比較のたびにコンポーネントが再構築され、結果的にリスト全体がゼロから再構築されることになります。それに加えて、制御されていない入力のような要素に対するコンポーネントの状態の更新や、その他の不思議なデバッグしにくい問題のような、予期せぬ問題に遭遇することもあります。
例外
配列のインデックスに戻ろう。これを Reactキー がこれほど問題になるのはなぜか。 React はデフォルトで使用するのでしょうか？そうしても問題ないユースケースはあるのでしょうか？答えはイエスで、その使用例は静的リストです。レンダリングするリストの順番が変わることがないのであれば、array indexを使っても問題ありませんが、一意な識別子がある場合は、それを使ったほうがよいことを覚えておいてください。また、インデックスをキーとして渡すと React のエラーメッセージは消えますが、同時に外部リンターのいくつかはエラーや警告を表示します。これは、インデックスをキーとして明示的に使用することは悪い習慣とみなされ、いくつかのリンターがエラーとして扱う可能性があるという事実によるものです。 React そのため、本当に自分が何をしているかわかっているのでなければ、そのようなことはしないでください。 この例外を使ってもいい場合の例としては、静的なボタンリストを持つドロップダウンや、会社の住所情報を持つ要素のリストを表示する場合などがあります。
データセットベースのキーに代わるもの
例えば、文字列の配列に基づいて要素のリストを表示しなければならない。例えば、文字列の配列に基づいて要素のリストを表示する必要があり、その配列は重複する可能性があるが、並び替えることもできる。この場合、文字列は一意ではないのでどれも使えないし（これは魔法のようなバグを引き起こす可能性もある）、配列のインデックスも要素の順番を変えてしまうので十分ではない。このような状況で最後に頼りになるのは、外部識別子を使うことだ。Math.random()を使うわけにはいかないので、安定したものでなければならないことを忘れないでほしい。このような場合に使えるNPMパッケージがいくつかあります。 「uuid パッケージを使用する。このようなツールは、データセット内に適切な識別子が見つからない場合でも、リストキーを安定かつ一意に保つのに役立ちます。で使用するパッケージの数を最小限にするために、データベースIDと配列インデックス（可能であれば）を最初に使用することを検討すべきです。 プロジェクト.
最後に
- のリスト上の各要素は React 要素は一意で安定したキー属性を持つべきである、
- Reactキー を高速化するために使用される。 調整プロセス そして、リスト上の要素の不必要な再構築を避ける、
- キーのソースとして最適なのは、（例えばデータベースからの）データ入力一意のIDである、
- 配列のインデックスをキーとして使うこともできるが、それは順番が変わらない静的リストに対してのみである、
- 安定した一意なキーを取得する方法が他にない場合は、外部のIDプロバイダー、たとえば「uuid」パッケージの利用を検討しよう。
続きを読む
おそらく）Typescriptを使うべき理由
悪いコーディング・プラクティスでプロジェクトを潰さないためには？
NextJSのデータフェッチ戦略
