Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix text lint errors in reconciliation.md #116

Closed
wants to merge 1 commit into from
Closed

fix text lint errors in reconciliation.md #116

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions content/docs/reconciliation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ React を使う際、`render()` 関数をある時点の React 要素のツリ

あるツリーを別のものに変換するための最小限の操作を求めるというアルゴリズム問題については、いくつかの一般的な解決方法が存在しています。しかし、[最新のアルゴリズム](http://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf)でもツリーの要素数を n として O(n<sup>3</sup>) ほどの計算量があります。

React でそのアルゴリズムを使った場合、1000 個の要素を表示するのに10億といったレベルの比較が必要となります。これではあまりに計算コストが高すぎます。代わりに、React は 2 つの仮定に基づくことで、ある程度近い結果を得ることができる O(n) ほどの計算量のアルゴリズムを実装しています。
React でそのアルゴリズムを使った場合、1000 個の要素を表示するのに 10 億といったレベルの比較が必要となります。これではあまりに計算コストが高すぎます。代わりに、React は 2 つの仮定に基づくことで、ある程度近い結果を得ることができる O(n) ほどの計算量のアルゴリズムを実装しています。

1. 異なる型の 2 つの要素は異なるツリーを生成する。
2. 開発者は key プロパティを与えることで、異なるレンダー間でどの子要素が変化しない可能性があるのかについてヒントを出すことができる。
Expand Down Expand Up @@ -53,7 +53,7 @@ React でそのアルゴリズムを使った場合、1000 個の要素を表示
<div className="after" title="stuff" />
```

これらの2つの要素を比べた場合、React は対応する DOM ノードの `className` のみを更新すればよいと分かります。
これらの 2 つの要素を比べた場合、React は対応する DOM ノードの `className` のみを更新すればよいと分かります。

`style` を更新した場合は、React は同様に変更されたプロパティのみを更新すればよいと分かります。例えば：

Expand Down Expand Up @@ -128,7 +128,7 @@ React は `<li>Duke</li>` と `<li>Villanova</li>` サブツリーをそのま
</ul>
```

これで React は、`'2014'` の keyを持つ要素が新規の要素であり、 `'2015'` と `'2016'` の keyをもつ要素は移動しただけだ、と理解するようになります。
これで React は、`'2014'` の key を持つ要素が新規の要素であり、`'2015'` と `'2016'` の key をもつ要素は移動しただけだ、と理解するようになります。

実際に、key を探すのはたいてい難しくありません。表示しようとしている要素は既に固有の ID を持っているかもしれないので、key をそのデータから設定するだけです。

Expand All @@ -142,7 +142,7 @@ React は `<li>Duke</li>` と `<li>Villanova</li>` サブツリーをそのま

key として配列のインデックスが使用されている場合、並べ替えはコンポーネントの状態に関しても問題を起こすことがあります。コンポーネントのインスタンスは key に基づいて更新、再利用されます。インデックスが key の場合、要素の移動はインデックスの変更を伴います。結果として、非制御の入力などに対するコンポーネントの状態が混乱し、予期せぬ形で更新されてしまうことがあります。

[CodePen](codepen://reconciliation/index-used-as-key)に配列のインデックスを key として使うことで生じる問題についての例があります。また、[こちら](codepen://reconciliation/no-index-used-as-key)が同じ例の更新版であり、配列のインデックスを使わないことで、ソートや並び替え、要素の先頭への追加にまつわる問題がどのように解決されるのかを示しています。
[CodePen](codepen://reconciliation/index-used-as-key) に配列のインデックスを key として使うことで生じる問題についての例があります。また、[こちら](codepen://reconciliation/no-index-used-as-key)が同じ例の更新版であり、配列のインデックスを使わないことで、ソートや並び替え、要素の先頭への追加にまつわる問題がどのように解決されるのかを示しています。

## トレードオフ {#tradeoffs}

Expand Down