别责怪框架我使用AngularJS和ReactJS的经验.docxVIP

别责怪框架：我使用 AngularJS 和 ReactJS 的经验在过去的几年里，网站进化成了复杂的网页应用。曾经的互联网只涉及到简单的商业信息展现，而如今，看看 Facebook、Slack、Spotify 以及 Netflix，互联网正在改变你的社交和生活方式。随着互联网的发展，前端开发这个行业达到了全新的高度，并得到了前所未有的重视。就像大多数前端开发者那样，我们的技术栈曾经由 HTML 和 jQuery 构成。我们使用 AJAX 请求从后端获取数据，使用 JavaScript 渲染新的 UI 元素然后将它插入到 DOM 中去，用户交互通过事件绑定和回调函数来实现。不要误解我，我不反对上面那种方式，它们今天依然适合于大多数 Web 应用。然而，当一个应用的复杂度大幅度增加，/posts/186-lessons-learnt-by-building-singleapplications一堆问题开始出现得比预期的更频繁：你可能数据更新了，但漏掉了更新某一处展现，你通过 Ajax 获取和更新了内容，但没有绑定事件，还有另外一些问题，把这些全部列出来会是个很长的清单。这些问题让你的代码逐渐变得不可维护，尤其是在多人协作团队开发的项目中。这时候，你就需要使用前端框架来为你解决多人协作开发的种种问题了。!–more–1. React 福音当我们的团队开始寻找一个合适的前端框架的时候，我们考虑了许多选择，最后留下两个选项 ——?/Angular?和React。Angular 是目前为止最成熟的方案：它拥有一个庞大的社区，你可以为大部分应用场景找到合适的第三方模块。React 也很有竞争力，它以 JavaScript 为中心的设计看起来很有前途，而且它性能很好。虽然它还是 Beta 版本，但是 “由Facebook团队开发的” 这一点给它的竞争力加分。我们决定给 React 一个机会，选择了使用它。最初使用 React 让人感觉棒极了，我们可以用 JavaScript 来做一切：展现一段 HTML，通过遍历数组渲染一个列表，优雅地改变一个变量的值，然后看着它通过?https://facebook.github.io/react/docs/transferring-props.htmlprops?传播到各处，更新要更新的内容到可复用组件里，然后一切就绪了，没有一坨一坨的代码，只有真正的https://facebook.github.io/react/docs/thinking-in-react.html停下来思考。React 解决了我们在团队开发中编写可维护代码的诉求。2. React + Flux = ?但沿着这条路走下去，我们发现并不是一切都很美好。我们遇到的第一个大挑战就曾让我们考虑是否应该放弃 React —— 我们陷入了回调迷宫。由于 React 的单向数据流性质，如果子组件需要更新父组件的状态，父组件就要传一个回调函数给它。这咋看起来没有什么大不了的，然而如果你的组件要更新 root 组件的状态，你就不得不将 “ps.updateCallback” 沿着数据流一层一层传递下来。尽管如此，我们喜欢 React，继续使用它完成我们的工作。通过努力，我们找到了?https://facebook.github.io/flux/Flux，它是一种规范化单向数据流的架构思想。它由四个主要元素构成。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 代码的时候，我就真心诅咒它。这就是所谓的：如果你爱 React，那你就恨 Angular。我不能自欺欺人，在一开始，我写 Angular 代码一点也不开心。将框架定义的属性（或者，更恰当地说法是 directives）写入到 HTML 中的做法让我感觉很不爽。我得费很大劲才能实现很简单的功能，比如改变 URL 的时候