## 前言 本文摘录一些常见的误解。 ## react是一个完整的前端框架 其实并不完整，其仅仅是包括了前端的页面，可以搭配jsx与虚拟dom完成视图层的操作，但是还缺乏数据的控制与逻辑部分，如果这部分也写在react中就会让组件显得臃肿，因此正确的观点是react搭配flux以及其他生态工具才能构成完整的前端框架。 ## jsx是页面模板 jsx表面看起来是html的模板，实际上却可以写js的逻辑，书写jsx实际上是在构建js的抽象语法树（AST）,其中每一个标签对应着一个js的表达式，而不是和其他模板一样，对应的是填充之后的html代码。 另一方面，它的转换不是简单的文本替换，而是AST转换。 所以每一处被嵌入的js逻辑代码必须是一个AST的独立节点。 ## react的性能 性能优化的本质原因：传统的dom更新是重新渲染的比较浪费时间，而虚拟dom是对比dom变化的部分，只对变化部分进行更新。这个是相对整体渲染而言的。 但有些时候，如果能够直接指定变更的部分，其比虚拟dom对比然后去更新代价要低。这里不排除，有些经过计算是比手动调整更优化的情况。所以虚拟dom不一定是所有场景下性能最优的。以可接受的执行效率损失作为代价，换取开发效率的提升，是一个趋势。 ## 短路式的性能优化 基于shouldComponentUpdate做的短路优化更新几乎是被无限制的或者默认的使用的。其基本做法是触发更新之前，对比其数据变更部分，认为props和state未变更的情况下，返回false，阻止其渲染。在很多情况下这种方式可以大大的提升性能，优化用户体验，但是有两个基本的前提： 1 组件本身的render方法参数是state和props的纯函数，对未改变的state和props,render返回相同的结果。 2 state和props是不可变的。关于第二点，其参数复杂的时候不会进行深层的匹配判断，其内容的变化不会被检查出来。如果这种情况数据发生变化了，但界面未进行更新，就会导致不匹配的错误。 **注意事项：** 尽管其看似是哪里都合适的，但是如果其判断机制浪费了很多逻辑，进行了多层对象遍历的开销。这样的优化不是很必要，尤其对于频繁更改的组件，其累计损失不可忽视，需要谨慎考虑。 **提示：默认给所有组件加上这个优化是不推荐的做法** ## 无状态函数式组件的性能