深入浅出React(一)React的设计哲学-简单之美.docx

《深入浅出React(一)React的设计哲学-简单之美.docx》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、深入浅出React（一）：React的设计哲学-简单之美编者按：自2013年Facebook发布以来，React吸引了越来越多的开发者，基于它的衍生技术，如ReactNative、ReactCanvas等也层出不穷。InfoQ精心策划“深入浅出React”系列文章，为读者剖析React开发的技术细节。React最初来自Facebook内部的广告系统项目，项目实施过程中前端开发遇到了巨大挑战，代码变得越来越臃肿且混乱不堪，难以维护。于是痛定思痛，他们决定抛开很多所谓的“最佳实践”，重新思考前端界面的构建方式，于是就有了React。React带来了很多开创性的思路来构建前端界面，虽然选择

2、React的最重要原因之一是性能，但是相关技术背后的设计思想更值得我们去思考。之前我也曾写过一篇React的入门文章，并提供了示例代码，大家可以结合参考。上个月React发布了最新的0.13版，并提供了对ES6的支持。在新版本中，一个小小的改变是React取消了函数的自动绑定，也就是说，以前可以这样去绑定一个事件：Submit而在以ES6语法定义的组件中，必须写为：Submit了解前端开发

3、和JavaScript的同学都知道，做事件绑定时我们需要通过bind（或类似函数）来实现一个闭包以让事件处理函数自带上下文信息，这是由JavaScript语言特性决定的。而在0.13版本之前，React会自动在初始化时对组件的每一个方法做一次这样的绑定，类似于this.func=this.func.bind(this)，这样在JSX的事件绑定中就可以直接写为onClick={this.handleSubmit}。表面上看自动绑定给开发带来了便利，而Facebook却认为这破坏了JavaScript的语言习惯，其背后的神奇（Magic）逻辑或许会给初学者带来困惑，甚至开发者如果从Rea

4、ct再转到其它库也可能会无所适从。基于同样的理由，React还取消了对mixin的支持，基于ES6的React组件不再能够以mixin的形式进行代码复用或者扩展。尽管这带来了很大不便，但Facebook认为mixin增加了代码的不可预测性，无法直观的去理解。关于mixin的思考，还可以参考这篇文章。以简单直观、符合习惯的（idiomatic）方式去编程，让代码更容易被理解，从而易于维护和不断演进。这正是React的设计哲学。编写可预测，符合习惯的代码所谓可预测（predictable），即容易理解的代码。在年初的React开发者大会上，React项目经理TomOcchino进一步阐述

5、React诞生的初衷，在演讲中提到，React最大的价值究竟是什么？是高性能虚拟DOM、服务器端Render、封装过的事件机制、还是完善的错误提示信息？尽管每一点都足以重要。但他指出，其实React最有价值的是声明式的，直观的编程方式。软件工程向来不提倡用高深莫测的技巧去编程，相反，如何写出可理解可维护的代码才是质量和效率的关键。试想，一个月之后你回头看你写的代码，是否一眼就明白某个变量，某个if判断的含义；一个新加入的同事想去增加一个小小的新功能或是修复某个Bug，他是否对自己的代码有足够的信心不引入任何副作用？随着功能的增加，代码很容易变得越来越复杂，这些问题也将越来越严重，最终

6、导致一份难以维护的代码。而React号称，新同事甚至在加入的第一天就能开始开发新功能。那么React是如何做的呢？使用JSX直观的定义用户界面JSX是React的核心组成部分，它使用XML标记的方式去直接声明界面，界面组件之间可以互相嵌套。但是JSX给人的第一印象却是相当“丑陋”。当下面这样的例子被第一次展示的时候，甚至很多人称之为“巨大的退步（HugeStepBackwards）”：varReact=require(‘React’);varmessage=HelloWorld

7、>;React.renderComponent(message,document.body);将HTML直接嵌入到JavaScript代码中看上去确实是一件足够疯狂的事情。人们花了多年时间总结出的界面和业务逻辑相互分离的“最佳实践”就这么被彻底打破。那么React为何要如此另类？模板出现的初衷是让非开发人员也能对界面做一定的修改。但这个初衷在当前Web程序里已完全不适用，每个模板背后的代码逻辑严重依赖模板中的内容和DOM结构，两者是紧密耦合的。即使做到文件