Angular 18+ 高级教程 – 初识 Angular

Before Starting

深入学习 Angular 是一件非常耗时耗力的事情。

实施 Angular 到项目中同样也是一件非常耗时耗力的事情。

在我们做出这么大的投入之前，我们有必要先思考以下几个问题：

什么样的项目适合使用 Angular 做开发？
要深入学习 Angular，需要做哪些学前准备？
Angular 还火吗，Google 会不会突然宣布不再更新？

什么样的项目适合使用 Angular 做开发？

这题是有官方答案的，Angular 团队的 Emma 在 YouTube 介绍过 3 种不同级别的 Angular 项目。

Solo Project – I Miss My Cafe
Team Project – Coffee Table Talks
Big Team Project – ClickUp

她是以团队大小来分级。我们来挨个解读一下

Solo Project（单人项目）

单人项目也意味着项目小、逻辑简单、代码量少、成长慢。毕竟一个人嘛，输出有限。

同时它还有这些特色：

代码风格随意
代码扩展性差
没写测试

之所以会有这些情况，倒不是因为开发者能力差，更多是因为项目不值得投入那么多。

所以，我觉得一个适合单人项目的框架应该具备以下这些特色：

学习成本低
代码量少
容错率高

显然，Angular 一点都不符合这些特性，单单一个 TypeScript 就同时增加了学习成本和代码量，更不用说还有其它的像 RxJS、依赖注入、Web Components 等等。

虽然 Angular 团队在 v14 版本后一直努力的降低 Angular 的学习成本和代码量，但我个人觉得这些努力对于单人项目而言，都只是杯水车薪而已。

Team Project（团队项目）

团队项目和单人项目差距太大了。

团队项目意味着项目不小、逻辑不简单、代码量不少，成长速度不慢。不然也不需要这么多人嘛。

人多意味着要分工，分工意味着要协作，那代码就得规范，风格就得统一。

人员流动也是一个需要考虑的问题。单人项目，开发者走了项目往往也垮了。

团队可不一样，一个走了，你得再找一个补上。招人的难度，新人上手的速度，这些都是需要考量的。

项目成长速度快，意味着代码需要具备可维护性，可扩展性，最好还配上一个自动化测试，不然每一次新增需求，修改代码后，牵一发动全身，bug 盛出不穷，谁还敢改呢？

综合上述这些情况，我觉得一个适合团队项目的框架应该具备以下这些特色：

代码规范，统一风格。

不仅仅是团队内的风格，还必须符合市场风格，因为需要考虑到人员流动。
市场通用性。

一个冷门的框架，会加大招人的难度，同时也会提高对旧人的依赖度。这两点都不利于项目发展。
框架的更新与稳定性。

项目在成长，框架自然也必须跟着成长。但如果每一次框架迭代更新都产生 breaking change，那将会给项目带来许多额外的开发成本，所以框架的更新与稳定性也需要被考量。

Angular 在代码规范，统一风格这一点上，做的非常好，无可挑剔。

Angular 不算是通用框架，有些类型的项目偏爱 Angular，比如管理系统，绝对热门。有些类型则完全排除 Angular，比如企业网站，绝对冷门。

Angular 处理 breaking change，migration 都做的很不错，虽然也会有 breanking change，但迁移文档清晰，再加上有辅助工具，这些都大大的降低了项目升级的成本。

Angular 迭代更新的速度不快，在 v14 以前，好几年才会推出一些不完整的小功能。幸好，v14 版本以后，哇！我只能用突飞猛进来形容。

综上，我觉得 Angular 是适用于团队项目的。但是！React 和 Vue 未必就输给 Angular。别忘了，Angular 有着高额的学习成本，另外，Angular 的市场通用性也没有比 React 和 Vue 高。

Big Team Project（大团队项目）

团队项目和大团队项目并没有本质上的区别，它只是量增加了而已，所以不会有新元素需要我们考量。

如果一个团队项目适合使用 Angular，那随着它越长越大，Angular 的优点只会越来越大。

学习 Angular 的预备条件

坊间有许多谣言说 Angular 的学习门槛高、曲线陡峭、概念多、复杂等等。

我想说...其实这些都是真的。

Angular 团队是一群不爱创新，爱 follow 标准，爱小题大做的一群人。（了解这群人的特性，对理解 Angular 很有帮助）

任何一个问题的解决方案，你都可以看见它背后的深(小)谋(题)远(大)虑(做)...看见它出自于某某远古伟大的概念...依据了某某远古伟大的标准...

那它为什么要这么搞呢? 其实很简单，因为要稳定，你不深谋远虑怎么避免 breaking change 呢？你不 follow 远古概念，怎么知道新概念可以活下去呢（至少远古的活了下来）？你没有标准，出事情的时候要怎样补救呢。

所以这些都是使用 Angular 的代价和成本。

举个例子，Angular 的 Component 对标的是 W3C 的 Web Component。

Angular Form 对标原生 HTML Form。

它们的概念和玩法高度相似。你甚至可以认为 Angular 就是 Web Component 和 HTML Form 的优化和扩展版本，骨子里都是一个东西，一个思路。

所以呢，要学好 Angular，首先需要找到它对标参照的概念和方法去学习，比如 Web Component、Form、Dependency Inject、HttpClient 等等。然后在那些基础上再学习 Angular 扩展出的特性。

这样才能学好 Angular。本系列教程也会依据这个方式去教。

更新：2020 - 2022 年 Angular 团队换了一大批人，这群人多了一个重要得特性 -- 愿意聆听。

再补充一点，TypeScript 和 RxJS 也是学习 Angular 的必备技能 (不需要到精通，但至少要熟练)，如果大家对它们不熟悉的话，建议先阅读下面这几篇文章：

Angular 还火吗? 会不会被 Google 砍掉?

传说 Google 有一个关门部，专门杀掉 Google 的项目，距今已经杀掉了 293 个项目。 AngularJS (Angular 的前生) 就是其中一个。

上面提到 Angular 的学习成本很高，如果哪天 Google 突然把它砍了，那不是白学了吗?

担心是对的，但也不用过分担心。就目前的局势来看。 Google 并没有计划杀掉 Angular。甚至可以说 Angular 最糟糕的时代已经过去了。目前算是欣欣向荣的。

至于 Angular 会火起来吗? 这是不可能的。因为 Angular 的定位和思想已经注定了它不会大受欢迎。就类似 React 的 Redux 一样。它的 time travel 非常厉害，但是绝大部分项目是不需要的。

当年之所以会火，只是因为 React 还没有推出 Hook 而已。 Angular 曾经也火过，但那也只是因为 Vue 还不完善而已。

总结：不火，而且越来越凉。但短期内 (3-5年) 完全看不出一丁点被砍掉的迹象。

聊聊那些年 Angular 的坎坷路

1. 阔时代的设计

AngularJS 1.0 是在 2009 发布的。开始的定位是帮助设计师快速搭建原型。但其 MVVM 的思想也收到了前端开发者的喜爱。

于是就开始走偏了。

巅峰时期 Angular 1.2 是在 2014 年。当时同类产品有 knockoutjs，Embed.js，Backbone.js，还有司徒正美的 Avalon。

AngularJS 无疑是里面最优秀的，但它依然存在太多太多的问题。试想想大中小项目统统都用 AngularJS。它一开始的定位又不是这些，怎么可能会做得好呢。

于是 Angular 团队想来一个彻底的革新。他们设计出了一款完全不符合那个时代的产品 Angular。

它就像当年 Tesla Model S 刚问世的的时候，很新潮、很厉害，但是一点都不实际，上哪充电啊?

TypeScript 1.8 可以用在 Production？用 SystemJS 来 build 项目？连 Webpack 都没有？

就因为这样一个阔时代的产品，让所有期待的粉丝瞬间脱粉了。

2. 替代品的崛起

Vue 的渐进式完全满足了迷茫中的 AngularJS 使用者。 React 则开启了另一条康庄大道。

至此 Angular 阔时代设计方案成功掉粉无数。随时可能被关门部盯上...

3. 错误的战略，痛失翻盘希望

随着 TypeScript 和工程化的普及。使用 Angular 的成本得到了大大的降低，Angular 似乎迎来了逆风翻盘的希望。

可惜的是，Angular 团队选择了无视所有支持者的 Feature Request，孤注一掷的去搞 render engine。

以至于在许多年里，Angular 一直没有推出 new Features，bug 也没有 fix。一个 render engine 就搞了 3 年。

粉丝数直接掉到谷底。

4. 内部纷争

2020 年是 Angular 离死亡最接近的一年，参考 No，I don't want to become an Angular GDE

许多核心队员纷纷离开。几乎是换了一次血。许多粉丝很担心是否 Angular 还会受到 Google 的青睐，还是会让 Flutter 取而代之。

人心惶惶的一年。。。

5. 迎来曙光

庆幸的是，新成员没有辜负前辈们的努力。 Angular 默默的翻新了几个版本后，终于在 v14，v15 迎来了稳定的发展。

从 roadmap 我们可以看到 Angular 团队依然再努力着让 Angular 变得更好。而且是按部就班的去做。稳定持续输出正是我们期望 Angular 做到的。

我曾经以为 Angular 会在 v10 或 v11 达到稳定版本。但以目前的进度来看，v15 以后才只是开始，相信 v20 以后 Angular 将成为一款人见人爱的大项目方案。

我们就提前几年开始学习它吧。

Angular 的断层问题

下图是 Angular npm last 7 days 的下载数量

你没有看错 v9.0.0 是最多人下载的版本，那是 2020 年发布的。

Angular 从 v14.0.0 开始有比较大的改动 (因为换了一批人，想法方向不一样了)。

这些改动大部分不是增加了新功能，而是修改了语法 (coding styles)。

Angular Team 的动机是想透过修改语法来降低学习成本，比如它们除去了：

Decorator (replaced by Signal & Global Functon)
NgModule (replaced by Standalone Component)
Zone.js (replaced by Signal)
RxJS (replaced by Signal)
指令微语法 (replaced by Control Flow)

动机虽然是好的，但是这类型的改动往往会让开发者形成断层。

也就是说会有一部分人一直停留在旧的版本 (比如 v9.0.0)，有另一部人会使用最新的版本 (v16, v17)。

会出现这种情形也很正常，因为这些改动最大的利益在于降低了学习成本，这只对新人有意义，对旧人来说利益很小甚至是有害的。

时至今日，Angular Material 源码中连一行 Signal 的代码也没有，从这里也能看出它们自己也觉得不值得。

断层对 Angular 的伤害是很大的：

向后兼容

保持对旧版本的兼容会大大增加代码设计的难度，代码量，维护，通通增加。
学习资源混乱

Angular 团队自己的教程就很乱，

angular.dev 不完整，angular.io 是旧的，你要看哪一个学习？

你该怎么选？

如果你是一名 Angular 开发者，目前掌握着 v9 的能力，维护者 v9 的项目，你可能会挺纠结的。

你会感觉自己正在被淘汰，但又不知道是否该学新的 Angular 或者干脆转投 Vue，React。

我给你的建议是，先继续看我的教程，如果你感觉吃力，那我建议你改投 Vue，React。

如果你觉得还可以，那看完它以后，尝试用新的 coding styles 去做新项目，或者新功能，一点一点的升级。

什么项目 "适合" 或 "可以考虑" 使用 Angular

小中大项目

坊间有许多谣传，说 Angular 适合 "大项目"，这给人一种 Angular 很牛逼、很难、会用的人都很厉害的错觉。

但其实呢，Angular 是可以用于不同级别的项目的，Angular 团队的 Emma 就在 YouTube 介绍过 Angular 3 种不同级别的项目。

小项目：I Miss My Cafe（Solo Project）

中项目：Coffee Table Talks（Team Project）

大项目：ClickUp（Big Team Project）

大中小其实很难理解，这里我提供一些衡量标准作为参考。

小项目的标准是

简单
结构简单、功能简单、业务简单，就是那种三言两语讲的清楚的简单。
不稳定
所有大项目都是从小项目开始。
不需要维护
功能简单，实现自然也不会复杂。
这时测试就可以省略，代码可读性，可扩展性都可以被省略掉。

中型项目的标准

more than easy
虽然说的清楚结构、功能、业务。但绝非像小项目那样三言两语。
no more 试水
中型项目通常会建立在小项目试水以后。
需要短期维护和升级 – 中型项目会有一个开发与试用阶段，这个阶段可能会维持 3 - 6 个月。项目会一直处于迭代开发阶段。需要边跑、边加、边改。
这个阶段是最考验开发技术的。庆幸的是，这个阶段不会太长。而且越靠后越轻松。
稳定期 – 经过 6 个月的打磨，项目会进入稳定期。往后项目会一直停留在当前版本，只做基本维护不再增加新功能。

大项目的标准

1. 复杂 – 结构、功能、业务都复杂。复杂大多表现为：

a. “多”。什么都多，体验多、功能多、逻辑多。多不代表乱，它只是多。

b. "例外"。当什么都 "多" 起来后，统一是管理的正道，但业务需求总会有许许多多的例外。这就导致了东西变得复杂。（但你又拿它没辙）

2. 需要长期保持升级和维护 – 大型项目在立项时就定了长远的方向，它不只有短期目标，还有长期目标。

这个阶段是最考验开发技术的，很不幸的是，这个阶段会一直持续直到项目结束。

小中大项目的比喻

小项目像 100 米短跑，跑得快最重要，冲就对了。

中型项目像 400 米短跑，前面不可以太冲，要留点力，最后 100 米是关键。越靠近终点越可以放手冲刺。

大型项目像马拉松，你需要有策略有周期的去用力，何时快跑、何时休息、保持循环，这样才可以一直稳定输出。

小中大项目例子

AngularJS 1.x 最初是一个小项目，它的定位是一款 MVVM 工具。服务的对象是设计师。让设计师可以不用搞 jQuery 做出一些简单的 prototype。

定位清晰，功能简单，idea 新颖。

后来，由于很多前端开发人员也爱上了它，所以就变成了一款中型的项目。一直迭代翻新直到 Angular 2.0 的构思出现，1.x 才进入稳定期 (不再加新功能)。

1.x 中期的版本是最糟糕的，因为立项时并没有预设要满足这么多需求 (根基不好)，以至于被许多使用者吐槽（慢、肿、麻烦）

Angular 2.0 立项就是大型项目。长期维护升级。

从 2.0 版本到现在的 16.0。 Angular 在使用上并没有大变化。TypeScript，Component，DI 还是那一套东东。

对比 React 的 Redux 到后来的 Hook，Vue 2.0 到 3.0 的变革，Angular 相对而言算是比较稳定的。

Angular 不适合小项目

两个原因

1. 产品定位 – Angular 走的是 Tesla 的产品路线。一开始只推出 Model S 最豪华的版本 (适合大项目)，有钱人才买得起（那一年会 TypeScript 的人并不多）

后来才开始关注平民，推出 Model 3（例如：Angular 15 的 standalone component）。

由此可见，品牌方的定位根本不是小项目人群，你硬要用还吐槽，那不是装可爱吗。。。

2. 替代方案太多了。

React、Vue、Svelte 哪一个不具备替代 Angular 做小项目的能力?

招人，学习教程，哪一个比 Angular 少?

3. Angular 的优势并不是没有代价的

Angular 的 "好" 是用 Angular 的 "坏" 换来的。比如维护成本低，是用学习成本和开发成本换来的。

对于需要长期维护的项目，这个交换或许是值得的，但是小项目并不需要长期维护丫。那增加的学习成本和开发成本就变得不划算了。

例外

凡是都有例外，对于小项目，Angular 没有什么特别优势，反而条条框框太多，但如果你不在意这些，或者你已习惯了这些。

比如你团队长期都是用 Angular 的一群人，那也没有必要为了开发一个小项目去学习 React、Vue、Svelte。用 Angular 其实也是可以的。

Angular 不太适合中型项目

如果世上没有 React、Vue。那么 Angular 是可以的。但是放一起选的话，我还是不推荐 Angular。原因和上面一样。只能说既生瑜何生亮，

在迭代期间，你会感觉 Angular 非常棒，但进入稳定期以后，你会发现之前的努力视乎后续就没有回报了。心里难免有点不平衡。

Angular 适合大项目

无风不起浪，坊间谣传便是始于我这类文章。。。

两个原因

1. 产品定位 – Angular 的定位人群不是社区，而是 Google 团队，而 Google 团队做的项目大部分都是大项目（需要长期维护升级，并且保持稳定）的 Web Application。

比如 : Gmail，Google Ads，Tag Manager，Google Analytics，Google Cloud

而这些项目刚好又偏向信息管理系统，于是就有了 Angular 适合 "大项目" 和 "后台管理系统" 的传闻了。

2. Angular 对项目长期维护的重视

大项目最重要、最苦、最考验技术的阶段就是长期的迭代、升级、维护。 Angular 本身就是大项目，而它的受众目标 (Google Team) 做的也是大项目，所以它很了解其中的苦。

Angular 对向后兼容和升级体验很重视。因为它要求使用者一直保持最新的 Angular 版本，所以升级的体验必须友好。

为此，Angular 有很正规的 Versioning and Releases。

比如，一个功能会先标签为 "即将废弃"。让使用者有足够的时间去升级。

然后才正式废弃，而即便废弃了也可以通过 use legacy mode 来 by pass。

另外，尽可能少的 breaking change 也是 Angular 的宗旨。为此 Angular 又搞了一堆的中间接口。哪怕 Angular Team 重写了整个底层核心 render engine 代码，上层接口也没有任何 breaking change。

框架的评分标准

开发这么多年，总结出一些框架需要具备的能力。这里提供给大家参考 (只限业务程序员)

1. 提供底层功能

这个是我觉得最基本的能力。我们用框架就是不想自己去写那些底层的代码。

底层代码的特色就是离业务很远，需要特定知识，各个项目都通用，写一次用一辈子。

这类代码，你让我们业务程序员去写，不是大材小用了吗。

2. 性能 & 安全

业务程序员眼里只有管理，没有性能和安全。为了代码可读性，牺牲性能是很常见的。

如果框架没有办法补上我们丢失的性能，那我要你何用？

安全? OWASP? 为了避免 SQL Inject，我可是直接用 ORM 的。你让我写 SQL Parameter? 我懒得理你。。。

所以框架必须替我们顾全性能和安全。

3. 扩展接口

当你发现底层功能不够用时，你已经很不爽了。更让你发火的是，你无法扩展它。只能自己实现一遍底层功能。。。

没有一个业务程序员可以忍受这样的事儿。

4. 开发体验

重复的声明，多余的表达。这些都是最扣开发体验分数的。你够聪明就应该可以推导出我的意图。但是你没有。。。

5. 学习体验

一个好的框架应该是通过少量记忆 + 逻辑 + 直觉来使用的。

没有逻辑，意味着得死背。不符合直觉意味着每次都要提醒。谁要学这样的东西。

Angular 符合标准吗?

我觉得吧... 还有很长一段距离... Angular 有许多底层功能是不完整的。扩展接口也不完善。

这和我用 .NET Core 的体验差很多 .NET Core 通常你是可以找到扩展接口的。

学习体验差，很多时候看源码会比你推理，测试，读文档还高效...这说明什么？

说明它设计的不逻辑，而且文档还没声明。