摘要：正文在年，框架的选择并不少。特别的，通过思考这些框架分别如何处理状态变化是很有用的。本文探索以下的数据绑定，的脏检查的虚拟以及它与不可变数据结构之间的联系。当状态产生变化时，只有真正需要更新的部分才会发生改变。
译者言
近几年可谓是 JavaScript 的大爆炸纪元，各种框架类库层出不穷，它们给前端带来一个又一个的新思想。从以前我们用的 jQuery 直接操作 DOM，到 BackboneJS、Dojo 提供监听器的形式，在到 Ember.js、AngularJS 数据绑定的理念，再到现在的 React、Vue 虚拟 DOM 的思想。都是在当前 Web 应用日益复杂的时代，对于如何处理「应用状态」与「用户界面」之间如何更新的问题，带来更先进的解决方案。
本文是一篇从技术上，以数据变更和UI同步为方向，循序渐进的讲述 JavaScript 框架如何演进过来的。
本篇文章，给了我一个更加高纬度的视角，来看待 JavaScript 这些个框架。
正文在 2015 年，JavaScript 框架的选择并不少。在 Angular，Ember，React，Backbone 以及它们众多的竞争者中，有足够多的选择。
虽然可以通过不少方面来对比这些框架的不同，但是最让人感兴趣的是它们分别如何管理状态（state）的。特别的，通过思考这些框架分别如何处理状态变化是很有用的。它们都提供了什么样的工具让你把这些变化呈现给用户？
如何处理应用状态（app state）与用户界面（user interface）之间的同步，长期以来都是用户界面开发如此复杂的主要原因。现在，我们有几个不同的处理方案。本文探索以下：Ember 的数据绑定，Angular 的脏检查、React 的虚拟DOM以及它与不可变数据结构（immutable data structures）之间的联系。
数据映射 Projecting Data我们首先讨论程序内部的状态与屏幕所看到的内容之间的映射。你把各种诸如 object，arrays，strings，以及 numbers 转换成一颗由诸如 texts、forms、links、buttons 和 images 组成的树状结构。在 Web 中，前者通常指 JavaScript 中的数据结构，而后者指的是 DOM （Document Object Model）
我们经常称这个过程为渲染（rendering），你可以想象这个过程是从数据模型到用户界面的一个映射。当你把数据渲染成一个模板，你得到的是一个 DOM（或者说 HTML）。
这个过程本身已经足够简单了，数据模型到用户界面之间的映射，并不总是那么的琐碎。它基本只是一个接受输入然后直接输出的函数。
在我们需要考虑数据开始随着时间而变化的时候，这件事就变得更有挑战性了。当用户进行操作或者其它某些操作导致数据产生变化的时候，用户界面需要呈现出这些变化。而且，由于重新构建 DOM 树的代价是极其昂贵的，我们要尽可能产生小的影响。
因为状态产生了变化，这比只是一次性渲染用户界面变得更加难。这就到了以下解决方案开始表演的时候了。
服务器渲染 Server-Side Rendering宇宙是永恒不变的，没有任何变化
在 JavaScript 新纪元之前，你的 Web 应用的任何交互都会触发一趟服务器的环绕旅行。每一个点击和每一个表单提交都会卸载当前页面，一个请求发送到服务器，服务器响应一个新的页面，然后浏览器重新渲染。
这种方式不需要前端管理任何的状态（state）。就前端范畴而言，当一些事情发生了(后端返回的数据)，整个过程就结束了。就算有状态，那也只是后端的范畴。前端只是由 HTML 和 CSS 构成，也许有时候会有些 JavaScript 撒在表面调味。
从前端来说，这是一个很简单的实现方式，但也是一个很慢的方式。每一个交互并不仅仅触发UI的重渲染，还涉及服务器的数据查询以及服务端渲染。
大多数人已经不再这样做了，我们可以在服务器端初始化我们的应用，然后转移到前端来做状态的管理（这也是 isomorphic JavaScript 致力于的。）。已经有人在类似的更复杂的设计思想中取得成功。
JS第一代革命：手动重渲染我不知道哪些需要渲染的，你来告诉我。
第一代革命的 JavaScript 框架，如：Backbone.js, Ext JS 以及 Dojo。第一次在浏览器端引入了数据模型（Data Model）的概念，代替了以前那些直接操作 DOM 的轻量级的脚本代码。这意味着你终于可以在浏览器端管理状态了。当数据模型的上下文改变时，你需要做一些工作，让改变呈现在用户界面中。
这些框架的体系能分离你的模型和界面代码，但同时也留下了一大部分同步的工作给你。你可以监听某类事件的发生，但是你有义务去计算如何重新渲染以及如何落实到用户界面中。
基于这种模型，作为开发者，你需要考虑大量的性能问题。由于你能控制什么时候和怎么处理更新，你可以从中做任意的做一些调整。这经常会面临一些权衡：简单的处理导致大面积的页面更新，或者强性能的处理来更新一小块页面。
Ember.js: 数据绑定由于我在控制你的模型和试图，我会确切知道如何重新渲染。
当应用状态改变的时候，手动处理渲染工作，无可避免的增加了复杂度。很多框架旨在解决这个问题，Ember.js 就是其中之一。
Ember，像 Backbone 一样，当数据模型改变的时候会触发某个事件。不同之处在于 Ember 同时提供了一些方法来接收这些事件。你可以把 UI 绑定到数据模型中，这意味着有一个监听器绑定到了 UI 上。该监听器当收到事件的时候，知道如何更新 UI。
这是一个高效率的机制。尽管设置全部的监听器需要在初始化时多出一些工作，但是之后就能保证同步状态时的最小影响。当状态产生变化时， 只有真正需要更新的部分才会发生改变。
这种方式最大的牺牲是 Ember 需要时刻盯着数据模型。这意味着你需要通过 Ember 的 API 封装你的数据，以及你要更新数据的时候是使用 foo.set("x",42) 而不是 foo.x = 42，以此类推。
在未来 ES6 的 Proxies 可能会对这种模式产生一定的帮助。它让 Ember 可以通过装饰 object 来绑定那些监听器的代码。这就不用像传统方式那样重写 object 的 setter 方法了。
原文链接Changes and Its detection of JavaScript Framework
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/89424.html
摘要：对此没有任何限制，它不关心这个。一种控制变化的办法是不可改变的，持久化的数据结构。总结检测变化时开发中的核心问题，而框架们以各种方式解决这个问题。因为组件内的变化是不被允许的。 AngularJS：脏检查 我不知道什么更新了，所以当更新的时候，我只能检查所有的东西。 AngularJS 类似于 Ember，当状态改变的时候，必须人工去处理。但不同的是，AngularJS 从不同的角度来...
摘要：正在暑假中的课多周刊第期我们的微信公众号，更多精彩内容皆在微信公众号，欢迎关注。若有帮助，请把课多周刊推荐给你的朋友，你的支持是我们最大的动力。原理微信热更新方案涨知识了，热更新是以后的标配。 正在暑假中的《课多周刊》(第1期) 我们的微信公众号：fed-talk，更多精彩内容皆在微信公众号，欢迎关注。 若有帮助，请把 课多周刊 推荐给你的朋友，你的支持是我们最大的动力。 远上寒山石径...
摘要：正在暑假中的课多周刊第期我们的微信公众号，更多精彩内容皆在微信公众号，欢迎关注。若有帮助，请把课多周刊推荐给你的朋友，你的支持是我们最大的动力。原理微信热更新方案涨知识了，热更新是以后的标配。 正在暑假中的《课多周刊》(第1期) 我们的微信公众号：fed-talk，更多精彩内容皆在微信公众号，欢迎关注。 若有帮助，请把 课多周刊 推荐给你的朋友，你的支持是我们最大的动力。 远上寒山石径...
摘要：精读前端可以从多个角度理解，比如规范框架语言社区场景以及整条研发链路。同是前端未来展望，不同的文章侧重的格局不同，两个标题相同的文章内容可能大相径庭。作为使用者，现在和未来的主流可能都是微软系，毕竟微软在操作系统方面人才储备和经验积累很多。 1. 引言 前端展望的文章越来越不好写了，随着前端发展的深入，需要拥有非常宽广的视野与格局才能看清前端的未来。 笔者根据自身经验，结合下面几篇文章...
摘要：前端每周清单第期与模式变迁与优化界面生成作者王下邀月熊编辑徐川前端每周清单专注前端领域内容，以对外文资料的搜集为主，帮助开发者了解一周前端热点分为新闻热点开发教程工程实践深度阅读开源项目巅峰人生等栏目。 showImg(https://segmentfault.com/img/remote/1460000013279448); 前端每周清单第 51 期: React Context A...
阅读 1102·2023-04-26 00:12
阅读 3185·2021-11-17 09:33
阅读 1017·2021-09-04 16:45
阅读 1145·2021-09-02 15:40
阅读 2053·2019-08-30 15:56
阅读 2877·2019-08-30 15:53
阅读 3476·2019-08-30 11:23
阅读 1891·2019-08-29 13:54
