别责怪框架：我使用 AngularJS 和 ReactJS 的经验 - WEB前端 - 伯乐在线
& 别责怪框架：我使用 AngularJS 和 ReactJS 的经验
在过去的几年里，网站进化成了复杂的网页应用。曾经的互联网只涉及到简单的商业信息展现，而如今，看看 Facebook、Slack、Spotify 以及 Netflix，互联网正在改变你的社交和生活方式。随着互联网的发展，前端开发这个行业达到了全新的高度，并得到了前所未有的重视。
就像大多数前端开发者那样，我们的技术栈曾经由 HTML 和 jQuery 构成。我们使用 AJAX 请求从后端获取数据，使用 JavaScript 渲染新的 UI 元素然后将它插入到 DOM 中去，用户交互通过事件绑定和回调函数来实现。不要误解我，我不反对上面那种方式，它们今天依然适合于大多数 Web 应用。
然而，当一个应用的复杂度大幅度增加，开始出现得比预期的更频繁：你可能数据更新了，但漏掉了更新某一处展现，你通过 Ajax 获取和更新了内容，但没有绑定事件，还有另外一些问题，把这些全部列出来会是个很长的清单。这些问题让你的代码逐渐变得不可维护，尤其是在多人协作团队开发的项目中。这时候，你就需要使用前端框架来为你解决多人协作开发的种种问题了。
1. React 福音
当我们的团队开始寻找一个合适的前端框架的时候，我们考虑了许多选择，最后留下两个选项 ——
Angular 是目前为止最成熟的方案：它拥有一个庞大的社区，你可以为大部分应用场景找到合适的第三方模块。
React 也很有竞争力，它以 JavaScript 为中心的设计看起来很有前途，而且它性能很好。虽然它还是 Beta 版本，但是 “由Facebook团队开发的” 这一点给它的竞争力加分。
我们决定给 React 一个机会，选择了使用它。
最初使用 React 让人感觉棒极了，我们可以用 JavaScript 来做一切：展现一段 HTML，通过遍历数组渲染一个列表，优雅地改变一个变量的值，然后看着它通过
传播到各处，更新要更新的内容到里，然后一切就绪了，没有一坨一坨的代码，只有真正的。React 解决了我们在团队开发中编写可维护代码的诉求。
2. React + Flux = ?
但沿着这条路走下去，我们发现并不是一切都很美好。我们遇到的第一个大挑战就曾让我们考虑是否应该放弃 React —— 我们陷入了回调迷宫。
由于 React 的单向数据流性质，如果子组件需要更新父组件的状态，父组件就要。这咋看起来没有什么大不了的，然而如果你的组件要更新 root 组件的状态，你就不得不将 “this.props.updateCallback” 沿着数据流一层一层传递下来。
尽管如此，我们喜欢 React，继续使用它完成我们的工作。通过努力，我们找到了 ，它是一种规范化单向数据流的架构思想。它由构成。
Store: 负责存储数据和应用状态。
Action: 触发状态改变。
Dispatcher: 管理 action 并将它们导向对应的 store。
View: 展现 store 中的数据，派发 action – 这块是 React 中已有的。
采用 Flux，我们就不用将状态保存在 root 组件中，然后将 update 回调一层层传递给它的子组件。React 组件通过 store 直接获得数据，通过调用 action 来改变状态：这样简单、优雅，不会让你抓狂。Flux 补充了可预测的行为和一些标准到被 React 框架约束的代码中。
3. 狂野的 Angular 出场……
……它采用以 HTML 为中心的代码且。
最近，我开始参与一个 Angular 项目。我加入的时候这个项目已经完成了很大一部分了，所以不得不用 Angular，没有回头路。作为一个忠实的 React 开发者，我吐槽 Angular。当我开始写第一行 Angular 代码的时候，我就真心诅咒它。这就是所谓的：。
我不能自欺欺人，在一开始，我写 Angular 代码一点也不开心。将框架定义的属性（或者，更恰当地说法是 directives）写入到 HTML 中的做法让我感觉很不爽。我得费很大劲才能实现很简单的功能，比如 或者渲染基础模板。
当我在表单中遇到一个由于
directive 创建一个新的子域而导致的问题时，我处理起来还是很费劲。还有当我想要从一个准备发送给服务器的 JSON 中移除一些空白字段时，我发现 UI 中对应的数据也被一并移除了 —— 丫的双向绑定 ╮(╯▽╰)╭。还有当我想要使用
来显示一个 HTML 块同时隐藏另一个 HTML 块时，在一瞬间，两者同时显示了。我明白许多问题是我自己的问题，而我想要指出的是，Angular是不可预测的，使用它的时候会遇上各种各样的坑。
当然，Angular 还是善于处理很多事情的。 非常棒，对 promise 的支持也很好。另一个我无法吐槽的好东西是：，它为 input 字段提供了默认的格式化、解析和校验，而且还提供了一个很好的插件用来展示错误信息。
使用 Angular 也能让开发团队与页面制作团队协同工作变得更简单。在我们团队，有专门的页面重构工程师负责写 HTML 和 CSS，Angular 能让我们的工作无缝对接：重构工程师负责 HTML 和一些额外的标签，我负责处理逻辑。如果我们使用的是 React，那么至少让重构工程师写组件会是一个挑战，要么得让他学会写基本的 JSX，要么我就只能自己将他写的 HTML 复制粘贴到 JSX 中。
还记得前面提到的 URL 替换和模板渲染问题吗？其实没关系，人们通常使用第三方的路由库()它们比标准的 ()要好用。最后，Angular 也没有我之前认为的那样糟糕。之前的大多数抱怨要么是因为我习惯了 React 思维，要么是我还不够专业。
4. 总结: AngularJS 与 ReactJS
React 使用原生 JavaScript 函数让开发者可以创建一个有固定生命周期的、单向数据流的可复用组件。React 与 Flux 架构（或者受 Flux 启发而产生的其他架构，比如 Redux）相结合，能让团队长期维护一个项目变得更加容易，使用它不用担心解决一个 bug 会引入更多新 bug。但是，如果你的团队有专门写 HTML 和 CSS 的人，React 会带来额外的学习成本，因为它改变了传统的开发流程。而且 React 的效果还非常依赖你选择的组成你的应用的模块。
另一方面，Angular 专注于设计简单的双向数据绑定，当你改变 controller scope 中的内容，变化将会被自动地同步到UI（效果如同魔法般）。它自认为节省了配置的时间，开发者不用像传统开发模式那样考虑用各种设计模式组织代码然后从上百种可选的方案中选出一个核心模块。使用双向绑定为开发带来了便利，然而它也容易在长期维护的过程中由于修改部分代码而产生不可预期的 bug，尤其是那些在过去的几个月中没有再动过的代码。
那么，我从头开始创建 app 的首选方案是什么呢？
从长远而言，我个人倾向于选择 React，使用
架构，使用
支持 promise-ready 的 HTTP 请求，以及使用
处理路由。不过，这也取决于团队的经验：如果有专门写 HTML 和 CSS 的人，我肯定会选择 Angular。两个框架都各有利弊，从构建可维护项目的目的来考虑，最关键的还是如何让小伙伴们写出好代码。
打赏支持我翻译更多好文章，谢谢！
打赏支持我翻译更多好文章，谢谢！
任选一种支付方式
关于作者：
可能感兴趣的话题
关于伯乐前端
伯乐前端分享Web前端开发，包括JavaScript，CSS和HTML5开发技术，前端相关的行业动态。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线966,690 十二月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
颠覆式前端UI开发框架：React
颠覆式前端UI开发框架：React
欲知区块链、VR、TensorFlow等潮流技术和框架，请锁定
相关厂商内容
如果你像在90年代那样写过服务器端Render的纯Web页面那么应该知道，服务器端所要做的就是根据数据Render出HTML送到浏览器端。如果这时因为用户的一个点击需要改变某个状态文字，那么也是通过刷新整个页面来完成的。服务器端并不需要知道是哪一小段HTML发生了变化，而只需要根据数据刷新整个页面。换句话说，任何UI的变化都是通过整体刷新来完成的。而React将这种开发模式以高性能的方式带到了前端，每做一点界面的更新，你都可以认为刷新了整个页面。至于如何进行局部更新以保证性能，则是React框架要完成的事情。
借用中聊天应用的例子，当一条新的消息过来时，传统开发的思路如上图，你的开发过程需要知道哪条数据过来了，如何将新的DOM结点添加到当前DOM树上；而基于React的开发思路如下图，你永远只需要关心数据整体，两次数据之间的UI如何变化，则完全交给框架去做。
可以看到，使用React大大降低了逻辑复杂性，意味着开发难度降低，可能产生Bug的机会也更少。至于React如何做到将原来O(n^3)复杂度的Diff算法降低到O（n），大家可以参考。
2. 组件化的开发思路
虚拟DOM不仅带来了简单的UI开发逻辑，同时也带来了组件化开发的思想，所谓组件，即封装起来的具有独立功能的UI部件。React推荐以组件的方式去重新思考UI构成，将UI上每一个功能相对独立的模块定义成组件，然后将小的组件通过组合或者嵌套的方式构成大的组件，最终完成整体UI的构建。例如，Facebook的整站都采用了React来开发，整个页面就是一个大的组件，其中包含了嵌套的大量其它组件，大家有兴趣可以看下它背后的代码。
如果说MVC的思想让你做到视图-数据-控制器的分离，那么组件化的思考方式则是带来了UI功能模块之间的分离。我们通过一个典型的Blog评论界面来看MVC和组件化开发思路的区别。
对于MVC开发模式来说，开发者将三者定义成不同的类，实现了表现，数据，控制的分离。开发者更多的是从技术的角度来对UI进行拆分，实现松耦合。
对于React而言，则完全是一个新的思路，开发者从功能的角度出发，将UI分成不同的组件，每个组件都独立封装。
在React中，你按照界面模块自然划分的方式来组织和编写你的代码，对于评论界面而言，整个UI是一个通过小组件构成的大组件，每个组件只关心自己部分的逻辑，彼此独立。这样最外层的界面的Render只需要如下代码：
通过这种方式，每个组件的UI和逻辑都定义在组件内部，和外部完全通过API来交互，通过组合的方式来实现复杂的功能。React认为一个组件应该具有如下特征：
（1）可组合（Composeable）：一个组件易于和其它组件一起使用，或者嵌套在另一个组件内部。如果一个组件内部创建了另一个组件，那么说父组件拥有（own）它创建的子组件，通过这个特性，一个复杂的UI可以拆分成多个简单的UI组件；
（2）可重用（Reusable）：每个组件都是具有独立功能的，它可以被使用在多个UI场景；
（3）可维护（Maintainable）：每个小的组件仅仅包含自身的逻辑，更容易被理解和维护；
（4）可测试（Testable）：因为每个组件都是独立的，那么对于各个组件分别测试显然要比对于整个UI进行测试容易的多。
3. 一个React组件开发的例子：Tab选择器
上面从总体上介绍了React带来的全新的前端开发方法，以及其带来的影响，并没有介绍如何使用。为了让大家对其有一个具体的印象，这里实际来开发一个简单的组件：Tab选择器。网店的产品页面通常需要这样的控件来选择产品属性，例如选择衣服的颜色。这个控件接受一个数据源展示多个Tab供点击，点击后就选中了某个颜色，界面通常如下图所示。
按传统方式，我们可以用如下代码来实现一个jQuery插件：
用React方式，代码如下：
通过比较可以看到，jQuery插件方式，开发者首先需要考虑控件第一次Render出来时的DOM构建；其次，需要知道如何切换UI上的选中状态。
而React的方式，开发者仅仅需要考虑整体界面的DOM构建，不再需要关心局部更新，每次在一个React的Component上调用setState方法，都会触发render来重建整个界面。从开发思想的角度看，你可以认为每次数据的更新都会做整体的完全刷新。逻辑简单而直接。
如果我们再多考虑一步，控件的值不只在初始化和点击时可以设置，而且还可以通过程序动态的去设置。那么对于jQuery的方案而言，我们需要额外的方法和入口去做对应的UI更新。而对于React方式，则无需做任何改变，外部只需调用setState方法改变它的状态即可。这就是简化UI逻辑带来的好处。
完整的代码和演示已上传在Github上：
，大家可以实际试用一下。
如上所述，React是一个全新思路的前端UI框架，它完全接管了UI开发中最为复杂的局部更新部分，擅长在在复杂场景下保证高性能；同时，它引入了基于组件的开发思想，从另一个角度来重新审视UI的构成。通过这种方法，不仅能够提高开发效率，而且可以让代码更容易理解，维护和测试。Facebook以这样一种方式将沉淀多年的前端开发经验和技术的积累完全开源出来，值得所有前端开发者去借鉴和学习。并且React在发布一年的时间里就获得了极大的关注，Github上拥有超过1万的Star，相信其对前端开发的方向，甚至Web Component的标准，都将产生一定的影响。
王沛，邮件：
关注IT趋势，承载前沿、深入、有温度的内容。感兴趣的读者可以搜索ID：laocuixiabian，或者扫描下方二维码加关注。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（）或者腾讯微博（）关注我们，并与我们的编辑和其他读者朋友交流。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
和google的angularJS比呢？
feng kazaff
Re: 组件化与MVC并不矛盾
Re: 和google的angularJS比呢？
Re: 和google的angularJS比呢？
这和无MVC的extjs4有何区别
yang sunny
这和无MVC的extjs4有何区别
yang sunny
这和无MVC的extjs4有何区别
yang sunny
这和无MVC的extjs4有何区别
yang sunny
这和无MVC的extjs4有何区别
yang sunny
Re: 组件化与MVC并不矛盾
Re: 组件化与MVC并不矛盾
Re: 组件化与MVC并不矛盾
Re: 组件化与MVC并不矛盾
Re: 和google的angularJS比呢？
Re: 和google的angularJS比呢？
liu daniel
mvc跟组件不冲突吧
那组件与组件之间是如何进行通信的？
过细的粒度对扩展的影响
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。蚂蚁金服开发的设计语言&前端框架：Ant Design
来源：open开发经验库
Ant Design 是蚂蚁金服开发和正在使用的一套企业级的前端设计语言和基于 React 的前端框架实现。 &#13;
特性 &#13;
企业级金融产品的交互语言和视觉体系。 &#13;
丰富实用的 React UI 组件。 &#13;
基于 React 的组件化开发模式。 &#13;
背靠 npm 生态圈。 &#13;
基于 webpack 的调试构建方案，支持 ES6。 &#13;
示例 &#13;
var antd = require('antd');&#13;
var Datepicker = antd.D&#13;
React.render(&Datepicker /&, mountNode); 如何贡献 &#13;
我们欢迎任何形式的贡献，有任何建议或意见您可以进行 ，或者给我们。 &#13;
开发说明 &#13;
本地调试 &#13;
$ npm start 然后访问
网站部署 &#13;
$ npm run deploy 版本构建 &#13;
$ npm run release 项目主页：&#13;
免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动