（四）：虚拟DOM Diff算法解析
最后更新于：2022-04-01 23:10:59
React中最神奇的部分莫过于虚拟DOM，以及其高效的Diff算法。这让我们可以无需担心性能问题而”毫无顾忌”的随时“刷新”整个页面，由虚拟DOM来确保只对界面上真正变化的部分进行实际的DOM操作。React在这一部分已经做到足够透明，在实际开发中我们基本无需关心虚拟DOM是如何运作的。然而，作为有态度的程序员，我们总是对技术背后的原理充满着好奇。理解其运行机制不仅有助于更好的理解React组件的生命周期，而且对于进一步优化React程序也会有很大帮助。
[TOC]
## 什么是DOM Diff算法
Web界面由DOM树来构成，当其中某一部分发生变化时，其实就是对应的某个DOM节点发生了变化。在React中，构建UI界面的思路是由当前状态决定界面。前后两个状态就对应两套界面，然后由React来比较两个界面的区别，这就需要对DOM树进行Diff算法分析。
即给定任意两棵树，找到最少的转换步骤。但是[标准的的Diff算法](http://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf)复杂度需要O(n^3)，这显然无法满足性能要求。要达到每次界面都可以整体刷新界面的目的，势必需要对算法进行优化。这看上去非常有难度，然而Facebook工程师却做到了，他们结合Web界面的特点做出了两个简单的假设，使得Diff算法复杂度直接降低到O(n)
1. 两个相同组件产生类似的DOM结构，不同的组件产生不同的DOM结构；
2. 对于同一层次的一组子节点，它们可以通过唯一的id进行区分。
算法上的优化是React整个界面Render的基础，事实也证明这两个假设是合理而精确的，保证了整体界面构建的性能。
## 不同节点类型的比较
为了在树之间进行比较，我们首先要能够比较两个节点，在React中即比较两个虚拟DOM节点，当两个节点不同时，应该如何处理。这分为两种情况：（1）节点类型不同 ，（2）节点类型相同，但是属性不同。本节先看第一种情况。
当在树中的同一位置前后输出了不同类型的节点，React直接删除前面的节点，然后创建并插入新的节点。假设我们在树的同一位置前后两次输出不同类型的节点。
~~~
renderA:
renderB:
=> [removeNode ], [insertNode ]
~~~
当一个节点从div变成span时，简单的直接删除div节点，并插入一个新的span节点。这符合我们对真实DOM操作的理解。
需要注意的是，删除节点意味着彻底销毁该节点，而不是再后续的比较中再去看是否有另外一个节点等同于该删除的节点。如果该删除的节点之下有子节点，那么这些子节点也会被完全删除，它们也不会用于后面的比较。这也是算法复杂能够降低到O（n）的原因。
上面提到的是对虚拟DOM节点的操作，而同样的逻辑也被用在React组件的比较，例如：
~~~
renderA:
);
},
shape6: function() {
return (
);
},
~~~
那么控制台输出如下：
~~~
C is updated.
B is updated.
A is updated.
R is updated.
~~~
可以看到，对于列表节点提供唯一的key属性可以帮助React定位到正确的节点进行比较，从而大幅减少DOM操作次数，提高了性能。
## 小结
本文分析了React的DOM Diff算法究竟是如何工作的，其复杂度控制在了O（n），这让我们考虑UI时可以完全基于状态来每次render整个界面而无需担心性能问题，简化了UI开发的复杂度。而算法优化的基础是文章开头提到的两个假设，以及React的UI基于组件这样的一个机制。理解虚拟DOM Diff算法不仅能够帮助我们理解组件的生命周期，而且也对我们实现自定义组件时如何进一步优化性能具有指导意义。
';
（三）：理解JSX和组件
最后更新于：2022-04-01 23:10:57
> 原文：http://www.infoq.com/cn/articles/react-jsx-and-component
通过前两篇文章的介绍，相信大家对JSX和组件已经有了一定的了解。JSX这种混合使用JavaScript和XML的语言第一眼看上去很“丑”，也很神奇，但是其语法和背后的逻辑却极其简单。相信读完本文你就可以对JSX和组件有一个全面的了解，并能够用JSX来直观的构造用户界面。
**目录**
[TOC]
## 什么是JSX
React的核心机制之一就是虚拟DOM：可以在内存中创建的虚拟DOM元素。React利用虚拟DOM来减少对实际DOM的操作从而提升性能。类似于真实的原生DOM，虚拟DOM也可以通过JavaScript来创建，例如：
~~~
var child1 = React.createElement('li', null, 'First Text Content');
var child2 = React.createElement('li', null, 'Second Text Content');
var root = React.createElement('ul', { className: 'my-list' }, child1, child2);
~~~
使用这样的机制，我们完全可以用JavaScript构建完整的界面DOM树，正如我们可以用JavaScript创建真实DOM。但这样的代码可读性并不好，于是React发明了JSX，利用我们熟悉的HTML语法来创建虚拟DOM：
~~~
var root =(
{todo.text}
);
});
var ul = (
';
- First Text Content
- Second Text Content
Welcome back, {{person.firstName}} {{person.lastName}}!
Please log in.
~~~
在[EmberJS](http://emberjs.com/)中：
~~~
{{#if person}}
Welcome back, {{person.firstName}} {{person.lastName}}!
{{else}}
Please log in.
{{/if}}
~~~
在[Knockoutjs](http://knockoutjs.com/)中：
~~~
Welcome back, {{person.firstName}} {{person.lastName}}!
Please log in.
~~~
模板可以直观的定义UI来展现Model中的数据，你不必手动的去拼出一个很长的HTML字符串，几乎每种框架都有自己的模板引擎。传统MVC框架强调界面展示逻辑和业务逻辑的分离，因此为了应对复杂的展示逻辑需求，这些模板引擎几乎都不可避免的需要发展成一门独立的语言，如上面代码所示，每个框架都有自己的模板语言语法。而这无疑增加了框架的门槛和复杂度。
如果说掌握一种模板语言并不是很大的问题，那么其实由模板带来的架构复杂性则是让框架也变得复杂的重要原因之一，例如：
* 模板需要对应数据模型，即上下文，如何去绑定和实现？
* 模板可以嵌套，不同部分界面可能来自不同数据模型，如何处理？
* 模板语言终究是一个轻量级语言，为了满足项目需求，你很可能需要扩展模板引擎的功能。
为了解决这些复杂度，框架本身需要精心的设计，以及创造新的概念（例如Angular的Directive）。这些都会让框架变得复杂和难以掌握，不仅增加了开发成本，各种难以调试的Bug还会降低开发质量。
正因为如此，React直接放弃了模板而发明了JSX。看上去很像模板语言，但其本质是通过代码来构建界面，这使得我们不再需要掌握一门新的语言就可以直观的去定义用户界面：掌握了JavaScript就已经掌握了JSX。这里不妨再引用之前文章举过的例子，在展示一个列表时，模板语言通常提供名为Repeat的语法，例如在Angular中：
~~~
- {{todo.text}}
-
{lis}
{
person ? Welcome back, {person.firstName} {person.lastName}!
: Please log in
}
);
~~~
既然大括号中是JavaScript，而JSX又允许在JavaScript中使用XML，因此在大括号中仍然可以使用XML来声明组件，不断递归使用。
如果需要展现一组子节点，只需表达式返回一个JavaScript数组，数组的每个元素都是一个React组件，例如上一节的例子，其中lis就是有多个“li”元素的数组。：
~~~
var ul = (
-
{lis}
Hello World.
~~~
乍一看，这段JSX中的大括号是双的，有点奇怪，但实际上里面的大括号只是标准的JavaScript对象表达式，外面的大括号是JSX的语法。所以，样式你也可以先赋值给一个变量，然后传进去，代码会更易读：
~~~
var style = {
color: '#ff0000',
fontSize: '14px'
};
var node = HelloWorld.
;
~~~
在JSX中可以使用所有的的样式，基本上属性名的转换规范就是将其写成驼峰写法，例如“background-color”变为“backgroundColor”, “font-size”变为“fontSize”，这和标准的JavaScript操作DOM样式的API是一致的。
## 使用自定义组件
在JSX中，我们不仅可以使用React自带div, input...这些虚拟DOM元素，还可以自定义组件。组件定义之后，也都可以利用XML语法去声明，而能够使用的XML Tag就是在当前JavaScript上下文的变量名，这一点非常好用，你不必再去考虑某个Tag是如何对应到相应的组件实现。例如React官方教程中的例子：
~~~
class HelloWorld extends React.Component{
render() {
return (
Hello, ! It is {this.props.date.toTimeString()}
); } }; setInterval(function() { React.render(（二）：React开发神器Webpack
最后更新于：2022-04-01 23:10:54
> 原文：http://www.infoq.com/cn/articles/react-and-webpack
> 作者：王沛
上一篇我们对React有了一个总体的认识，在介绍其中的技术细节之前，我们首先来了解一下用于React开发和模块管理的主流工具Webpack。称之为React开发神器有点标题党了，不过Webpack确实是笔者见过的功能最为强大的前端模块管理和打包工具。虽然Webpack是一个通用的工具，并不只适合于React，但是很多React的文章或者项目都使用了Webpack，尤其是[react-hot-loader](https://github.com/gaearon/react-hot-loader)这样的神器存在，让Webpack成为最主流的React开发工具。
CommonJS和AMD是用于JavaScript模块管理的两大规范，前者定义的是模块的同步加载，主要用于NodeJS；而后者则是异步加载，通过requirejs等工具适用于前端。随着npm成为主流的JavaScript组件发布平台，越来越多的前端项目也依赖于npm上的项目，或者自身就会发布到npm平台。因此，让前端项目更方便的使用npm上的资源成为一大需求。于是诞生了类似[browserify](http://browserify.org/)这样的工具，代码中可以使用require函数直接以同步语法形式引入npm模块，打包后再由浏览器执行。
Webpack其实有点类似browserify，出自Facebook的Instagram团队，但功能比browserify更为强大。其主要特性如下：
1. 同时支持[CommonJS](http://wiki.commonjs.org/wiki/Modules/1.1)和[AMD](https://github.com/amdjs/amdjs-api/wiki/AMD)模块（对于新项目，推荐直接使用CommonJS）；
2. 串联式模块加载器以及插件机制，让其具有更好的灵活性和扩展性，例如提供对CoffeeScript、ES6的支持；
3. 可以基于配置或者智能分析打包成多个文件，实现公共模块或者按需加载；
4. 支持对CSS，图片等资源进行打包，从而无需借助Grunt或Gulp；
5. 开发时在内存中完成打包，性能更快，完全可以支持开发过程的实时打包需求；
6. 对sourcemap有很好的支持，易于调试。
Webpack将项目中用到的一切静态资源都视之为模块，模块之间可以互相依赖。Webpack对它们进行统一的管理以及打包发布，其官方主页用下面这张图来说明Webpack的作用：
可以看到Webpack的目标就是对项目中的静态资源进行统一管理，为产品的最终发布提供最优的打包部署方案。本文就将围绕React对其相关用法做一个总体介绍，从而能让你将其应用在自己的实际项目之中。
**目录**
[TOC]
## 安装Webpack，并加载一个简单的React组件
Webpack一般作为全局的npm模块安装：
~~~
npm install -g webpack
~~~
之后便有了全局的webpack命令，直接执行此命令会默认使用当前目录的webpack.config.js作为配置文件。如果要指定另外的配置文件，可以执行：
~~~
webpack —config webpack.custom.config.js
~~~
尽管Webpack可以通过命令行来指定参数，但我们通常会将所有相关参数定义在配置文件中。一般我们会定义两个配置文件，一个用于开发时，另外一个用于产品发布。生产环境下的打包文件不需要包含sourcemap等用于开发时的代码。配置文件通常放在项目根目录之下，其本身也是一个标准的CommonJS模块。
一个最简单的Webpack配置文件webpack.config.js如下所示：
~~~
module.exports = {
entry:[
'./app/main.js'
],
output: {
path: __dirname + '/assets/',
publicPath: "/assets/",
filename: 'bundle.js'
}
};
~~~
其中entry参数定义了打包后的入口文件，数组中的所有文件会按顺序打包。每个文件进行依赖的递归查找，直到所有相关模块都被打包。output参数定义了输出文件的位置，其中常用的参数包括：
* **path**: 打包文件存放的绝对路径
* **publicPath**: 网站运行时的访问路径
* **filename**: 打包后的文件名
现在来看如何打包一个React组件。假设有如下项目文件夹结构：
~~~
- react-sample
+ assets/
- js/
Hello.js
entry.js
index.html
webpack.config.js
~~~
其中Hello.js定义了一个简单的React组件，使用ES6语法：
~~~
var React = require('react');
class Hello extends React.Component {
render() {
return (
';
Hello {this.props.name}!
); } } ~~~ entry.js是入口文件，将一个Hello组件输出到界面： ~~~ var React = require('react'); var Hello = require('./Hello'); React.render(（一）：React的设计哲学 – 简单之美
最后更新于：2022-04-01 23:10:51
> 原文：http://www.infoq.com/cn/articles/react-art-of-simplity
> 作者：王沛
> **编者按**：自2013年Facebook发布以来，React吸引了越来越多的开发者，基于它的衍生技术，如React Native、React Canvas等也层出不穷。InfoQ精心策划“深入浅出React”系列文章，为读者剖析React开发的技术细节。
React最初来自Facebook内部的广告系统项目，项目实施过程中前端开发遇到了巨大挑战，代码变得越来越臃肿且混乱不堪，难以维护。于是痛定思痛，他们决定抛开很多所谓的“最佳实践”，重新思考前端界面的构建方式，于是就有了React。
React带来了很多开创性的思路来构建前端界面，虽然选择React的最重要原因之一是性能，但是相关技术背后的设计思想更值得我们去思考。之前我也曾写过一篇React的[入门文章](http://www.infoq.com/cn/articles/subversion-front-end-ui-development-framework-react)，并提供了示例代码，大家可以结合参考。
**目录**
[TOC]
上个月React发布了最新的0.13版，并提供了对ES6的支持。在新版本中，一个小小的改变是React取消了函数的自动绑定，也就是说，以前可以这样去绑定一个事件：
~~~
~~~
而在以ES6语法定义的组件中，必须写为：
~~~
~~~
了解前端开发和JavaScript的同学都知道，做事件绑定时我们需要通过bind（或类似函数）来实现一个闭包以让事件处理函数自带上下文信息，这是由JavaScript语言特性决定的。而在0.13版本之前，React会自动在初始化时对组件的每一个方法做一次这样的绑定，类似于`this.func = this.func.bind(this)`，这样在JSX的事件绑定中就可以直接写为`onClick={this.handleSubmit}`。
表面上看自动绑定给开发带来了便利，而Facebook却[认为](http://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html)这破坏了JavaScript的语言习惯，其背后的神奇（Magic）逻辑或许会给初学者带来困惑，甚至开发者如果从React再转到其它库也可能会无所适从。基于同样的理由，React还取消了对mixin的支持，基于ES6的React组件不再能够以mixin的形式进行代码复用或者扩展。尽管这带来了很大不便，但Facebook认为mixin增加了代码的不可预测性，无法直观的去理解。关于mixin的思考，还可以参考[这篇文章](https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750)。
以简单直观、符合习惯的（idiomatic）方式去编程，让代码更容易被理解，从而易于维护和不断演进。这正是React的设计哲学。
## 编写可预测，符合习惯的代码
所谓可预测（predictable），即容易理解的代码。在年初的React开发者大会上，React项目经理Tom Occhino进一步阐述React诞生的[初衷](http://facebook.github.io/react/docs/conferences.html)，在演讲中提到，React最大的价值究竟是什么？是高性能虚拟DOM、服务器端Render、封装过的事件机制、还是完善的错误提示信息？尽管每一点都足以重要。但他指出，其实React最有价值的是声明式的，直观的编程方式。
软件工程向来不提倡用高深莫测的技巧去编程，相反，如何写出可理解可维护的代码才是质量和效率的关键。试想，一个月之后你回头看你写的代码，是否一眼就明白某个变量，某个if判断的含义；一个新加入的同事想去增加一个小小的新功能或是修复某个Bug，他是否对自己的代码有足够的信心不引入任何副作用？随着功能的增加，代码很容易变得越来越复杂，这些问题也将越来越严重，最终导致一份难以维护的代码。而React号称，新同事甚至在加入的第一天就能开始开发新功能。
那么React是如何做的呢？
## 使用JSX直观的定义用户界面
JSX是React的核心组成部分，它使用XML标记的方式去直接声明界面，界面组件之间可以互相嵌套。但是JSX给人的第一印象却是相当“丑陋”。当下面这样的例子被第一次展示的时候，甚至很多人称之为“巨大的退步（Huge Step Backwards）”：
~~~
var React = require('React');
var message =
{todo.text}
);
});
return (
';
Hello World
;
React.renderComponent(message, document.body);
~~~
将HTML直接嵌入到JavaScript代码中看上去确实是一件足够疯狂的事情。人们花了多年时间总结出的界面和业务逻辑相互分离的“最佳实践”就这么被彻底打破。那么React为何要如此另类？
模板出现的初衷是让非开发人员也能对界面做一定的修改。但这个初衷在当前Web程序里已完全不适用，每个模板背后的代码逻辑严重依赖模板中的内容和DOM结构，两者是紧密耦合的。即使做到文件位置的分离，实际上两者还是一体的，并且为了两者之间的协作而不得不引入很多机制和概念。以[Angularjs](https://angularjs.org/)的首页示例代码为例：
~~~
- {{todo.text}}
-
{lis}