引言
研发模式不断演进的背后
恰恰蕴含着前端人对“DOM操作”这一核心动作的持续思考和改进
为什么我们需要虚拟 DOM
DOM操作是很慢的,而 JS 却可以很快,直接操作 DOM 可能会导致频繁的回流与重绘,JS不存在这些问题。因此虚拟 DOM 以原生 DOM 更快。
真的是这样的吗?
快速搞定虚拟 DOM 的两个“大问题”
虚拟 DOM
本质是JS和DOM之间一个映射缓存,在形态上表现为一个能够描述 DOM 结构及其属性。
原生 JS 支配下的“人肉DOM”时期
解放生产力的先导阶段:jQuery 时期
使用模板引擎方案来渲染数据需要关注的仅仅是数据和数据变化本身
走“数据驱动视图”这条基本道路
既然操作真实 DOM 对性能损耗这么大,那么操作假的 DOM 不就行了?
虚拟 DOM 是如何解决问题的?
- 虚拟 DOM 和 Redux 一样,不依附于任何具体的框架
- 学习 React 必须了解虚拟 DOM
开发者写得爽不爽,在于研发体验/研发效率
虚拟 DOM 是前端开发们
为了追求更好的研发体验和开发效率
而创造出来的高阶产物
React 选用虚拟 DOM,真的是为了更好的性能吗?
能够在提供更爽、更高效的研发模式的同时,仍然保持一个还不错的性能
性能问题属于前端领域复杂度比较高的问题
量化性能的时候要结合各种要素来作分情况的讨论
那么虚拟 DOM 的价值到底是什么呢?
- 研发体验/研发效率的问题
- 跨平台的问题
“批量更新”
在通用虚拟 DOM 库是由 batch 函数来处理的 batch 的作用是缓冲每次生成的补丁集