最初使用React时，没有太注意细节，只是会使用，实现功能，当使用一段时间再回过头来看官方文档时发现有些东西原来是这样的，下面就把再次看文档时觉得柳暗花明的地方总结一下，也算是对React基础学习告一段落，开启下一篇章。
key应该是稳定的，且唯一的，尽量不要用索引作为key
都知道React组件渲染列表时需要为每个列表元素分配一个在列表中独一无二的key，key可以在DOM中的某些元素被增加或删除视乎帮助React识别哪些发生了变化，通常列表数据都会有id字段，习惯用id值作为key，当没有id或其他唯一标识时，也会用序列号索引index作为key，之前并没有觉得用index有什么不好之处，再次看文档发现序列号索引作为key有一些弊端。
如果列表可以重新排序，不建议使用索引作为key，因为会导致渲染变得很慢，如果不重排，没问题。
为什么变得很慢？
React通过对比算法来更新组件，使用key来匹配原本树的子节点和新树的子节点，比如以下列表，在开始插入元素：
<ul>
<li key='6'>6</li>
<li key='7'>7</li>
</ul>
<ul>
<li key='5'>5</li>
<li key='6'>6</li>
<li key='7'>7</li>
</ul>
没有使用index作为key，React知道key为'5'的元素是新的，仅移动key为'6'、'7'的元素就可以了。
如果使用index作为key，上述列表的变化会导致key值的变化，列表元素不能复用，造成不必要的重建，也可能会以意想不到的方式更新，所以会变慢。
注意：不要使用不稳定的key（类似Math.random()生成的）
React中布尔值、Null和Undefined被忽略，数字0不会被忽略
React使用条件渲染时，通常用JavaScript的逻辑与&&，当showHeader为true时渲染<Header />，如下：
<div>
{showHeader && <Header />}
</div>
但数字0不会像预期的哪样运行，如下：
<div>
{props.messages.length &&
<MessageList messages={props.messages} />
}
</div>
props.messages为空数组时，仍然会渲染<MessageList />，要解决这个问题，确保 && 前面的表达式始终为布尔值：
<div>
{props.messages.length > 0 &&
<MessageList messages={props.messages} />
}
</div>
使用PropTypes进行类型检查是很必要的
最开始写React的时候从来都不加PropTypes，觉得没什么必要，现在发现PropTypes进行类型检查是很必要的，如果父组件传给子组件的参数不符合PropTypes配置，控制台就会报错，给出错误信息，这样可以快速定位问题。
另外通过defaultProps为props定义默认值时，类型检查也会应用在 defaultProps 上面，因为类型检查发生在 defaultProps 赋值之后。
使用说明请查看官方文档：https://doc.react-china.org/docs/typechecking-with-proptypes.html
React中获取真实DOM节点或 React 元素时使用Refs
获取在 render 方法中创建的 DOM 节点或 React 元素时，最好使用“回调 ref”的方式，不要用DOM操作也不要用旧版 API：String 类型的 Refs
render() {
return (
//回调ref
<input ref={input => this.inputRef = input}/>
//string类型的ref
<input ref=“inputRef”/>
);
}
不要在函数式组件中使用ref属性来进行回调函数的绑定，因为函数式组件是没有实例的，准确的说函数式组件不是一个真正的类
React.Fragment组件的使用
在React中组件返回多个元素时要被一个元素包裹，不然会报错，我们通常用div元素，这个div元素没有什么实际的意义，并且会在DOM中增加额外节点，建议用React.Fragment组件，不会增加额外的节点，目前key 是唯一可以传递给 Fragment 的属性。
render() {
return (
<React.Fragment>
<h1>React 文档</h1>
<div>React内容</div>
</React.Fragment>
);
}
