From f5a4a76780f5a13ec4d3826238bac3fb2c766341 Mon Sep 17 00:00:00 2001 From: Glen Mailer Date: Thu, 18 Sep 2014 22:48:35 +0100 Subject: [PATCH] [docs] Clarify wording on sub-tree reconciliation The previous wording could be interpreted to mean sub-trees moving from within one sibling to within another, rather than the shuffling of siblings on a single level as intended --- docs/ref-08-reconciliation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ref-08-reconciliation.md b/docs/ref-08-reconciliation.md index 7332103d..60f669ca 100644 --- a/docs/ref-08-reconciliation.md +++ b/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.