From b814697ce38b04cd4a7925cf10fce314e5311ccf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Paul=20O=E2=80=99Shannessy?= Date: Mon, 22 Sep 2014 14:32:18 -0700 Subject: [PATCH] Merge pull request #2209 from glenjamin/patch-2 [docs] Clarify wording on sub-tree reconciliation --- docs/docs/ref-08-reconciliation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/ref-08-reconciliation.md b/docs/docs/ref-08-reconciliation.md index 7332103dfb..60f669caea 100644 --- a/docs/docs/ref-08-reconciliation.md +++ b/docs/docs/ref-08-reconciliation.md @@ -122,7 +122,7 @@ In practice, finding a key is not really hard. Most of the time, the element you It is important to remember that the reconciliation algorithm is an implementation detail. React could re-render the whole app on every action, the end-result would be the same. We are regularly refining the heuristics in order to make common use cases faster. -In the current implementation, you can express the fact that a sub-tree has been moved between siblings, but you cannot tell that it has moved somewhere else. The algorithm will re-render that full sub-tree. +In the current implementation, you can express the fact that a sub-tree has been moved amongst its siblings, but you cannot tell that it has moved somewhere else. The algorithm will re-render that full sub-tree. Because we rely on two heuristics, if the assumptions behind them are not met, performance will suffer.