JavaScript框架中的变动和变动检测框架中的变动和变动检测
进入2015年以后,关于JS框架,开发人员有了更多选择了。除了Angular,Ember,React,Backbone,还出现了大量的竞争者,
现在有太多的框架可选。
每个人可以从不同的角度对比这些框架,但是我认为最有趣的区别之一是它们管理状态的方法。尤其,思考一下当状态经常发
生改变的时候,这些框架是如何做的,这是很一件有意义的事情,在这些框架中,他们各自都用什么方法来反应用户界面的变
化?
管理应用的状态和用户界面的一致在很长的时间里都是一个引发UI开发复杂性的根源。到目前为止,我们有了几个不同的处理
方式,本篇文章会浏览一下它们之中的几个:Ember的数据绑定,angular的脏检查,React的虚拟DOM以及它和不可变数据
结构的关系。
显示数据
我们要说的基本任务是关于程序的内部状态以及怎么把它放到屏幕上显示出来的可见元素。你拿到一套对象,数组,字符串和
数字,再把它们变成由一个文本组成的树图结构的东西,表单,链接,按钮和图片。在网页开发中,前者经常表达为
JavaScript数据结构,后面几个表现为DOM。
我们经常叫这个过程为“渲染”,你可以想象成是把你的数据模型”映射”成可见的用户界面内容。当你用模板渲染数据时,你得
到一个DOM(或者HTML)来表现数据。
这个过程本身听起来够简单的:尽管映射表单数据模型到UI可能不平凡,但它毕竟是一个很直接的从输入到输出的转换过程。
当我们提到数据经常改变的时候,事情变的有挑战了。当用户和UI交互,或者不知道世界上什么东西的改变更新了数据,反正
UI需要反映这些变化。而且,因为重建DOM树的操作是一个昂贵的操作,消耗较大,我们愿意做尽可能少的工作来让数据更
新到屏幕。
相对于仅仅渲染一次UI,这里面有一个更有难度的问题,因为它涉及到状态更新。这也是产生几个不同方案的地方。
服务器端渲染:一切重来
“没有变化,宇宙是不可变的”
在大JavaScript纪元以前,每一个你和网页的交互都会触发一个服务器端的来回交互,每次点击,每次表单的提交,意味着网
页的重新加载,一个请求被发送到服务器端,服务器处理并响应一个崭新的页面,浏览器再重新渲染它。