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

深入浅出React (一)： React的设计哲学-简单之美 编者按：自2013年Facebook发布以來，React吸引了越来越多的开发者，基于它的衍生 技术，如React Native、React Canvas等也层出不穷。InfoQ精心策划“深入浅出React” 系列文章，为读者剖析React开发的技术细节。 React最初来自Facebook闪部的广告系统项目，项目实施过程屮前端开发遇到了巨人挑战， 代码变得越來越臃肿且混乱不堪，难以维护。于是痛定思痛，他们决定抛开很多所谓的“最 桂实践”，重新思考前端界而的构建方式，于是就有了 React。 React带来了很多开创性的思路来构建前端界而，虽然选择React的最重要原因之一是性能， 但是相关技术背后的设计思想更值得我们去思考。之前我也曾写过一篇React的入门文章， 并提供了示例代码，大家可以结合参考。 上个月React发布了最新的0.13版，并提供了对ES6的支持。在新版本中，一个小小的改 变是React取消了函数的自动绑定，也就是说，以前可以这样去绑定一个事件： 〈button onClick={this.handleSubmit}Submit〈/button 而在以ES6语法定义的组件中，必须写为： button onClick={this.handleSubmit.bind(this)}Submit/button 了解前端开发和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，他是否对 向己的代码有足够的信心不引入任何副作用？随着功能的增加，代码很容易变得越来越复杂, 这些M题也将越来越严重，最终导致一份难以维护的代码。而React号称，新同事甚至在 加入的第一天就能开始开发新功能。 那么React是如何做的呢？ 使用JSX直观的定义用户界面 JSX是React的核心组成部分，它使用XML标记的方式去直接声明界而，界而组件之间可 以互相肷套。但是JSX给人的第一印象却是相当“丑陋”。当下面这样的例子被第一次展示的 时候，甚至很多人称之为“巨大的退步(Huge Step Backwards) ”： var React = require(rReacV); var message = div class=frhello” onClick={someFunc} spanHello World/span /div; React.renderComponent(message, document.body); 将 直接嵌入到JavaScript代码中看上去确实是一件足够疯狂的事情。人们花了多年 时间总结出的界面和业务逻辑相互分离的最佳实践”就这么被彻底打破。那么React为何要 如此另类？ 模板出现的初衷是让非开发人员也能对界面做一定的修改。