为什么我要从 Angular 迁移到 React 和 Redux ？
我对 Angular 又爱又恨已经有一段时间了。这很有趣，因为我正在学习，而且在做一个简单的应用程序时，我被卡住了好几周。
我注意到，即使在制作最简单的特性的过程中，我甚至不确定它是否值得使用 Angular 。我彻底掌握了基本的基本原理，这足以使小的特性发挥作用。
但是，它没有成功。更糟糕的是，我甚至根本不使用 Javascript 。它更像是一种完全不同的语言。
我喜欢 Typescript ，但不知怎的，我在使用它时变得烦躁不安，因为我花了很多时间来掌握 Javascript 的细节。而且感觉我还在做一些后端工作(依赖注入、服务等)。奇怪的是，所有的事情都让人感到熟悉和沮丧。
然后有一天，我最终放弃使用 Angular 并寻找诸如 React 和 Vue 等其他选择。我在 2015 年 React 发布时有尝试过 React 。我记得它当时处于测试阶段，有很多人都在谈论它。 我不明白它的全部流程，比如 “state” 。
但在 2017 年第四季度左右，我尝试重温并观看与 React 和 Redux 相关的课程。 我很好奇大家为什么对这个库感到大惊小怪，它在 2017 年左右疯狂流行，其所谓的数据不变性也在大肆宣传。
我喜欢 AngularJS（ Angular 的第一个版本），以至于我喜欢它的“怪癖”并对它进行了很多研究。 但是，当我转移到 Angular 2+ 并投入了时间去研究时发现，我觉得有些东西不对，并且出于某种原因，它可能无法提供 React 中最简单的功能。
快速使用：最后我很高兴我做到了。 一旦你了解 React 的基本原理，实际上很容易实现这些基本功能。
我几个月来一直在我的新项目中使用 React ，并且我可以真正地说我没有后悔尝试使用 React 生态系统。 从那以后，我再也不用依靠 Angular 了。
所以，如果你可能会问：是什么让我从 Angula 转到 React ？ 仅仅只是灵活性吗？
小争论：不要拿苹果和橘子比较
我的意思是在这两个生态系统中我都没有受到任何损失，可能我们只是说，在 React 中整合新功能比 Angular 更容易，因为 React 是一个库，Angular 是一个框架。 大多数人都忽略了两者之间显著存在的巨大差异。
当你使用一个库时，它只是你应用程序的一部分。所以显然，学习曲线也很小，你甚至可以混合使用其他一些库。
框架对你开发影响是很大的。而且你应该遵守他们的标准使用方式（例如做 http 请求，组件绑定，事件绑定等）。简而言之，在使用 Angular 的情况下，你需要以“angular”的方式来做事情。因为你使用的是框架，所以你必须遵循它。
这与只负责视图部分的 React 情况不同。除此之外，你可以自行发现可能想要用于执行 http 请求以及订阅密钥绑定的内容。你可能想要使用 Redux 或 Flux 来进行数据存储和状态管理。你有很大的自由空间。
那么，下面是我现在使用 React 的原因：
它是一个库。因此，你可以附加任何你想要的 JavaScript 库作为附加组件
这很明显，因为 React 只是另一个 JavaScript 库，而不是框架。如前所述，在 React 中，你可以轻松地附加任何想要的库。只要你知道你在做什么，它并不关心 JavaScript 中的堆栈环境。 React 的理念围绕“乐高积木”的概念展开。这是你可以在库中获得的一个重大优势，也是你可以拥有的最强大的好处之一。我们都知道技术来来去去基本都是那几种。那么为什么你仍然需要把大部分时间都花在学习一个框架中呢？
这就是为什么我切换到 React 的原因：只使用我需要的东西。我可能不需要全面的框架，因为我不会以其他的方式使用框架的大部分功能。关键是，不管你的应用是过度设计还是架构良好，你仍然无法躲避在过程中引入错误的现实。既然如此，为什么还要过度设计？
当我尝试创建一个涉及附加全局事件处理程序的功能时，在 Angular 中，为了实现这个功能而需要做大量工作！
我搜索了几次 StackOverflow ，答案都是一样的。为了完成这项工作，需要经历一系列的挑战，实际上就是需要大量开发工作。 但我通过使用 Event Emitters 只花了一天时间就解决了这个问题。也就是说，对于一些简单的事情，它仍然需要大量的工作。
我并不是说 Angular 执行得不够好。 但是，可能我仍然需要投入大量时间才能完成简单的工作。
React 通过使用另一个名为 mousetrap 的 js 库来实现这一点，以实际绑定整个应用中的全局键值。 现在我可以使用我在 Vanilla JavaScript 中学到的东西了。
P.S：React 具有极大的灵活性的同时也具备良好的职责分工。
状态管理更加灵活
如果没有像 Flux 和 Redux 这样的库补充到 React 生态系统中，我可以说， React 可能与 Angular 依赖注入和服务模式是同等的。我不太喜欢使用这些模式，特别是在做一些前端的事情时。也许我只是不习惯使用它，因为在后端使用它更有意义，但在前端更少。
在我开始使用 React 和 Redux 一段时间后，我注意到，管理状态和在组件的不同部分分配那个状态是多么容易和轻松。这很神奇，因为它更强调每个 React 和 Redux 结合在一起的“状态”。
那么为什么它这么重要？因为它使你的沟通在你的组件的所有部分看起来毫不费力。你只需要发送一个动作，创建一个减速机，连接并知道它是什么 “state” ，瞧! 这个状态将反映在所有使用它的组件中，只要你修改了该状态。只有当你使用 Flux 和 Redux 时，这才是正确的。
一个理想的用例是当两个或多个组件依赖相同的数据或状态时，只需通过简单地将组件连接到 Redux 来轻松地检索它们。例如，我的仪表盘上的组件都需要同样的数据，并很好的在模态框中显示，以让我更容易把它们连接起来。
为实现这个目标，你需要做以下的事情：
- 在你的 React App 中加入 Redux
- 创建一个 由 Dispatchers, Actions, Reducers 组成的 Redux store
- 把你的组件连接到 Redux Container
- 在你的组件内部使用 Application State
当然，在这样做时，你也必须小心，因为随着应用的增长，它可能会变得更加混乱。在所有的灵活性中总是有一个权衡，无论是编程语言还是库。Abramov 在他的博客中进一步表示：你可能不需要 Redux 。
现在，让我们来看看 Angular 是如何做的：
带有 Service 的组件作为中心连接一个组件与另一个组件进行通信。
全局状态方法也可以用 Angular 2+ 的方式进行。你可能会说，它与 React 工作方式完全不同，因为它使用服务模式作为 Angular 核心模式，主要是为了迎合 API ，使单元测试更容易。
为了让组件彼此通信，你需要执行以下操作:
- 创建包含事件发射器的服务，以使每个组件的通信成为可能。
- 创建可以响应用户在全局组件中操作的事件发射器。
- 为将使用全局事件的每个组件注入服务。
- 为将使用它们的每个组件创建事件发射器，并在订阅服务中创建事件。
- 确保事件发射器将被取消订阅，以使事件只触发一次。
你仍然完成需要冗长的设置，以便开始在组件彼此之间通信。
将 JSX 语法与 Javascript 很好地融合在一起。
我相信这是未来的 Javascript 应该采用的。这几乎让人觉得是 Javascript 的自然进化，或者是 Javascript 就应该是很好地融合在一起的。
使用 JSX 语法的示例 JS 文件
当我在玩 Angular的时候，感觉就像在 Angular 和 Javascript 之间有一种阻力。可能是由于 Typescript 的要求。
但是有了 React ，它与 Javascript 完美地结合，因为你的组件直接驻留在 Javascript 中。所以不需要双向数据绑定。
一开始，我只是有点喜欢这样的想法：组件在 html 和另一个单独的 js 文件中很好地分离，以便在 html 中使用它来做一些数据输入。
但是，我当时没想到的是，我将会爱上 JSX 语法与 Javascript 的融合。将逻辑添加到 JSX 中的组件很容易。这加快了我的开发时间，大约比 Angular 提高 4 倍。
更快的学习曲线
学习一个特定的框架或库的学习曲线有多困难或多长时间对我来说没有问题，只要它有一个困难的原因(比如，改进的可维护性和工作流)，我就会把它当作一个挑战。
我承认我很难进入 React 的生态系统(特别是在2015年初)，但是一旦我能够理解它是如何运作的，以及它背后的设计理念，我的生产率提高了十倍。我不需要在这里和那里进行类型检查。
当然，没有类型检查也有其不足之处。但大多数都是微不足道的。如果你更喜欢使用 TypeScript ，那么 React 是欢迎的。
现代 Web 开发具有挑战性，我们开发 Web 应用的方式现在与以前有很大不同
这也是我加入 React 生态系统的原因之一。考虑到开发 Web 应用的领域已经发生变化，我需要使用一个库，或者具有较短学习曲线和易于维护的框架。通过这种方式，我仍然有更多的时间来学习 Web 开发的其他部分，并打磨我作为开发人员的技能。
我想强调一点，因为在现代开发应用比以前有明显不同并令人生畏。大多数情况下，你的 Web 应用现在可以成为一个独立的 JavaScript 应用，这要归功于 Javascript 社区所取得的发展和进步（或许要感谢 NodeJS 的存在）。
现今的互联网也正在发生着很多事情，比如说同构的 Web 应用，通用的 Web 应用，原生的 Web 应用（比如说 React Native )。无论哪种方式，都变得越来越有挑战性。
现如今，对于新的开发人员和已经在 Web 开发有一段时间的人员来说都有挑战，因为你需要了解如何打包你的 Javascipt 应用，如何使用 grunt 或 gulp, browserify, webpack 等等。
这告诉了我们关于 Angular 和 React 生态系统的什么？简单来讲，学习曲线和时间。
如果我们刚刚开始体会到现代 web 开发的感觉，学习 Angular 将会吞噬你真正开始构建一个真实世界应用的时间。因为，学习 Angular 就需要花费你一年的时间。你可以说现在的框架和库由于 CLI （命令行界面）变得更加容易设置，但是你仍然忽略了 web 应用真正运行的内部机制。它将你从完全学习中抽象出来。
这对于现代 Web 开发来说是一个坏消息，尤其是如果你想要成为一个全栈开发者。你只有很少的时间去学习现代 Web 应用安装设置的细枝末节。
你能够多快地学习并使用 React 构建 Web 应用，你才可以更加高效地学习构建现代 Web 应用的其他部分。正因如此，我在短时间内对 ES6 的特性、babel、webpack 都有了很好的了解。这节省了我很多时间。总体上，我可以了解现代 Web 开发的工作原理（甚至从零开始学习 NodeJS ）。
你可以不花力气地复用组件，因为它们都只是纯函数
使用 React，你的组件是纯函数，你可以简单地在其他 React 组件中导入和应用它。
在 App.js 中重用的 SidebarTableSchemas 组件
我讨厌 Angular 思想，它似乎很难与你的组件通信。我必须先熟悉许多术语，以便重用其他组件中的 Angular 组件。这是令人失望和耗时的。
而且，通常情况下，你仍然需要添加一个服务，以便让它们彼此通信(如果你是一位像我一样的后端开发，这不是问题)。在大多数情况下，你仍然需要手动添加订阅服务器，以便让两个或多个组件彼此通信。这就是我们大部分时间所面临的问题
当我搜索 Stack Overflow 时，很多人在他们的每个组件中大范围广播相同的数据时遇到了问题。
当我读到能让我重复使用一个组件的解决方案时，我不禁摇了摇头，问自己:这个解决方案值得吗?为什么这在一开始就很复杂呢?
大量的社区支持
React：
Angular：
想象一下一个几乎没有社区支持的 Javascript 库或框架。在某些情况下，你或许会在技术实现上遇到麻烦，或是遇到无法解决的问题，或是你不得不自己处理那些脏的工作。通常这个对于你自身部分以及应用依赖的业务代价是很高的。
近期，React 有大量的社区支持，超过了 Angular 和 AngularJS 的总和。并且 VueJS 可能会迎头赶上。你可以区分现今人们所广泛支持的是哪一个。
你也可以在 Google Trends 或 Github 上查看一些统计数据。当然，你不能仅仅看这些数字就证明它是最好的框架或库。你必须亲自去尝试，去分辨哪一个是最好的。
那么，选择哪一个呢?
当你为你的应用选择 Javascript 框架或库时，你需要考虑几个因素。
- 你的团队的技能/专长。
- 项目规模或性质(小型、中型、企业)
- 使用的资源
最后，关于 React 是否比 Angular 更好的争论是非常主观的。这实际上可以归结为你的团队在某个特定的库中的适应性，你正在开发的项目的性质，以及程序员的个人喜好。
如果你的团队是由新手组成的，那么由于其简单性和 Javascript 的优点，常规情况下会喜欢 React 超过 Angular 。相反，如果你的团队由经验丰富的专业人员组成，并且在相当长一段时间内使用了 Angular ，那么可能会选择使用它。
结论
每个库和框架的目标，都应该是简化开发人员的生活，使他们在长期开发的过程中具有生产力和适应性。 Javascript 已经是一种杂乱的编程语言，很多人都在用它来构建一个库或框架，以使它变得更好。
就我个人而言，我认为 Angular 在新框架中已经过时了。它实际上弊大于利(抱歉，没有冒犯 Angular 用户的意思)。
React 给了我希望, 现代 web 开发不应该很难驯服,考虑到它仍然是生态系统中的一部分,许多事情我们需要捆绑如 Babel、Webpack、Electron 等来开发多平台应用。
如果你是那种看重你的时间和热情去学习其他的堆栈以及现代 Web 应用细节的开发人员，你可以考虑学习 React 。我强烈推荐它。否则，坚持 Angular 。
本文文字及图片出自 OSchina
你也许感兴趣的：
- React 19 差点拖慢整个互联网！核心团队紧急叫停
- 从 React 到 HTML 优先：Microsoft Edge 推出 “WebUI 2.0”
- 【译文】React 是新的 IBM
- 沉寂 600 多天后，React 憋了个大招
- 【译文】React 让我有点恼火
- React 正在杀死 Angular 吗？
- 【译论】React Native 还流行吗？
- 我从“过时”的 React 开发中汲取经验教训
- 力不从心，React核心开发者Dan Abramov宣布从Meta离职
- Elm + React：入门容易，坚持难
你对本文的反应是：