React as a UI Runtime(五、列表)

通过比较树中的元素是否在同一位置，通常已经足够判断是否是重用还是再次创建通信组件了。
但是这只在子元素的位置是静止的并且不需要重排。在我们的上述的例子中，即使message不存在，我们仍然只带input在message之后，并且没有其他的子元素。

对于动态列表，我们不能确定顺序是否会一致：

function ShoppingList({ list }) {
  return (
    

      {list.map(item => (
        

          You bought {item.name}
          

          Enter how many do you want: 
        
      ))}
    
  )
}

如果shopping项目没有被重排，React把所有的p和input元素看做是一个类型，并且不知道怎么移动他们。（从react的视角看，是商品的项目本身改变了，而不是他们的顺序）
React执行的10个商品项目的重排会是下面这样：

for (let i = 0; i < 10; i++) {
  let pNode = formNode.childNodes[i];
  let textNode = pNode.firstChild;
  textNode.textContent = 'You bought ' + items[i].name;
}

So instead of re-ordering them, React would effectively update each of them. This can create performance issues and possible bugs. For example, the content of the first input would stay reflected in first input after the sort — even though conceptually they might refer to different products in your shopping list!

This is why React nags you to specify a special property called key every time you include an array of elements in your output:

所以React会更新每一个元素而不是对他们进行重排。这可能会引起性能问题和可能的bugs。例如，当商品列表的顺序改变时，原本在第一个输入框的内容仍然会存在于现在的第一个输入框中 — 尽管事实上在商品列表里它应该代表着其他的商品！
这就是为什么React会提示你为每一个数组的遍历元素标记一个独有的key属性：

function ShoppingList({ list }) {
  return (
    

      {list.map(item => (
        

          You bought {item.name}
          

          Enter how many do you want: 
        
      ))}
    
  )
}

key 给予 React 判断子元素是否真正相同的能力，即使在渲染前后它在父元素中的位置不是相同的。

当 React 在

中发现

，它就会检查之前版本中的 是否同样含有

。即使 中的子元素们改变位置后，这个方法同样有效。在渲染前后当 key 仍然相同时，React 会重用先前的宿主实例，然后重新排序其兄弟元素。

需要注意的是 key 只与特定的父亲 React 元素相关联，比如 。React 并不会去匹配父元素不同但 key 相同的子元素。（React 并没有惯用的支持对在不重新创建元素的情况下让宿主实例在不同的父元素之间移动。）

给 key 赋予什么值最好呢？最简单的答案就是：哪时候一个元素不会改变即使它在父元素中的顺序被改变？ 例如，在商品列表中，商品本身的 ID 是区别于其他兄弟商品的标识。