From 3eed5deead1419982707e4a82a59c9f0590f7735 Mon Sep 17 00:00:00 2001 From: Jim Date: Tue, 10 Nov 2015 10:28:49 -0800 Subject: [PATCH] Merge pull request #5403 from yuyokk/patch-1 Clarify note about stable keys (cherry picked from commit d6a547f7934edce9ea411d681c94357cd6842939) --- 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 25d20b2832..54e40d3700 100644 --- a/docs/docs/ref-08-reconciliation.md +++ b/docs/docs/ref-08-reconciliation.md @@ -129,5 +129,5 @@ Because we rely on two heuristics, if the assumptions behind them are not met, p 1. The algorithm will not try to match sub-trees of different components classes. If you see yourself alternating between two components classes with very similar output, you may want to make it the same class. In practice, we haven't found this to be an issue. -2. If you don't provide stable keys (by using Math.random() for example), all the sub-trees are going to be re-rendered every single time. By giving the users the choice to choose the key, they have the ability to shoot themselves in the foot. +2. Keys should be stable, predictable, and unique. Unstable keys (like those produced by Math.random()) will cause many nodes to be unnecessarily re-created, which can cause performance degradation and lost state in child components.