Category Archives: Frontend

React Native之React速学教程(下)

本文出自《React Native学习笔记》系列文章。

React Native是基于React的，在开发React Native过程中少不了的需要用到React方面的知识。虽然官方也有相应的Document，但篇幅比较多，学起来比较枯燥。 通过《React Native之React速学教程》你可以对React有更系统和更深入的认识。为了方便大家学习，我将《React Native之React速学教程》分为上、中、下三篇，大家可以根据需要进行阅读学习。

View Details

深入浅出React（一）：React的设计哲学 – 简单之美

编者按：自2013年Facebook发布以来，React吸引了越来越多的开发者，基于它的衍生技术，如React Native、React Canvas等也层出不穷。InfoQ精心策划“深入浅出React”系列文章，为读者剖析React开发的技术细节。 React最初来自Facebook内部的广告系统项目，项目实施过程中前端开发遇到了巨大挑战，代码变得越来越臃肿且混乱不堪，难以维护。于是痛定思痛，他们决定抛开很多所谓的“最佳实践”，重新思考前端界面的构建方式，于是就有了React。 React带来了很多开创性的思路来构建前端界面，虽然选择React的最重要原因之一是性能，但是相关技术背后的设计思想更值得我们去思考。之前我也曾写过一篇React的入门文章，并提供了示例代码，大家可以结合参考。 上个月React发布了最新的0.13版，并提供了对ES6的支持。在新版本中，一个小小的改变是React取消了函数的自动绑定，也就是说，以前可以这样去绑定一个事件：

而在以ES6语法定义的组件中，必须写为：

了解前端开发和JavaScript的同学都知道，做事件绑定时我们需要通过bind（或类似函数）来实现一个闭包以让事件处理函数自带上下文信息，这是由JavaScript语言特性决定的。而在0.13版本之前，React会自动在初始化时对组件的每一个方法做一次这样的绑定，类似于this.func = this.func.bind(this)，这样在JSX的事件绑定中就可以直接写为onClick={this.handleSubmit}。 表面上看自动绑定给开发带来了便利，而Facebook却认为这破坏了JavaScript的语言习惯，其背后的神奇（Magic）逻辑或许会给初学者带来困惑，甚至开发者如果从React再转到其它库也可能会无所适从。基于同样的理由，React还取消了对mixin的支持，基于ES6的React组件不再能够以mixin的形式进行代码复用或者扩展。尽管这带来了很大不便，但Facebook认为mixin增加了代码的不可预测性，无法直观的去理解。关于mixin的思考，还可以参考这篇文章。 以简单直观、符合习惯的（idiomatic）方式去编程，让代码更容易被理解，从而易于维护和不断演进。这正是React的设计哲学。 编写可预测，符合习惯的代码 所谓可预测（predictable），即容易理解的代码。在年初的React开发者大会上，React项目经理Tom Occhino进一步阐述React诞生的初衷，在演讲中提到，React最大的价值究竟是什么？是高性能虚拟DOM、服务器端Render、封装过的事件机制、还是完善的错误提示信息？尽管每一点都足以重要。但他指出，其实React最有价值的是声明式的，直观的编程方式。 软件工程向来不提倡用高深莫测的技巧去编程，相反，如何写出可理解可维护的代码才是质量和效率的关键。试想，一个月之后你回头看你写的代码，是否一眼就明白某个变量，某个if判断的含义；一个新加入的同事想去增加一个小小的新功能或是修复某个Bug，他是否对自己的代码有足够的信心不引入任何副作用？随着功能的增加，代码很容易变得越来越复杂，这些问题也将越来越严重，最终导致一份难以维护的代码。而React号称，新同事甚至在加入的第一天就能开始开发新功能。 那么React是如何做的呢？ 使用JSX直观的定义用户界面 JSX是React的核心组成部分，它使用XML标记的方式去直接声明界面，界面组件之间可以互相嵌套。但是JSX给人的第一印象却是相当“丑陋”。当下面这样的例子被第一次展示的时候，甚至很多人称之为“巨大的退步（Huge Step Backwards）”：

将HTML直接嵌入到JavaScript代码中看上去确实是一件足够疯狂的事情。人们花了多年时间总结出的界面和业务逻辑相互分离的“最佳实践”就这么被彻底打破。那么React为何要如此另类？ 模板出现的初衷是让非开发人员也能对界面做一定的修改。但这个初衷在当前Web程序里已完全不适用，每个模板背后的代码逻辑严重依赖模板中的内容和DOM结构，两者是紧密耦合的。即使做到文件位置的分离，实际上两者还是一体的，并且为了两者之间的协作而不得不引入很多机制和概念。以Angularjs的首页示例代码为例：

尽管我们很容易看懂这一小段模板的含义，但你却无法开始写这样的代码，因为你需要学习这一整套语法。比如说，你得知道有ng-repeat这样的标记的准确含义，其中的”todo in todoList.todos”看上去是repeat语法的一部分，或许还有其它语法存在；可以看到有{{todo.text}}这样的数据绑定，那么如果要对这段文本格式化（加一个formatter）该怎么做；另外，ng-model背后又需要什么样的数据结构？ 现在来看React怎么写这段逻辑：

可以看到，JSX中除了另类的HTML标记之外，并没有引入其它任何新的概念（事实上HTML标记也可以完全用JavaScript去写）。Angular中的repeat在这里被一个简单的数组方法map所替代。在这里你可以利用熟悉的JavaScript语法去定义界面，在你的思维过程中其实已经不需要存在模板的概念，需要考虑的仅仅是如何用代码构建整个界面。这种自然而直观的方式直接降低了React的学习门槛并且让代码更容易理解。 简化的组件模型：所谓组件，其实就是状态机器 组件并不是一个新的概念，它意味着某个独立功能或界面的封装，达到复用、或是业务逻辑分离的目的。而React却这样理解界面组件： 所谓组件，就是状态机器 React将用户界面看做简单的状态机器。当组件处于某个状态时，那么就输出这个状态对应的界面。通过这种方式，就很容易去保证界面的一致性。 在React中，你简单的去更新某个组件的状态，然后输出基于新状态的整个界面。React负责以最高效的方式去比较两个界面并更新DOM树。 这种组件模型简化了我们思考的方式：对组件的管理就是对状态的管理。不同于其它框架模型，React组件很少需要暴露组件方法和外部交互。例如，某个组件有只读和编辑两个状态。一般的思路可能是提供beginEditing()和endEditing()这样的方法来实现切换；而在React中，需要做的是setState({editing: true/false})。在组件的输出逻辑中负责正确展现当前状态。这种方式，你不需要考虑beginEditing和endEditing中应该怎样更新UI，而只需要考虑在某个状态下，UI是怎样的。显然后者更加自然和直观。 组件是React中构建用户界面的基本单位。它们和外界的交互除了状态（state）之外，还有就是属性（props）。事实上，状态更多的是一个组件内部去自己维护，而属性则由外部在初始化这个组件时传递进来（一般是组件需要管理的数据）。React认为属性应该是只读的，一旦赋值过去后就不应该变化。关于状态和属性的使用在后续文章中还会深入探讨。 每一次界面变化都是整体刷新 数据模型驱动UI界面的两层编程模型从概念角度看上去是直观的，而在实际开发中却困难重重。一个数据模型的变化可能导致分散在界面多个角落的UI同时发生变化。界面越复杂，这种数据和界面的一致性越难维护。在Facebook内部他们称之为“Cascading Updates”，即层叠式更新，意味着UI界面之间会有一种互相依赖的关系。开发者为了维护这种依赖更新，有时不得不触发大范围的界面刷新，而其中很多并不真的需要。React的初衷之一就是，既然整体刷新一定能解决层叠更新的问题，那我们为什么不索性就每次都这么做呢？让框架自身去解决哪些局部UI需要更新的问题。这听上去非常有挑战，但React却做到了，实现途径就是通过虚拟DOM（Virtual DOM）。 关于虚拟DOM的原理我在去年底的文章有过比较详细的介绍，这里不再重复。简而言之就是，UI界面是一棵DOM树，对应的我们创建一个全局唯一的数据模型，每次数据模型有任何变化，都将整个数据模型应用到UI DOM树上，由React来负责去更新需要更新的界面部分。事实证明，这种方式不但简化了开发逻辑并且极大的提高了性能。 以这种思路出发，我们在考虑不断变化的UI界面时，仅仅需要整体考虑UI的构成。编程模型的简化带来的是代码的精简和易于理解，也即React不断提到的可预测（Predictable）的代码，代码的功能一目了然易于理解。Tom Occhino在2015 React开发者大会上也分享了React在Facebook内部的应用案例，随着新功能被不断的添加到系统中，开发进度非但没有变慢，甚至越来越快。 单向数据流动：Flux 既然已经有了组件机制去定义界面，那么还需要一定的机制来定义组件之间，以及组件和数据模型之间如何通信。为此，Facebook提出了Flux框架用于管理数据流。Flux是一个相当宽松的概念框架，同样符合React简单直观的原则。不同于其它大多数MVC框架的双向数据绑定，Flux提倡的是单向数据流动，即永远只有从模型到视图的数据流动。 Flux引入了Dispatcher和Action的概念：Dispatcher是一个全局的分发器负责接收Action，而Store可以在Dispatcher上监听到Action并做出相应的操作。简单的理解可以认为类似于全局的消息发布订阅模型。Action可以来自于用户的某个界面操作，比如点击提交按钮；也可以来自服务器端的某个数据更新。当数据模型发生变化时，就触发刷新整个界面。 Flux的定义非常宽松，除了Facebook自己的实现之外，社区中还出现了很多Flux的不同实现，各有特点，比较流行的包括Flexible, Reflux, Flummox等等。 让数据模型也变简单：Immutability Immutability含义是只读数据，React提倡使用只读数据来建立数据模型。这又是一个听上去相当疯狂的机制：所有数据都是只读的，如果需要修改它，那么你只能产生一份包含新的修改的数据。假设有如下数据：

如果要修改年龄，那么你需要产生一份新的数据：

这样，原来的employee对象并没有发生任何变化，相反，产生了一个新的updated对象，体现了年龄发生了变化。这时候需要把新的updated对象应用到界面组件上来进行界面的更新。 只读数据并不是Facebook的全新发明，而是起源于Clojure, Scala, Haskell等函数式编程语言。只读的数据可以让代码更加的安全和易于维护，你不再需要担心数据在某个角落被某段神奇的代码所修改；也就不必再为了找到修改的地方而苦苦调试。而结合React，只读数据能够让React的组件仅仅通过比较对象引用是否相等来决定自身是否要重新Render。这在复杂的界面上可以极大的提高性能。 针对只读数据，Facebook开发了一整套框架immutable.js，将只读数据的概念引入JavaScript，并且在github开源。如果不希望一开始就引入这样一个较大的框架，React还提供了一个工具类插件，帮助管理和操作只读数据：React.addons.update。 React思想的衍生：React Native, React Canvas等等 在前几天的Facebook F8开发者大会上，React Native终于众望所归的发布，它将React的思想延伸到了原生移动开发。它的口号是“Learn Once, Write Anywhere”，有React开发经验的开发人员将可以无缝的进行React Native开发。无论是组件化的思想，调试工具，动态代码加载等React具有的强大特性都可以应用在React Native。相信这会对以后的移动开发布局产生重要影响。 React对UI层进行了完美的抽象，写Web界面时甚至能够做到完全的去DOM化：开发者可以无需进行任何DOM操作。因此，这也让对UI层进行整体替换成为了可能。React Native正是将浏览器基于DOM的UI层换成了iOS或者Android的原生控件。而Flipboard则将UI层换成了Canvas。 React Canvas是Flipboard出品的一套前端框架，所有的界面元素都通过Canvas来绘制，infoQ之前也有文章对其进行了介绍。Flipboard追求极致的性能和用户体验，因此对浏览器的缓慢DOM操作深恶痛绝，不惜大刀阔斧彻底舍弃了DOM，而完全用Canvas实现了整套UI控件。有兴趣的同学不妨一试。 小结 React并不是突然从哪里蹦出来，而是为了解决前端开发中的痛点而生。以简单为原则设计也决定了React具有极其平缓的学习曲线，开发者可以快速上手并应用到实际项目中。本文总结分析了其相关技术背后的设计思想，希望通过这个角度能让大家对React有一个总体的认识，从而在React的实际项目开发中，遵循简单直观的原则，进行高效率高质量的产品开发。 参考资料 React官方网站：http://facebook.github.io/react/ React博客：http://facebook.github.io/react/blog/ React入门：http://ryanclark.me/getting-started-with-react/ 颠覆式前端UI框架：React：http://www.infoq.com/cn/articles/subversion-front-end-ui-development-framework-react Immutable.js: http://facebook.github.io/immutable-js/ […]

View Details

深入浅出React（二）：React开发神器Webpack

编者按：自2013年Facebook发布以来，React吸引了越来越多的开发者，基于它的衍生技术，如React Native、React Canvas等也层出不穷。InfoQ精心策划“深入浅出React”系列文章，为读者剖析React开发的技术细节。 上一篇我们对React有了一个总体的认识，在介绍其中的技术细节之前，我们首先来了解一下用于React开发和模块管理的主流工具Webpack。称之为React开发神器有点标题党了，不过Webpack确实是笔者见过的功能最为强大的前端模块管理和打包工具。虽然Webpack是一个通用的工具，并不只适合于React，但是很多React的文章或者项目都使用了Webpack，尤其是react-hot-loader这样的神器存在，让Webpack成为最主流的React开发工具。 CommonJS和AMD是用于JavaScript模块管理的两大规范，前者定义的是模块的同步加载，主要用于NodeJS；而后者则是异步加载，通过requirejs等工具适用于前端。随着npm成为主流的JavaScript组件发布平台，越来越多的前端项目也依赖于npm上的项目，或者自身就会发布到npm平台。因此，让前端项目更方便的使用npm上的资源成为一大需求。于是诞生了类似browserify这样的工具，代码中可以使用require函数直接以同步语法形式引入npm模块，打包后再由浏览器执行。 Webpack其实有点类似browserify，出自Facebook的Instagram团队，但功能比browserify更为强大。其主要特性如下： 同时支持CommonJS和AMD模块（对于新项目，推荐直接使用CommonJS）； 串联式模块加载器以及插件机制，让其具有更好的灵活性和扩展性，例如提供对CoffeeScript、ES6的支持； 可以基于配置或者智能分析打包成多个文件，实现公共模块或者按需加载； 支持对CSS，图片等资源进行打包，从而无需借助Grunt或Gulp； 开发时在内存中完成打包，性能更快，完全可以支持开发过程的实时打包需求； 对sourcemap有很好的支持，易于调试。 Webpack将项目中用到的一切静态资源都视之为模块，模块之间可以互相依赖。Webpack对它们进行统一的管理以及打包发布，其官方主页用下面这张图来说明Webpack的作用： 可以看到Webpack的目标就是对项目中的静态资源进行统一管理，为产品的最终发布提供最优的打包部署方案。本文就将围绕React对其相关用法做一个总体介绍，从而能让你将其应用在自己的实际项目之中。 安装Webpack，并加载一个简单的React组件 Webpack一般作为全局的npm模块安装：

之后便有了全局的webpack命令，直接执行此命令会默认使用当前目录的webpack.config.js作为配置文件。如果要指定另外的配置文件，可以执行：

尽管Webpack可以通过命令行来指定参数，但我们通常会将所有相关参数定义在配置文件中。一般我们会定义两个配置文件，一个用于开发时，另外一个用于产品发布。生产环境下的打包文件不需要包含sourcemap等用于开发时的代码。配置文件通常放在项目根目录之下，其本身也是一个标准的CommonJS模块。 一个最简单的Webpack配置文件webpack.config.js如下所示：

其中entry参数定义了打包后的入口文件，数组中的所有文件会按顺序打包。每个文件进行依赖的递归查找，直到所有相关模块都被打包。output参数定义了输出文件的位置，其中常用的参数包括： path: 打包文件存放的绝对路径 publicPath: 网站运行时的访问路径 filename: 打包后的文件名 现在来看如何打包一个React组件。假设有如下项目文件夹结构：

其中Hello.js定义了一个简单的React组件，使用ES6语法：

entry.js是入口文件，将一个Hello组件输出到界面：

index.html的内容如下：

在这里Hello.js和entry.js都是JSX组件语法，需要对它们进行预处理，这就要引入webpack的JSX加载器。因此在配置文件中加入如下配置：

加载器的概念稍后还会详细介绍，这里只需要知道它能将JSX编译成JavaScript并加载为Webpack模块。这样在当前目录执行webpack命令之后，在assets目录将生成bundle.js，打包了entry.js的内容。当浏览器打开当前服务器上的index.html，将显示“Hello Nate!”。这是一个非常简单的例子，演示了如何使用Webpack来进行最简单的React组件打包。 加载AMD或CommonJS模块 在实际项目中，代码以模块进行组织，AMD是在CommonJS的基础上考虑了浏览器的异步加载特性而产生的，可以让模块异步加载并保证执行顺序。而CommonJS的require函数则是同步加载。在Webpack中笔者更加推荐CommonJS方式去加载模块，这种方式语法更加简洁直观。即使在开发时，我们也是加载Webpack打包后的文件，通过sourcemap去进行调试。 除了项目本身的模块，我们也需要依赖第三方的模块，现在比较常用的第三方模块基本都通过npm进行发布，使用它们已经无需单独下载管理，需要时执行npm install即可。例如，我们需要依赖jQuery，只需执行：

更多情况下我们是在项目的package.json中进行依赖管理，然后通过直接执行npm install来安装所有依赖。这样在项目的代码仓库中并不需要存储实际的第三方依赖库的代码。 安装之后，在需要使用jquery的模块中需要在头部进行引入：

可以看到，这种以CommonJS的同步形式去引入其它模块的方式代码更加简洁。浏览器并不会实际的去同步加载这个模块，require的处理是由Webpack进行解析和打包的，浏览器只需要执行打包后的代码。Webpack自身已经可以完全处理JavaScript模块的加载，但是对于React中的JSX语法，这就需要使用Webpack的扩展加载器来处理了。 Webpack开发服务器 除了提供模块打包功能，Webpack还提供了一个基于Node.js Express框架的开发服务器，它是一个静态资源Web服务器，对于简单静态页面或者仅依赖于独立服务的前端页面，都可以直接使用这个开发服务器进行开发。在开发过程中，开发服务器会监听每一个文件的变化，进行实时打包，并且可以推送通知前端页面代码发生了变化，从而可以实现页面的自动刷新。 Webpack开发服务器需要单独安装，同样是通过npm进行：

之后便可以运行webpack-dev-server命令来启动开发服务器，然后通过localhost:8080/webpack-dev-server/访问到页面了。默认情况下服务器以当前目录作为服务器目录。在React开发中，我们通常会结合react-hot-loader来使用开发服务器，因此这里不做太多介绍，只需要知道有这样一个开发服务器可以用于开发时的内容实时打包和推送。详细配置和用法可以参考官方文档。 Webpack模块加载器（Loaders） Webpack将所有静态资源都认为是模块，比如JavaScript，CSS，LESS，TypeScript，JSX，CoffeeScript，图片等等，从而可以对其进行统一管理。为此Webpack引入了加载器的概念，除了纯JavaScript之外，每一种资源都可以通过对应的加载器处理成模块。和大多数包管理器不一样的是，Webpack的加载器之间可以进行串联，一个加载器的输出可以成为另一个加载器的输入。比如LESS文件先通过less-load处理成css，然后再通过css-loader加载成css模块，最后由style-loader加载器对其做最后的处理，从而运行时可以通过style标签将其应用到最终的浏览器环境。 对于React的JSX也是如此，它通过jsx-loader来载入。jsx-loader专门用于载入React的JSX文件，Webpack的加载器支持参数，jsx-loader就可以添加?harmony参数使其支持ES6语法。为了让Webpack识别什么样的资源应该用什么加载器去载入，需要在配置文件进行配置：通过正则表达式对文件名进行匹配。例如：

可以看到，该使用什么加载器完全取决于这里的配置，即使对于JSX文件，我们也可以用js作为后缀，从而所有的JavaScript都可以通过jsx-loader载入，因为jsx本身就是完全兼容JavaScript的，所以即使没有JSX语法，普通JavaScript模块也可以使用jsx-loader来载入。 加载器之间的级联是通过感叹号来连接，例如对于LESS资源，写法为style-loader!css-loader!less-loader。对于小型的图片资源，也可以将其进行统一打包，由url-loader实现，代码中url-loader?limit=8192含义就是对于所有小于8192字节的图片资源也进行打包。这在一定程度上可以替代Css Sprites方案，用于减少对于小图片资源的HTTP请求数量。 除了已有加载器，你也可以自己实现自己的加载器，从而可以让Webpack统一管理项目特定的静态资源。现在也已经有很多第三方的加载器实现常见静态资源的打包管理，可以参考Webpack主页上的加载器列表。 React开发神器：react-hot-loader Webpack本身具有运行时模块替换功能，称之为Hot Module Replacement (HMR)。当某个模块代码发生变化时，Webpack实时打包将其推送到页面并进行替换，从而无需刷新页面就实现代码替换。这个过程相对比较复杂，需要进行多方面考虑和配置。而现在针对React出现了一个第三方react-hot-loader加载器，使用这个加载器就可以轻松实现React组件的热替换，非常方便。其实正是因为React的每一次更新都是全局刷新的虚拟DOM机制，让React组件的热替换可以成为通用的加载器，从而极大提高开发效率。 要使用react-hot-loader，首先通过npm进行安装：

之后，Webpack开发服务器需要开启HMR参数hot，为了方便，我们创建一个名为server.js的文件用以启动Webpack开发服务器：

为了热加载React组件，我们需要在前端页面中加入相应的代码，用以接收Webpack推送过来的代码模块，进而可以通知所有相关React组件进行重新Render。加入这个代码很简单：

需要注意的是，这里的client?http://127.0.0.1:3000需要和在server.js中启动Webpack开发服务器的地址匹配。这样，打包生成的文件就知道该从哪里去获取动态的代码更新。下一步，我们需要让Webpack用react-hot-loader去加载React组件，如上一节所介绍，这通过加载器配置完成：

做完这些配置之后，使用Node.js运行server.js：

即可启动开发服务器并实现React组件的热加载。为了方便，我们也可以在package.json中加入一节配置：

从而通过npm start命令即可启动开发服务器。示例代码也上传在Github上，大家可以参考。 这样，React的热加载开发环境即配置完成，任何修改只要以保存，就会在页面上立刻体现出来。无论是对样式修改，还是对界面渲染的修改，甚至事件绑定处理函数的修改，都可以立刻生效，不得不说是提高开发效率的神器。 将Webpack开发服务器集成到已有服务器 尽管Webpack开发服务器可以直接用于开发，但实际项目中我们可能必须使用自己的Web服务器。这就需要我们能将Webpack的服务集成到已有服务器，来使用Webpack提供的模块打包和加载功能。要实现这一点其实非常容易，只需要在载入打包文件时指定完整的URL地址，例如：

这就告诉当前页面应该去另外一个服务器获得脚本资源文件，在之前我们已经在配置文件中指定了开发服务器的地址，因此打包后的文件也知道应该通过哪个地址去建立Socket […]

View Details

深入浅出React（三）：理解JSX和组件

编者按：自2013年Facebook发布以来，React吸引了越来越多的开发者，基于它的衍生技术，如React Native、React Canvas等也层出不穷。InfoQ精心策划“深入浅出React”系列文章，为读者剖析React开发的技术细节。 通过前两篇文章的介绍，相信大家对JSX和组件已经有了一定的了解。JSX这种混合使用JavaScript和XML的语言第一眼看上去很“丑”，也很神奇，但是其语法和背后的逻辑却极其简单。相信读完本文你就可以对JSX和组件有一个全面的了解，并能够用JSX来直观的构造用户界面。 什么是JSX React的核心机制之一就是虚拟DOM：可以在内存中创建的虚拟DOM元素。React利用虚拟DOM来减少对实际DOM的操作从而提升性能。类似于真实的原生DOM，虚拟DOM也可以通过JavaScript来创建，例如：

使用这样的机制，我们完全可以用JavaScript构建完整的界面DOM树，正如我们可以用JavaScript创建真实DOM。但这样的代码可读性并不好，于是React发明了JSX，利用我们熟悉的HTML语法来创建虚拟DOM：

这两段代码是完全等价的，后者将XML语法直接加入到JavaScript代码中，让你能够高效的通过代码而不是模板来定义界面。之后JSX通过翻译器转换到纯JavaScript再由浏览器执行。在实际开发中，JSX在产品打包阶段都已经编译成纯JavaScript，JSX的语法不会带来任何性能影响。另外，由于JSX只是一种语法，因此JavaScript的关键字class, for等也不能出现在XML中，而要如例子中所示，使用className, htmlFor代替，这和原生DOM在JavaScript中的创建也是一致的。 因此，JSX本身并不是什么高深的技术，可以说只是一个比较高级但很直观的语法糖。它非常有用，却不是一个必需品，没有JSX的React也可以正常工作：只要你乐意用JavaScript代码去创建这些虚拟DOM元素。 为什么使用JSX 前端界面的最基本功能在于展现数据，为此大多数框架都使用了模板引擎，例如在AngularJS中：

在EmberJS中：

在Knockoutjs中：

模板可以直观的定义UI来展现Model中的数据，你不必手动的去拼出一个很长的HTML字符串，几乎每种框架都有自己的模板引擎。传统MVC框架强调界面展示逻辑和业务逻辑的分离，因此为了应对复杂的展示逻辑需求，这些模板引擎几乎都不可避免的需要发展成一门独立的语言，如上面代码所示，每个框架都有自己的模板语言语法。而这无疑增加了框架的门槛和复杂度。 如果说掌握一种模板语言并不是很大的问题，那么其实由模板带来的架构复杂性则是让框架也变得复杂的重要原因之一，例如： 模板需要对应数据模型，即上下文，如何去绑定和实现？ 模板可以嵌套，不同部分界面可能来自不同数据模型，如何处理？ 模板语言终究是一个轻量级语言，为了满足项目需求，你很可能需要扩展模板引擎的功能。 为了解决这些复杂度，框架本身需要精心的设计，以及创造新的概念（例如Angular的Directive）。这些都会让框架变得复杂和难以掌握，不仅增加了开发成本，各种难以调试的Bug还会降低开发质量。 正因为如此，React直接放弃了模板而发明了JSX。看上去很像模板语言，但其本质是通过代码来构建界面，这使得我们不再需要掌握一门新的语言就可以直观的去定义用户界面：掌握了JavaScript就已经掌握了JSX。这里不妨再引用之前文章举过的例子，在展示一个列表时，模板语言通常提供名为Repeat的语法，例如在Angular中：

而使用JSX，则代码如下：

可以看到，JSX完美利用了JavaScript自带的语法和特性，我们只要记住HTML只是代码创建DOM的一种语法形式，就很容易理解JSX。而这种使用代码构建界面的方式，完全消除了业务逻辑和界面元素之间的隔阂，让代码更加直观和易于维护。 JSX的语法 JSX本身就和XML语法类似，可以定义属性以及子元素。唯一特殊的是可以用大括号来加入JavaScript表达式，例如：

一般每个组件都定义了一组属性（props，properties的简写）接收输入参数，这些属性通过XML标记的属性来指定。大括号中的语法就是纯JavaScript表达式，返回值会赋予组件的对应属性，因此可以使用任何JavaScript变量或者函数调用。上述代码经过JSX编译后会得到：

对于子元素也是类似，大括号中使用JavaScript表达式来返回需要展现的元素，例如文章开头提到的例子使用JSX可以写成：

既然大括号中是JavaScript，而JSX又允许在JavaScript中使用XML，因此在大括号中仍然可以使用XML来声明组件，不断递归使用。 如果需要展现一组子节点，只需表达式返回一个JavaScript数组，数组的每个元素都是一个React组件，例如上一节的例子，其中lis就是有多个“li”元素的数组。：

在JSX中使用事件 如果你在90年代写过HTML，那么也许会有点怀念那时的事件绑定是多么的直观和简单：

那时的JavaScript应用范围非常有限，最有用的也许就是做表单有效性验证。因为逻辑都很简单，直接写到HTML中并没有问题，而且这种方式非常直观易读。但是现在因为Web程序变的越来越复杂，我们就需要使用JavaScript来绑定事件，例如在jQuery中：

在看到这段事件绑定和验证逻辑之前，你无法直观的看到有事件绑定在某个元素上，这种隐藏的界面元素和业务逻辑的耦合是很多Bug和内存泄露产生的根源。幸运的是，现在JSX可以让事件绑定返璞归真：

和原生HTML定义事件的唯一区别就是JSX采用驼峰写法来描述事件名称，大括号中仍然是标准的JavaScript表达式，返回一个事件处理函数。在JSX中你不需要关心什么时机去移除事件绑定，因为React会在对应的真实DOM节点移除时就自动解除了事件绑定。 React并不会真正的绑定事件到每一个具体的元素上，而是采用事件代理的模式：在根节点document上为每种事件添加唯一的Listener，然后通过事件的target找到真实的触发元素。这样从触发元素到顶层节点之间的所有节点如果有绑定这个事件，React都会触发对应的事件处理函数。这就是所谓的React模拟事件系统。 尽管整个事件系统由React管理，但是其API和使用方法与原生事件一致。这种机制确保了跨浏览器的一致性：在所有浏览器（IE8及以上）都可以使用符合W3C标准的API，包括stopPropagation()，preventDefault()等等。对于事件的冒泡（bubble）和捕获（capture）模式也都完全支持。 在JSX中使用样式 尽管在大部分场景下我们应该将样式写在独立的CSS文件中，但是有时对于某个特定组件而言，其样式相当简单而且独立，那么也可以将其直接定义在JSX中。在JSX中使用样式和真实的样式也很类似，通过style属性来定义，但和真实DOM不同的是，属性值不能是字符串而必须为对象，例如：

乍一看，这段JSX中的大括号是双的，有点奇怪，但实际上里面的大括号只是标准的JavaScript对象表达式，外面的大括号是JSX的语法。所以，样式你也可以先赋值给一个变量，然后传进去，代码会更易读：

在JSX中可以使用所有的的样式，基本上属性名的转换规范就是将其写成驼峰写法，例如“background-color”变为“backgroundColor”, “font-size”变为“fontSize”，这和标准的JavaScript操作DOM样式的API是一致的。 使用自定义组件 在JSX中，我们不仅可以使用React自带div, input…这些虚拟DOM元素，还可以自定义组件。组件定义之后，也都可以利用XML语法去声明，而能够使用的XML Tag就是在当前JavaScript上下文的变量名，这一点非常好用，你不必再去考虑某个Tag是如何对应到相应的组件实现。例如React官方教程中的例子：

其中声明了一个名为HelloWorld的组件，那么就可以在XML中使用<HellWorld />，这个Tag就是JavaScript变量名，我们可以用任意变量名：

甚至，我们还可以引入命名空间：

这些语法看上去有点怪，但是如果我们记住JSX语法只是JavaScript语法的一个语法映射，那么这些就非常容易理解了。 组件的概念和生命周期 React使用组件来封装界面模块，整个界面就是一个大组件，开发过程就是不断优化和拆分界面组件、构造整个组件树的过程。可以认为组件类似于其他框架中Widget（或Control）的概念，但又有所不同。React中的界面一切皆为组件，而Widget一般只是嵌入到界面中为完成某个功能的独立模块。 如下图，整个页面是一个大的组件，然后再将其拆分成很多小的组件。组件机制加上JSX的语法，让你在构造界面时就像有一套符合项目需求的HTML标记，界面定义变得非常直观。 组件自身定义了一组props作为对外接口，展示一个组件时只需要指定props作为XML节点的属性。组件很少需要对外公开方法，唯一的交互途径就是props。这使得使用组件就像使用函数一样简单，给定一个输入，组件给定一个界面输出。当给予的参数一定时，那么输出也是一定的。而传统控件通常提供很多方法让你在外部改变控件的状态和行为，当控件的状态在不同场景不同逻辑中可以被随意控制时，开发和调试也会变得复杂。 而React组件通过唯一的props接口避免了逻辑复杂性，让开发测试都更加容易。这种特性完全得益于虚拟DOM机制，让你可以每次props改变都能以整体刷新页面的思路去考虑界面展现逻辑。 如果整个项目完全采用React，那么界面上就只有一个组件根节点；如果局部使用React，那么每个局部使用的部分都有一个根节点。在Render时，根节点由React.render函数去触发：

而所有的子节点则都是通过父节点的render方法去构造的。每个组件都会有一个render方法，这个方法返回组件的实例，最终整个界面得到一个虚拟DOM树，再由React以最高效的方式展现在界面上。 除了props之外，组件还有一个很重要的概念：state。组件规范中定义了setState方法，每次调用时都会更新组件的状态，触发render方法。需要注意，render方法是被异步调用的，这可以保证同步的多个setState方法只会触发一次render，有利于提高性能。和props不同，state是组件的内部状态，除了初始化时可能由props来决定，之后就完全由组件自身去维护。在组件的整个生命周期中，React强烈不推荐去修改自身的props，因为这会破坏UI和Model的一致性，props只能够由使用者来决定。 对于自定义组件，唯一必须实现的方法就是render()，除此之外，还有一些方法会在组件生命周期中被调用，如下图所示： 图中的方法几乎已经包括了React的所有API，自定义组件时根据需要在组件生命周期的不同阶段实现不同的逻辑。除了必须的render方法之外，其它常用的方法包括： componentDidMount: 在组件第一次render之后调用，这时组件对应的DOM节点已被加入到浏览器。在这个方法里可以去实现一些初始化逻辑。 componentWillUnmount: 在DOM节点移除之后被调用，这里可以做一些相关的清理工作。 shouldComponentUpdate: 这是一个和性能非常相关的方法，在每一次render方法之前被调用。它提供了一个机会让你决定是否要对组件进行实际的render。例如：

当此函数返回false时，组件就不会调用render方法从而避免了虚拟DOM的创建和内存中的Diff比较，从而有助于提高性能。当返回true时，则会进行正常的render的逻辑。 […]

View Details