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

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

深入浅出REACT(一)REACT的设计哲学简单之美编者按自2013年FACEBOOK发布以来，REACT吸引了越来越多的开发者，基于它的衍生技术，如REACTNATIVE、REACTCANVAS等也层出不穷。INFOQ精心策划“深入浅出REACT”系列文章，为读者剖析REACT开发的技术细节。REACT最初来自FACEBOOK内部的广告系统项目，项目实施过程中前端开发遇到了巨大挑战，代码变得越来越臃肿且混乱不堪，难以维护。于是痛定思痛，他们决定抛开很多所谓的“最佳实践”，重新思考前端界面的构建方式，于是就有了REACT。REACT带来了很多开创性的思路来构建前端界面，虽然选择REACT的最重要原因之一是性能，但是相关技术背后的设计思想更值得我们去思考。之前我也曾写过一篇REACT的入门文章，并提供了示例代码，大家可以结合参考。上个月REACT发布了最新的013版，并提供了对ES6的支持。在新版本中，一个小小的改变是REACT取消了函数的自动绑定，也就是说，以前可以这样去绑定一个事件而在以ES6语法定义的组件中，必须写为了解前端开发和JAVASCRIPT的同学都知道，做事件绑定时我们需要通过BIND(或类似函数)来实现一个闭包以让事件处理函数自带上下文信息，这是由JAVASCRIPT语言特性决定的。而在013版本之前，REACT会自动在初始化时对组件的每一个方法做一次这样的绑定，类似于THISFUNCTHISFUNCBINDTHIS，这样在JSX的事件绑定中就可以直接写为ONCLICK{THISHANDLE}。表面上看自动绑定给开发带来了便利，而FACEBOOK却认为这破坏了JAVASCRIPT的语言习惯，其背后的神奇(MAGIC)逻辑或许会给初学者带来困惑，甚至开发者如果从REACT再转到其它库也可能会无所适从。基于同样的理由，REACT还取消了对MIXIN的支持，基于ES6的REACT组件不再能够以MIXIN的形式进行代码复用或者扩展。尽管这带来了很大不便，但FACEBOOK认为MIXIN增加了代码的不可预测性，无法直观的去理解。关于MIXIN的思考，还可以参考这篇文章。以简单直观、符合习惯的(IDIOMATIC)方式去编程，让代码更容易被理解，从而易于维护和不断演进。这正是REACT的设计哲学。编写可预测，符合习惯的代码所谓可预测(PREDICTABLE)，即容易理解的代码。在年初的REACT开发者大会上，REACT项目经理TOMOCCHINO进一步阐述REACT诞生的初衷，在演讲中提到，REACT最大的价值究竟是什么是高性能虚拟DOM、服务器端RENDER、封装过的事件机制、还是完善的错误提示信息尽管每一点都足以重要。但他指出，其实REACT最有价值的是声明式的，直观的编程方式。软件工程向来不提倡用高深莫测的技巧去编程，相反，如何写出可理解可维护的代码才是质量和效率的关键。试想，一个月之后你回头看你写的代码，是否一眼就明白某个变量，某个IF判断的含义；一个新加入的同事想去增加一个小小的新功能或是修复某个BUG，他是否对自己的代码有足够的信心不引入任何副作用随着功能的增加，代码很容易变得越来越复杂，这些问题也将越来越严重，最终导致一份难以维护的代码。而REACT号称，新同事甚至在加入的第一天就能开始开发新功能。那么REACT是如何做的呢使用JSX直观的定义用户界面JSX是REACT的核心组成部分，它使用XML标记的方式去直接声明界面，界面组件之间可以互相嵌套。但是JSX给人的第一印象却是相当“丑陋”。当下面这样的例子被第一次展示的时候，甚至很多人称之为“巨大的退步(HUGESTEPBACKWARDS)”VARREACTREQUIRE‘REACT’VARMESSAGEHELLOWORLDREACTRENDERCOMPONENTMESSAGE,DOCUMENTBODY将HTML直接嵌入到JAVASCRIPT代码中看上去确实是一件足够疯狂的事情。人们花了多年时间总结出的界面和业务逻辑相互分离的“最佳实践”就这么被彻底打破。那么REACT为何要如此另类模板出现的初衷是让非开发人员也能对界面做一定的修改。但这个初衷在当前WEB程序里已完全不适用，每个模板背后的代码逻辑严重依赖模板中的内容和DOM结构，两者是紧密耦合的。即使做到文件位置的分离，实际上两者还是一体的，并且为了两者之间的协作而不得不引入很多机制和概念。以ANGULARJS的首页示例代码为例{{TODOTEXT}}尽管我们很容易看懂这一小段模板的含义，但你却无法开始写这样的代码，因为你需要学习这一整套语法。比如说，你得知道有NGREPEAT这样的标记的准确含义，其中的”TODOINTODOLISTTODOS”看上去是REPEAT语法的一部分，或许还有其它语法存在；可以看到有{{TODOTEXT}}这样的数据绑定，那么如果要对这段文本格式化(加一个ATTER)该怎么做；另外，NGMODEL背后又需要什么样的数据结构现在来看REACT怎么写这段逻辑//RENDERFUNCTION{VARLISTHISTODOLISTTODOSMAPFUNCTIONTODO{RETURN{TODOTEXT}}RETURN{LIS}}//可以看到，JSX中除了另类的HTML标记之外，并没有引入其它任何新的概念(事实上HTML标记也可以完全用JAVASCRIPT去写)。ANGULAR中的REPEAT在这里被一个简单的数组方法MAP所替代。在这里你可以利用熟悉的JAVASCRIPT语法去定义界面，在你的思维过程中其实已经不需要存在模板的概念，需要考虑的仅仅是如何用代码构建整个界面。这种自然而直观的方式直接降低了REACT的学习门槛并且让代码更容易理解。简化的组件模型所谓组件，其实就是状态机器组件并不是一个新的概念，它意味着某个独立功能或界面的封装，达到复用、或是业务逻辑分离的目的。而REACT却这样理解界面组件所谓组件，就是状态机器REACT将用户界面看做简单的状态机器。当组件处于某个状态时，那么就输出这个状态对应的界面。通过这种方式，就很容易去保证界面的一致性。在REACT中，你简单的去更新某个组件的状态，然后输出基于新状态的整个界面。REACT负责以最高效的方式去比较两个界面并更新DOM树。这种组件模型简化了我们思考的方式对组件的管理就是对状态的管理。不同于其它框架模型，REACT组件很少需要暴露组件方法和外部交互。例如，某个组件有只读和编辑两个状态。一般的思路可能是提供BEGINEDITING和ENDEDITING这样的方法来实现切换；而在REACT中，需要做的是SETSTATE{EDITINGTRUE/FALSE}。在组件的输出逻辑中负责正确展现当前状态。这种方式，你不需要考虑BEGINEDITING和ENDEDITING中应该怎样更新UI，而只需要考虑在某个状态下，UI是怎样的。显然后者更加自然和直观。组件是REACT中构建用户界面的基本单位。它们和外界的交互除了状态(STATE)之外，还有就是属性(PROPS)。事实上，状态更多的是一个组件内部去自己维护，而属性则由外部在初始化这个组件时传递进来(一般是组