我曾见过很多很多人盲目地使用(前端)框架,如 React,Angular 或 Vue等等。这些框架提供了许多有意思的东西,然而通常人们(自以为)使用框架是因为:
它们支持组件化;
它们有强大的社区支持;
它们有很多(基于框架的)第三方库来解决问题;
它们有很多(很好的)第三方组件;
它们有浏览器扩展工具来帮助调试;
它们适合做单页应用。
但这些都不是使用框架的根本原因。
最最本质的原因是:
(UI 与状态同步非常困难)
为了高效地改变 DOM,我们需要编写大量点对点(译者注:指状态到 UI)的代码。但只要你犯下了很小的错误,UI 与状态将不再保持同步:(可能会出现)丢失或呈现错误的信息、不再响应用户的操作,更糟糕的是触发了错误的动作(如点了删除按钮后删除了非对应的一项)。
因此,保持 UI 与状态同步,需要编写大量乏味且非常脆弱的代码。
响应式 UI 拯救一切
所以,(之所以使用框架,)不是因为社区,不是因为工具,不是因为生态,不是因为第三方库……
目前为止,框架最大的改进是(为我们)提供了应用内部状态与 UI 同步的可靠保证。
只要你清楚特定框架的某些(特定)规则(如不可变状态),就差不多(可以正常使用)了。
我们只需要定义一次 UI 界面,不再需要为每个操作编写特定的 UI 代码,同时,每个相同的状态均有相同的输出(译者注:指 UI 一致):当状态改变后,框架自动更新(对应的)视图。
框架是如何工作的呢?
基于两个基本的策略:
重新渲染整个组件,如React。当组件中的状态发生改变时,在内存中计算出(新的)DOM 结构后与已有的 DOM 结构进行对比。实际上,这是非常昂贵的。因而采取(将真实 DOM)映射为虚拟 DOM ,通过对比状态变化前后虚拟 DOM 的不同,计算出变化后再改变真实 DOM 结构。这个过程称为调和(reconciliation)。
通过(添加)观察者监测变化,如 Angular 和 Vue.js。应用中状态的属性会被监测,当它们发生变化时,只有依赖了(发生变化)属性的 DOM 元素会被重新渲染。
结论
现代 js 框架解决的主要问题是保持 UI 与状态同步。
使用原生 JavaScript 编写复杂、高效而又易于维护的 UI 界面几乎是不可能的。
Web components 并未提供解决同步问题的方案。
使用现有的虚拟 DOM 库去搭建自己的框架并不困难。但并不建议这么做!
(转载: https://mp.weixin.qq.com/s/GqUK_QRIjBFwMXF5_c4vgg)