为什么我要从 Angular 迁移到 React 和 Redux ? 已翻译 100%

oschina 投递于 2018/02/26 14:21 (共 19 段, 翻译完成于 03-13)
阅读 10491
收藏 32
4
加载中

我对 Angular 又爱又恨已经有一段时间了。这很有趣,因为我正在学习,而且在做一个简单的应用程序时,我被卡住了好几周。

我注意到,即使在制作最简单的特性的过程中,我甚至不确定它是否值得使用 Angular 。我彻底掌握了基本的基本原理,这足以使小的特性发挥作用。

但是,它没有成功。更糟糕的是,我甚至根本不使用 Javascript 。它更像是一种完全不同的语言。

我喜欢 Typescript ,但不知怎的,我在使用它时变得烦躁不安,因为我花了很多时间来掌握 Javascript 的细节。而且感觉我还在做一些后端工作(依赖注入、服务等)。奇怪的是,所有的事情都让人感到熟悉和沮丧。


liyue李月
翻译于 2018/03/02 10:21
1

然后有一天,我最终放弃使用 Angular 并寻找诸如 React 和 Vue 等其他选择。我在 2015 年 React 发布时有尝试过 React 。我记得它当时处于测试阶段,有很多人都在谈论它。 我不明白它的全部流程,比如 “state” 。

但在 2017 年第四季度左右,我尝试重温并观看与 React 和 Redux 相关的课程。 我很好奇大家为什么对这个库感到大惊小怪,它在 2017 年左右疯狂流行,其所谓的数据不变性也在大肆宣传。

我喜欢 AngularJS( Angular 的第一个版本),以至于我喜欢它的“怪癖”并对它进行了很多研究。 但是,当我转移到 Angular 2+ 并投入了时间去研究时发现,我觉得有些东西不对,并且出于某种原因,它可能无法提供 React 中最简单的功能。 

凉凉_
翻译于 2018/02/27 13:39
1

快速使用:最后我很高兴我做到了。 一旦你了解 React 的基本原理,实际上很容易实现这些基本功能。

我几个月来一直在我的新项目中使用 React ,并且我可以真正地说我没有后悔尝试使用 React 生态系统。 从那以后,我再也不用依靠 Angular 了。

所以,如果你可能会问:是什么让我从 Angula 转到 React ? 仅仅只是灵活性吗?

小争论:不要拿苹果和橘子比较

我的意思是在这两个生态系统中我都没有受到任何损失,可能我们只是说,在 React 中整合新功能比 Angular 更容易,因为 React 是一个,Angular 是一个框架。 大多数人都忽略了两者之间显著存在的巨大差异。

凉凉_
翻译于 2018/02/27 13:47
2

当你使用一个库时,它只是你应用程序的一部分。所以显然,学习曲线也很小,你甚至可以混合使用其他一些库。

框架对你开发影响是很大的。而且你应该遵守他们的标准使用方式(例如做 http 请求,组件绑定,事件绑定等)。简而言之,在使用 Angular 的情况下,你需要以“angular”的方式来做事情。因为你使用的是框架,所以你必须遵循它。 

这与只负责视图部分的 React 情况不同。除此之外,你可以自行发现可能想要用于执行 http 请求以及订阅密钥绑定的内容。你可能想要使用 Redux 或 Flux 来进行数据存储和状态管理。你有很大的自由空间。

那么,下面是我现在使用 React 的原因:

凉凉_
翻译于 2018/02/27 13:52
1

它是一个库。因此,你可以附加任何你想要的 JavaScript 库作为附加组件

这很明显,因为 React 只是另一个 JavaScript 库,而不是框架。如前所述,在 React 中,你可以轻松地附加任何想要的库。只要你知道你在做什么,它并不关心 JavaScript 中的堆栈环境。 React 的理念围绕“乐高积木”的概念展开。这是你可以在库中获得的一个重大优势,也是你可以拥有的最强大的好处之一。我们都知道技术来来去去基本都是那几种。那么为什么你仍然需要把大部分时间都花在学习一个框架中呢?

这就是为什么我切换到 React 的原因:只使用我需要的东西。我可能不需要全面的框架,因为我不会以其他的方式使用框架的大部分功能。关键是,不管你的应用是过度设计还是架构良好,你仍然无法躲避在过程中引入错误的现实。既然如此,为什么还要过度设计?

凉凉_
翻译于 2018/02/27 14:02
1

当我尝试创建一个涉及附加全局事件处理程序的功能时,在 Angular 中,为了实现这个功能而需要做大量工作!

我搜索了几次 StackOverflow ,答案都是一样的。为了完成这项工作,需要经历一系列的挑战,实际上就是需要大量开发工作。 但我通过使用 Event Emitters 只花了一天时间就解决了这个问题。也就是说,对于一些简单的事情,它仍然需要大量的工作。

我并不是说 Angular 执行得不够好。 但是,可能我仍然需要投入大量时间才能完成简单的工作。

React 通过使用另一个名为 mousetrap 的 js 库来实现这一点,以实际绑定整个应用中的全局键值。 现在我可以使用我在 Vanilla JavaScript 中学到的东西了。

P.S:React 具有极大的灵活性的同时也具备良好的职责分工。

凉凉_
翻译于 2018/02/27 14:12
1

状态管理更加灵活



如果没有像 Flux 和 Redux 这样的库补充到 React 生态系统中,我可以说, React 可能与 Angular 依赖注入和服务模式是同等的。我不太喜欢使用这些模式,特别是在做一些前端的事情时。也许我只是不习惯使用它,因为在后端使用它更有意义,但在前端更少。

在我开始使用 React 和 Redux 一段时间后,我注意到,管理状态和在组件的不同部分分配那个状态是多么容易和轻松。这很神奇,因为它更强调每个 React 和 Redux 结合在一起的“状态”。

liyue李月
翻译于 2018/03/02 10:42
0

那么为什么它这么重要?因为它使你的沟通在你的组件的所有部分看起来毫不费力。你只需要发送一个动作,创建一个减速机,连接并知道它是什么 “state” ,瞧! 这个状态将反映在所有使用它的组件中,只要你修改了该状态。只有当你使用 Flux 和 Redux 时,这才是正确的。

以斯拉
翻译于 2018/03/07 11:51
1

一个理想的用例是当两个或多个组件依赖相同的数据或状态时,只需通过简单地将组件连接到 Redux 来轻松地检索它们。例如,我的仪表盘上的组件都需要同样的数据,并很好的在模态框中显示,以让我更容易把它们连接起来。

为实现这个目标,你需要做以下的事情:

  • 在你的 React App 中加入 Redux

  • 创建一个 由 DispatchersActionsReducers 组成的 Redux store

  • 把你的组件连接到 Redux Container

  • 在你的组件内部使用 Application State

当然,在这样做时,你也必须小心,因为随着应用的增长,它可能会变得更加混乱。在所有的灵活性中总是有一个权衡,无论是编程语言还是库。Abramov 在他的博客中进一步表示:你可能不需要 Redux 。

现在,让我们来看看 Angular 是如何做的:

带有 Service 的组件作为中心连接一个组件与另一个组件进行通信。

翻译于 2018/03/10 22:26
0

全局状态方法也可以用 Angular 2+ 的方式进行。你可能会说,它与 React 工作方式完全不同,因为它使用服务模式作为 Angular 核心模式,主要是为了迎合 API ,使单元测试更容易。

为了让组件彼此通信,你需要执行以下操作:

  1. 创建包含事件发射器的服务,以使每个组件的通信成为可能。

  2. 创建可以响应用户在全局组件中操作的事件发射器。

  3. 为将使用全局事件的每个组件注入服务。

  4. 为将使用它们的每个组件创建事件发射器,并在订阅服务中创建事件。

  5. 确保事件发射器将被取消订阅,以使事件只触发一次。

你仍然完成需要冗长的设置,以便开始在组件彼此之间通信。

liyue李月
翻译于 2018/03/02 10:35
0
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(32)

老年全栈
怪你家的F1赛车不能满足川藏线的梦想吗?
满城丧尸
满城丧尸
angular挺好的,很多值得学习的地方,对技术有追求的人都应该去研究一下,暂时不要瞎评论
喻恒春
喻恒春

引用来自“Raphael_goh”的评论

@喻恒春 你说angular约束,依赖, 强耦合。我承认,ng确实是约束, 有依赖,但强耦合这个可能每个人的理解不同。

angular引入依赖注入的目的就是弱化耦合。就拿之前说的,只要你引入axios做一下简单适配,就可以把http模块给替换掉。如果你对router不满也可以替换掉angular的router。但是绝大多数的用户都先入为主的认为angular就是一个整套的开发框架,完全没有考虑过去替换掉里面的组件。所以你所谓的约束,依赖, 强耦合也不奇怪。

最后我再次提及ivy render,render v3已经非常接近jsx的翻译结果了,该去的依赖也都去了,通过@angular/elements打包可以直接嵌入vue、react的项目不是问题。如果愿意甚至可以像vue、react这样只用ivy render + @angular/elements开发,完全没有任何约束。所以未来的angular应该是弱约束、去依赖、弱耦合。

引用来自“喻恒春”的评论

如果未来 Angular 是弱约束、去依赖、弱耦合 那还有得看.

但 WEB 世界相同目标的项目和独立解耦的库太多了, 或者只是一个思路 有选择啊. 没必要去迁就谁.
真没有就自己造啊, 大家都是程序员, 干的就是这个.

前耦合这个大坑在项目中多如牛毛, 常常一个项目初期好好的, 越做耦合越强.
这和使用者的总想获得大而全的工具思维模式有关系. 但开发者如果把握不住, 那就是灾难.

另外说到 Angular 的依赖注入, 从 Angular 的角度看, 这是个不错的解决方案.
但站在外面看, 这方案简直丑陋的离谱. JavaScript 是动态语言, 任意对象都可以附加属性和函数, 还有 bind, MAP.
这种解决方法完全就是忽视了宿主语言特性发明的轮子, 一个库忽视了宿主语言特征和运行场景特征,,, 那是全新的轮子, 全新的语言.

引用来自“Raphael_goh”的评论

所以angular最终选择了typescript这个超集,而不是JavaScript.
没错, Angular 如果用其它静态语言写(typescript 还是与 JS 有太多交集), 给非 JavaScript 程序员用, 那做法和定位就合理了, 这不是不可能的, 看看 Flutter, 就是用 Dart 写的, 能不能工作于 WEB 平台, 那就看团队怎么写了.
Raphael_goh
Raphael_goh

引用来自“Raphael_goh”的评论

@喻恒春 你说angular约束,依赖, 强耦合。我承认,ng确实是约束, 有依赖,但强耦合这个可能每个人的理解不同。

angular引入依赖注入的目的就是弱化耦合。就拿之前说的,只要你引入axios做一下简单适配,就可以把http模块给替换掉。如果你对router不满也可以替换掉angular的router。但是绝大多数的用户都先入为主的认为angular就是一个整套的开发框架,完全没有考虑过去替换掉里面的组件。所以你所谓的约束,依赖, 强耦合也不奇怪。

最后我再次提及ivy render,render v3已经非常接近jsx的翻译结果了,该去的依赖也都去了,通过@angular/elements打包可以直接嵌入vue、react的项目不是问题。如果愿意甚至可以像vue、react这样只用ivy render + @angular/elements开发,完全没有任何约束。所以未来的angular应该是弱约束、去依赖、弱耦合。

引用来自“喻恒春”的评论

如果未来 Angular 是弱约束、去依赖、弱耦合 那还有得看.

但 WEB 世界相同目标的项目和独立解耦的库太多了, 或者只是一个思路 有选择啊. 没必要去迁就谁.
真没有就自己造啊, 大家都是程序员, 干的就是这个.

前耦合这个大坑在项目中多如牛毛, 常常一个项目初期好好的, 越做耦合越强.
这和使用者的总想获得大而全的工具思维模式有关系. 但开发者如果把握不住, 那就是灾难.

另外说到 Angular 的依赖注入, 从 Angular 的角度看, 这是个不错的解决方案.
但站在外面看, 这方案简直丑陋的离谱. JavaScript 是动态语言, 任意对象都可以附加属性和函数, 还有 bind, MAP.
这种解决方法完全就是忽视了宿主语言特性发明的轮子, 一个库忽视了宿主语言特征和运行场景特征,,, 那是全新的轮子, 全新的语言.
所以angular最终选择了typescript这个超集,而不是JavaScript.
喻恒春
喻恒春

引用来自“Raphael_goh”的评论

@喻恒春 你说angular约束,依赖, 强耦合。我承认,ng确实是约束, 有依赖,但强耦合这个可能每个人的理解不同。

angular引入依赖注入的目的就是弱化耦合。就拿之前说的,只要你引入axios做一下简单适配,就可以把http模块给替换掉。如果你对router不满也可以替换掉angular的router。但是绝大多数的用户都先入为主的认为angular就是一个整套的开发框架,完全没有考虑过去替换掉里面的组件。所以你所谓的约束,依赖, 强耦合也不奇怪。

最后我再次提及ivy render,render v3已经非常接近jsx的翻译结果了,该去的依赖也都去了,通过@angular/elements打包可以直接嵌入vue、react的项目不是问题。如果愿意甚至可以像vue、react这样只用ivy render + @angular/elements开发,完全没有任何约束。所以未来的angular应该是弱约束、去依赖、弱耦合。
如果未来 Angular 是弱约束、去依赖、弱耦合 那还有得看.

但 WEB 世界相同目标的项目和独立解耦的库太多了, 或者只是一个思路 有选择啊. 没必要去迁就谁.
真没有就自己造啊, 大家都是程序员, 干的就是这个.

前耦合这个大坑在项目中多如牛毛, 常常一个项目初期好好的, 越做耦合越强.
这和使用者的总想获得大而全的工具思维模式有关系. 但开发者如果把握不住, 那就是灾难.

另外说到 Angular 的依赖注入, 从 Angular 的角度看, 这是个不错的解决方案.
但站在外面看, 这方案简直丑陋的离谱. JavaScript 是动态语言, 任意对象都可以附加属性和函数, 还有 bind, MAP.
这种解决方法完全就是忽视了宿主语言特性发明的轮子, 一个库忽视了宿主语言特征和运行场景特征,,, 那是全新的轮子, 全新的语言.
Raphael_goh
Raphael_goh
@喻恒春 你说angular约束,依赖, 强耦合。我承认,ng确实是约束, 有依赖,但强耦合这个可能每个人的理解不同。

angular引入依赖注入的目的就是弱化耦合。就拿之前说的,只要你引入axios做一下简单适配,就可以把http模块给替换掉。如果你对router不满也可以替换掉angular的router。但是绝大多数的用户都先入为主的认为angular就是一个整套的开发框架,完全没有考虑过去替换掉里面的组件。所以你所谓的约束,依赖, 强耦合也不奇怪。

最后我再次提及ivy render,render v3已经非常接近jsx的翻译结果了,该去的依赖也都去了,通过@angular/elements打包可以直接嵌入vue、react的项目不是问题。如果愿意甚至可以像vue、react这样只用ivy render + @angular/elements开发,完全没有任何约束。所以未来的angular应该是弱约束、去依赖、弱耦合。
喻恒春
喻恒春

引用来自“喻恒春”的评论

Angular 是基于 HTML, JavaScript, CSS 的, 但 Angular 没有直接继承已有的融合技术,
而是创造了全新方法, 创造了新的世界观.
而且学习成本陡峭, 你学到的东西只能用于 Angular, 不能提高 HTML, JavaScript, CSS 的技能和知识.
所以我一直认为 Angular 创(毁)三观的做法不值得推荐.

引用来自“Raphael_goh”的评论

什么叫不能提高 HTML, JavaScript, CSS 的技能和知识?
知道啥叫web component?custom dom?shadow dom?html import?
三大框架里唯一一个按照web component规范走的一个框架。目前提供了angular element (beta版),可以转化成web component的组件,将来可以嵌入到任何地方,脱离ng不是梦。

每个人都鼓吹组件式开发,但浏览器和其他框架从来不提供web component的相关的技术支持。从v0->v1都靠Google一家来推动,v1之后其他浏览器才纷纷响应。

抛开web component不谈,从框架层面最先提供service worker的也是angular吧,当然vue、react更倾向于把这些问题抛给社区,提供更加成熟的方案。

其他方面,angular不能使用jsx,也不能使用css in js,但这方面也不能叫没有直接继承已有的融合技术吧!难道在用原始的html和css也不行,在上面做微小改进也算是创造了全新方法, 创造了新的世界观?

要说angular陡峭和变扭的地方,就是依赖注入、angular module了吧。在新的ivy render(angular 6)中已经可以不用angular module了,至于依赖注入这个是ng的特色,仁者见仁智者见智了。

其他的比如typescript,vue也提供了官方方案,只不过不是默认方案。数据层方面,angular没有提供flux/redux模式,而是选择了rxjs,增加了部分的门槛,但这种方案在社区里也是比较受欢迎的方案之一,不能说是什么创造了新的世界观吧。难道当年Facebook创造vitural dom,flux就不是创造全新世界观了?

引用来自“喻恒春”的评论

Angular 的确有可取的创新之处, 这是事实.
当然喜欢 Angular 的开发者也很多, 在开发历史上也出现过类似的现象.
最典型的对比例子就是 PHP 的 Smart 模板, 不要在意他们的应用领域不同, 他们在做法上有太多的相似之处. 比如:

1. 出于安全,可靠的目标 封装(做出各种限制)了一切
2. 定义了大量的新语义设施
3. 因为前两条使得难于直接使用(融合)宿主语言执行环境所提供的支持

当年 Smart 模板出现的时候就有很多 PHP 开发者认为:
PHP 本身就是个模板语言, 使用 Smart 得不偿失, 与其让非 PHP 开发者学习 Smart, 还不如让他们学习一点 PHP 原生语法.

Angular 在 WEB 领域再次重现了 Smart 的一幕.
与其学习 Angular 不如学习原生的 DOM, CSS, HTML, JavaScript. 搭配为解决专(单)项问题的库来构建 WEB 应用.

比较中肯的说: Angular 团队最佳的做法是拆分各个模块, 降低依赖性. 使模块可以通过简单的组合来使用, 当然有部分强依赖是正常的, 可接受的

引用来自“Raphael_goh”的评论

你说的拆分各个模块, 降低依赖性,其实angular团队已经做了,只不过一般人不太体会的到。

为什么要提供依赖注入?就是让他的每个组件都是可替换的,只要提供各个模块的实现就可以替换掉对应的模块,比如你可以把angular的http直接替换成axios。但这样做的唯一问题就是要对第三方库做一些简单的包装(部分可以直接换,大多数要做一层包装)。

目前的情况看下来的结果就是只有ionic做了这样的事情,大部分人倾向于全盘接收angular,所以会觉得angular依赖太密切了。而相对来说,angular将来提供的render v3和@angular/elements,应该会是这种依赖降低很多。

至于你说的smart template,我体会不到。就我的感觉来说,angular和原生js、html、css几乎没什么区别,vue基本上也是这样做的,但没人说vue吧。要真的说创造了一套新语法的反而是jsx。

引用来自“喻恒春”的评论

jsx 的确是创造了一套新语法, 但是这个语法基于 HTML 基础, 而还保留了完整的原生 HTML 知识.
本质上 vue 和 jsx 区别不大, 都是基于字符串对 HTML 进行重构, 最后生成 DOM, 他们都保留了原生 HTML 知识.
反观 Angular, 创造了整个构建 WEB 的技术点, 这意味着, 以前学习的知识点全部要和 Angular 的三观进行映射.
从知识积累的角度, Angular 创建了一个原点, 在我的评判中这方法太生硬, 不美.

引用来自“Raphael_goh”的评论

<h2>Should mankind colonize the Universe?</h2>
<h3>Agree: {{agreed}}, Disagree: {{disagreed}}</h3>
< app-voter *ngFor="let voter of voters"
[name]="voter"
(onVoted)="onVoted($event)">


<h2>Should mankind colonize the Universe?</h2>
<h3>Agree: {{agreed}}, Disagree: {{disagreed}}</h3>
< app-voter v-for="voter in voters" :name="voter" @on-voted="onVoted($event)">

所以vue就是保留了原生 HTML 知识,而angular就是全部要和 Angular 的三观进行映射?

引用来自“喻恒春”的评论

是的, 你举的模板例子是很重要的一个方面.
就模板而言 Angular 的模板引入了太多东西, 做的多不一定是好事儿, 会让事情更复杂. 其它方面也一样.
也许你会认为, Angular 这样解决了 VUE, JSX 不能解决的问题, 没错, 可这种方法不美.

大家都知道开发中的"银弹"是不存在的, VUE,JSX 解决不了的, 不表示它们必须要解决才够强.
也不表示没有解决方案, 关于这点译文中已经阐述.
模板是 WEB 开发要解决的基础问题之一, 既然你提到了模板, 刚好我也是模板引擎开发者, 从我的角度出发, VUE,JSX 的做法还是不够新, 不够前端, 它们的做法更多的是代码形式上的差别, 本质没有改变.

我之所以会对他们不感冒, 底气就在于我自己开发了改变本质的前端模板引擎.
https://codepen.io/achun/project/full/XjEvaw

核心理念: 模板就是用 HTML 代码写(翻译到) JS
同理: CSS 预处理器就是用 CSS 写(翻译到) JS

https://github.com/powjs/powcss

引用来自“Raphael_goh”的评论

2. 当然就算抛弃了跨平台抽象这层概念,该有的一些概念还是有,比如EmbeddedViewRef、ViewContainerRef、TemplateRef,这些抽象层。对你来说,你觉得这些概念是多此一举,html就是html,没必要搞那么复杂。所以这又扯到了我最开始说的话题上:web component。

之所以引入这一层抽象,就是针对web component所做的。web component的几个组成部分,custom dom、shadow dom、html import、HTML templates。就这方面来说,angular是vue、react这几大框架(库)里最激进的,只要简单配置,就可以在light dom和shadow dom之间进行切换。而angular/elemenets的引入也让他将来可以直接把组件打包成一个web component规范的标准组件成为了可能,这之后这些组件就可以跨任何框架、模板引擎进行使用了。vue的作者尤雨溪也说,将来可能会提供对web component的支持,那时候可能也会引入一些额外的东西,只是现在没必要。

当然了对于有没有必要使用web component,每个人的看法不同,还有很多人唱衰这个标准。但不管怎么说angular提供对这个标准的支持也给其他人提供了一种选择。

3. 其他概念directive、pipe什么的这些算是angular的特色,我就不多说了,可能你觉得完全没必要。
我从未否定过 web component, view, shadow dom, directive, pipe 等等技术设施,
它们每个都是真实有效的, 世界是多样的才会精彩.
我一直说的是约束,依赖, 强耦合. 我不喜欢把这些所有都强耦合在一起.
quanwei9958
quanwei9958
呵呵.

为什么我从Vue转向React

为什么我从Angular转向React

为什么我从React转向Vue

为什么我从Angular转向Vue

为什么我从Vue转向Angular

为什么我从React转向Angular
keep_wan
keep_wan
傻逼言论. 自己水平不行也怪框架跟ts咯.
飞翔吧星尘龙
工作中使用的就是angular5,听说很快出angular6了,对angular的繁琐真的是深有体会,搞了很多复杂的概念,比较扭曲。如果是新手的话用vue更简单,高手的话用react更厉害。angular有种高不成,低不就的感觉。
返回顶部
顶部