Angular 社区最热门问题（2020 年 10 月）
在首场 Angular Discord 问答活动中，Angular 团队成员 Minko Gechev 回答了社区中最热门的问题。继续阅读，了解大家提出了哪些问题以及 Minko 是如何解答的！
您还有其他关于 Angular 的问题，想要与社区互动，或者对下次问答环节有疑问？加入Angular Discord吧！
非常感谢主持人delasteve、@beeman和Alex Okrushko促成此事。完整录像可在YouTube上找到。
所有问题
- RxJS 在 Angular 中扮演什么角色？随着越来越多的人使用 Observable，是否有可能进行更深入的集成（例如将 @Input() 作为 Observable）？
- 在 Ivy 版本之前，Angular 的一个座右铭是“永远不要触碰 DOM”，因为我们总是需要使用平台抽象层（例如通过 Renderer2），但自从 Ivy 版本之后，这种情况似乎发生了改变。目前的建议是什么？
- 您认为两年后Angular会发展成什么样？对开发者来说，主要变化会是什么？
- Angular Elements 的状态和优先级是什么？Ivy 如何影响 Angular Elements？
- 目前使用响应式表单时不存在类型安全问题。我们能否期待在响应式表单中实现类型安全？
- Angular Material 的未来发展方向是什么？Material 会有哪些新功能推出？
- ::ng-deep 伪类有助于在某些组件组合模式下保持风格一致性，但它已被弃用。::ng-deep 还将支持多久？应该使用哪些模式来逐步淘汰 ::ng-deep？
- Bazel 与 Angular 的集成（可能最终会集成到 CLI 中）何时才能从 Labs 阶段走向成熟？您认为它与 Nx 目前提供的功能相比如何？
- 如果组件没有路由，是否支持延迟加载？官方是否支持？
- 随着浏览器的成熟，ViewEncapsulation.Shadow DOM 是否应该成为 Angular 组件的默认设置？该特性最初的设计愿景是什么？
- 能否简要介绍一下Angular产品路线图的制定过程？我很想了解一下最重要的利益相关者是谁（社区还是谷歌），以及优先级是如何确定的。
- 路线图中提到了开发工具。目前的开发进度如何？我们可以期待哪些功能？
- 我手下有多个团队在开发各自的 Angular 项目。您设想如何构建和部署多个 Angular 应用，并让它们在同一个页面上高效地协同运行？这是否属于模块联合的范畴？
- Angular 11 有哪些值得关注的地方？
- 关于父组件和子组件之间共享数据的问题，您能否详细说明使用 ViewChild 和使用 Service 的优势，以及反过来使用 ViewChild 和 Service 的优势？是否存在某些特定情况应该优先使用其中一种，还是仅仅取决于开发者的个人偏好？
- 您如何看待当前 JS 生态系统和流行框架的现状？与其他框架相比，Angular 在提升用户体验方面有哪些优势？
RxJS 在 Angular 中扮演什么角色？随着越来越多的人使用 Observable，是否有可能进行更深入的集成（例如将 @Input() 作为 Observable）？
在内部对 Observables 进行硬性依赖会带来一些挑战@angular/core。虽然目前存在这种硬性依赖，但未来可能会放宽。
我们对进一步加强对 RxJS 的依赖持非常谨慎的态度。
——明科·格切夫
Minko 列出了不集成 RxJS 的原因，以下是这些原因：
- 包大小：RxJS 和操作符会增加包的大小。对于不想使用 RxJS 功能的用户来说，这纯粹是浪费资源。
- 学习曲线：很多用户对 RxJS 都很感兴趣，这些用户大多是“高级用户”。然而，对于 Angular 新手来说，Observables 又是他们需要学习的新知识。学习 RxJS 会成为新手提高工作效率的又一道障碍。
- 组件加载方式的限制：Angular 团队正在研究如何利用渐进式水合实现组件的乱序加载。但 Observables 会阻碍团队实现这一目标。具体来说，框架需要预先知道订阅者的存在，才能确定组件的加载顺序。
这并不意味着@Inputs不能使用 Observables。完全可以同时支持传统方式和@InputObservables。但是，支持两种方式也会带来额外的成本。
Beeman提出了另一个问题：如果Observables成为Web标准并像Promise一样作为浏览器的一部分发布，会有什么不同吗？Minko回答说，如果Observables成为浏览器的一部分，这将有助于减小包的大小。然而，它并不能解决另外两个问题——降低学习难度和限制Angular未来的发展。
鉴于这些困难，Minko 提供了一些关于时间表的信息：我们不应该期望在接下来的几个月（甚至更长时间）内得到关于“输入作为可观察对象”这一主题的明确答案。
2. 在 Ivy 版本之前，Angular 的一个座右铭是“永远不要触碰 DOM”，因为我们总是需要使用平台抽象层（例如通过 Renderer2），但自从 Ivy 版本之后，这种情况似乎发生了改变。目前的建议是什么？
Minko解释说，人们的思维方式已经与之前的建议有所不同。
如果你在开发 Web 应用程序，那么直接操作 DOM 完全没问题。
——明科·格切夫
此外，不修改 DOM 的建议并非主要针对 Ivy，而是与您希望运行 Angular 应用的平台有关。新的建议如下：
- 如果你的应用只在网页上运行，你可以直接修改 DOM。但需要注意一些事项：如果你想查询组件的结构，请使用 Angular 的相关特性，例如 `@ViewChild`注解。这是因为 Angular 内部已经预先了解了组件结构和模板中当前存在哪些元素。如果你确实需要写入 DOM，当然可以这样做。
- 如果您计划开发一款非Web平台的跨平台应用程序，则需要格外谨慎。例如，如果您使用NativeScript（一种使用Angular为Android和iOS编写原生应用程序的方法）开发应用程序，则不应使用DOM API，因为没有DOM可供修改。
3. 你认为两年后 Angular 会发展成什么样？对开发者来说，主要变化会是什么？
Minko提到了一些开发者可以从Angular中获得的益处：
我们将 Angular 本身的各个版本视为功能发布版本。
——明科·格切夫
- 您将获得一些新功能，这些功能将提升您的工作效率、改进编译器并改善您的开发体验——而且无需担心会造成破坏性变更。只需运行命令
ng update即可获取新版本并体验这些新功能。这称为功能发布。 - 不重写：我们没有像从 Angular.JS 过渡到 Angular 时那样进行大规模重写的计划。我们的目标是将 Angular 打造成一个常青框架，您可以像日常工作和持续集成 (CI) 一样轻松升级。每次升级，您都将获得更快的应用程序
ng update。Angular 团队将尽可能减少破坏性变更。但是，如果底层平台发生变化，迫使团队重新考虑某些架构决策，则可能需要进行破坏性变更。 - 还有一些规模更大的项目，例如Zone-less和 Angular Devtools，它们将产生重大影响。此外，还有一些项目致力于让初学者更容易上手该框架。
- 稳定性：Beeman 提出了一个问题，比较了 Angular 和 React 的情况（例如，将基于类的组件迁移到基于函数的组件）。Minko 回答说，Angular 的目标是采用统一的开发方式，以便于在不同项目之间切换。
4. Angular Elements 的状态和优先级是什么？Ivy 如何影响 Angular Elements？
Angular Elements 运行良好，并被社区广泛采用。Angular 团队维护并将继续维护 Web Components。社区目前有两个不同的需求：与 Web Components 的兼容性以及构建系统和分发方式。
Angular Elements 目前运行良好，并且会继续正常运行，我们目前没有计划对此进行任何更改。
——明科·格切夫
与 Web Components 的兼容性：
Web Components 和 Angular 在功能相似的情况下存在一些差异。例如，Web Components 的 Shadow DOM 插槽的行为与 Angular 中 ng-content 的内容投影和默认内容有所不同。Angular 团队正在积极致力于提高与 Web 标准的兼容性。
构建系统和分发：
使用 Angular Elements 的一大问题是组件包的大小，这些组件会被分发到不同的应用程序（例如 React 应用程序）中使用。优化 Angular Elements 的构建系统和分发方式来解决这个问题非常困难。Elements 是一个非常动态和灵活的系统。为了减小组件包的大小，你需要预先知道页面上的组件将使用 Angular 的哪些部分。这意味着你会牺牲一些灵活性——无法再使用不同的 Elements 动态地组装 UI。
一种分发方案是创建一个完整的 Angular UMD 包，将其添加到页面中，然后所有不同的 Angular Elements 组件都可以使用它。缺点是，需要添加的包体积相当大。这是因为 Angular 的设计初衷是支持 tree-shaking 优化，而 Elements 组件由于其所需的灵活性，无法做到这一点。
在构建和分发方面，Angular 团队目前没有任何计划，而且未来可能也不会有任何改进。目前没有简单的解决方案可以立即发布，并让团队能够继续推进相关工作。
一般来说，如果你有实际需要，就可以使用 Angular Elements。Minko 举了一个例子：一个团队使用 Angular Elements 向客户分发组件。客户在基于 WordPress、React 和其他技术的应用程序中使用这些组件。由于这些应用程序是供内部使用的，因此包大小对他们来说并不是主要问题。
5. 目前使用响应式表单时不存在类型安全问题。我们能否期待在响应式表单中看到类型安全？
正如 Minko 所述，这是 Angular 团队非常希望实现并正在积极努力的方向。目前仍有一些挑战正在解决中：首先，为表单添加类型安全功能会带来一些破坏性变更，因此需要提供清晰的应用程序更新路径。
除了响应式表单之外，还有一些技术难题可能会产生一些重大影响，因此我们需要更好地规划这些问题。
——明科·格切夫
另一个挑战是为动态表单添加类型定义。当您动态添加表单控件时，类型无法预先推断。Angular 团队目前正在考虑不同的方法和解决方案来应对这些挑战。
Angular 团队成员 Alex Rickabaugh 可能会撰写一篇博文，详细介绍技术挑战和可能的解决方案——敬请期待！
6. Angular Material 的未来发展方向是什么？Material 会有哪些新功能推出吗？
Angular 团队正在努力将 Angular Material 迁移到 MDC Web，这是 Material Design 团队官方发布的 Material Design 实现。Angular 将保留当前实现的公共 API，以便开发者轻松完成迁移。此次迁移的优势在于提升了可访问性，并与 Material Design 规范保持高度兼容。Mirko 估计，在 Angular Material 的所有开发时间中，约有 50% 用于迁移到 MDC，另外 50% 用于分析 Material Design 代码库中的问题，了解社区的需求（例如日期选择器）。
我们将保留现有的材料组件和公共 API，并将它们迁移到 MDC-Web。
——明科·格切夫
Minko 还谈到了 Angular Material 团队目前面临的挑战：由于组件的内部 DOM 结构发生了变化，迁移到 MDC Web 很可能会导致单元测试和端到端测试失效。尽管内部结构被视为私有 API 的一部分，但 Angular 团队仍然希望方便开发者在迁移后修复测试。为此，他们将提供测试框架和组件框架，供开发者在测试中使用。这种方法类似于页面对象在端到端测试中的工作方式。
Alex Okrushko补充道，Firebase控制台使用了Angular Material，并且它本身也是Angular Material测试套件的一部分。这有助于Angular Material团队充满信心地进行更改，因为Firebase控制台经过了大量的测试，包括屏幕截图对比和视觉测试——而其代码库接近100万行！
7. ::ng-deep 伪类有助于在某些组件组合模式下保持风格一致性，但它已被弃用。::ng-deep 还将支持多久？应该使用哪些模式来逐步淘汰 ::ng-deep？
Minko解释说，目前还没有更好的方法来替代已弃用的`::ng-deep`。这不仅是Angular的问题——Shadow DOM中也移除了与之匹配的功能（`/deep/`） 。然而，到目前为止，规范中还没有添加更好的方法。Angular团队将在找到更好的实现方式后（同时与Web标准组织合作）提供从`::ng-deep`的迁移路径，因为`::ng-deep`在谷歌内外都被广泛使用。
我们近期没有移除它的计划。实际上，鉴于目前显然没有解决办法，我认为弃用它是不合适的。
——明科·格切夫
结论是，虽然 ::ng-deep 已被弃用，但您仍然可以在应用程序中安全地使用它。
8. Bazel 与 Angular 的集成（可能最终会集成到 CLI 中）何时才能从 Labs 阶段走向成熟？您认为它与 Nx 目前提供的功能相比如何？
这是一个很大的话题，Minko 说他可以讲两个小时！简而言之，Angular 团队一直在尝试将 Angular CLI 从原生构建系统迁移到 Bazel 作为底层构建系统。Bazel 的表现非常出色，尤其是在包含多种技术的大型代码库中。
然而，使用 Bazel 也存在一些缺点：你需要配置构建图，包括项目的依赖项等等。编写构建文件通常需要手动完成。虽然工具可以自动生成构建文件，但生成构建文件并非易事，尤其是在使用动态语言时。最初的目标是向用户隐藏构建文件，以便用户可以像现在一样使用命令行界面 (CLI)，但底层使用的是 Bazel。问题在于，并非总是能够生成构建图。虽然自动生成大多数情况下都能正常工作，但一旦出现问题，就很难找出原因。
这种方法大概有 90% 的成功率，剩下的 10% 你则完全摸不着头脑。
——明科·格切夫
此外，该工具并非总能生成最优构建图，从而抵消了部分优势。Angular 团队最终认为，将 Bazel 与 Angular CLI 集成并非最佳方案，并已停止推进该集成工作。
Bazel 对于许多大型应用程序来说仍然适用。Bazel 已从 Angular Labs 正式发布，现在即可使用。目前有很多大型项目和企业都在使用 Bazel 来构建他们的 Angular 应用。
[Nx 是一种] 更符合人体工程学的方法，您可以充分利用它。
——明科·格切夫
Nx 可以很好地解决增量构建的问题，而且无需增加额外的配置开销。但同时，它不像 Bazel 那样提供强大的安全保证。有时，构建的封装性并非 100% 有效。不过，在大多数情况下，这仍然可以接受。Nx 仍然提供了一种更人性化的方法，您可以充分利用它。此外，Nx 还支持多种语言的插件，例如 Go。Minko 建议，如果您的项目遇到了瓶颈，并且想要尝试增量构建，可以先尝试 Nx，然后再根据实际情况选择 Bazel。
9. 如果组件没有路由，是否支持延迟加载？官方是否支持？
无需路由即可实现组件的懒加载，这是官方支持的，您可以放心使用。Minko 甚至建议在懒加载路由之外也进行组件懒加载，因为有时这可能是减少初始打包大小的唯一方法。
未来我们将提出更符合人体工程学的方法。
——明科·格切夫
从长远来看，Angular 团队希望提供一个更好的 API，用于在不使用路由的情况下实现组件的懒加载。这需要移除所谓的“ngfactories”，它们在 Ivy 版本之前很有用，但现在已不再适用。ngfactories 将被弃用，这将为更易用的 API 铺平道路。
10. 随着浏览器的成熟，ViewEncapsulation.Shadow DOM 是否应该成为 Angular 组件的默认设置？该特性的愿景是什么？
Angular 的愿景是长期大量使用 Web 标准，从而减小包的大小。为了确保 `ViewEncapsulation.Emulated` 的工作方式与 Shadow DOM 相同，并且 Angular 通过其创建的 polyfill 与 Web 标准兼容，还有很多工作要做。
11. 您能否简要解释一下Angular路线图的制定过程？我很想了解一下最重要的利益相关者是谁（社区还是谷歌），以及优先级是如何确定的。
Minko告诉我们，谷歌如此青睐Angular的原因在于，Angular在谷歌内外的使用方式差异极小。这让谷歌的工作更加轻松，因为新员工加入时就已经熟悉了谷歌内部使用的技术。Angular团队希望确保Angular在谷歌内外的使用方式尽可能地重合。
两者之间存在一些细微差别，主要集中在构建系统方面。在 Google 外部，通常使用 Webpack，而在 Google 内部，则使用不同的构建工具。Angular 的路线图上只有一项与 Google 相关的计划，即 Angular 与 Google 内部服务栈的集成。
对 Angular 团队来说，更艰巨的任务是确定所有功能请求的优先级——无论这些请求来自何处。例如，Angular 语言服务 (Angular Language Service) 的下载量高达 170 万次，即使是这个较小的组件，也收到了大量的请求、反馈和拉取请求。Minko 解释说，这些请求大多来自经验丰富的开发人员，他们非常清楚自己在做什么。
确保我们能够从初级开发者的角度看待问题也非常重要，这或许是最难的部分。
——明科·格切夫
为了确定优先级，Angular 团队会查看收到的功能请求及其请求频率。每位团队成员都会提出提案，然后进行讨论并排序。团队还会考虑需要解决的技术债务。Minko 解释说，在对每个提案进行排序时，从 Angular 新手开发者的角度看待问题既重要又困难——因为 Angular 团队的大多数成员都拥有丰富的行业经验。这些功能都存在争议。例如，严格模式虽然支持更激进的 tree shaking 和高级优化，但也使类型定义更加严格，从而增加了 Angular 的学习难度。
对于有争议的功能，Angular 团队有两种方法：一是发布 RFC（征求意见稿），这种方法可以收集到有价值的反馈，但缺点是容易让阅读功能跟踪器的高级用户感到不满；二是积极提高功能的可见度，例如发布功能公告、在 Angular 博客上发表文章，以及与经常接触新开发者的 Angular 培训师沟通。
12. 路线图中提到了开发工具。目前的开发进度如何？我们可以期待哪些功能？
我们将考虑如何以合适的方式使其对所有人开放，而不仅仅是对那些参与测试的人。
——明科·格切夫
目前有一些开发工具原型可以帮助开发者理解应用程序中的组件结构。这些新工具还能帮助你分析性能，并了解应用程序在变更检测过程中花费的时间。Angular 团队正在努力将这些开发工具集成到 Angular 公共 API 中，以确保长期稳定性。一旦完成集成，这些工具将向所有人开放！
13. 我手下有多个团队在开发各自的 Angular 项目。您设想如何构建和部署多个 Angular 应用，并让它们在同一个页面上高效地协同运行？这是否属于模块联合？
我们正在研究这个问题，模块联合可能是正确的解决方案。
——明科·格切夫
作为 Angular 11 的一部分，将提供一个可选的 Webpack 5 预览版，该预览版支持模块联合。目前还没有设计文档，但 Angular 团队正在研究这项功能，因为开发者经常提出模块联合支持的需求。
14. Angular 11 有哪些值得关注的地方？
Minko 向我们介绍了即将发布的版本中许多令人兴奋的新功能：
- 我们将推出更便捷的热模块重载 (HMR) 支持。这将使您在修改代码后更快地在浏览器中看到更改。虽然目前已支持 HMR，但启用后会更加简单。您只需使用一个简单的标志即可启用 HMR。
- Angular 团队与 James Henry（ESLint 团队）和社区密切合作，改进了 ESLint 支持，并提供了从 TSLint 到 ESLint 的迁移路径。
- Ivy 语言服务将提供可选预览版- 这意味着您的模板将拥有更好的类型检查和自动完成功能！
- Angular 11 中， Angular 编译器 Ngcc 的速度将提升 4 倍。这意味着您等待构建和重新构建完成的时间将大大减少。为了提升 Ngcc 的性能，Angular 贡献者 Joost 在对 Angular 编译器进行性能分析时，不得不加快 TypeScript 编译器的运行速度！这项改进将在 TypeScript 4.1 中实现——因此，当 Angular 支持 TypeScript 4.1 时，您将自动获得更快的构建速度。
15. 关于父组件和子组件之间共享数据，您能否详细说明使用 ViewChild 和使用 Service 的优势，以及反过来使用 ViewChild 和 Service 的优势？是否存在某些特定情况应该使用其中一种而不是另一种，还是仅仅是开发者的个人偏好？
Minko解释说，这主要是一个状态管理话题——Alex Okrushko刚刚就此做了一个精彩的演讲！如果你想了解更多关于状态管理以及如何在组件结构中传递状态的知识，请观看：https://www.youtube.com/watch?v =Azus3_CEkpw
16. 您如何看待当前的 JS 生态系统、流行的框架以及 Angular 与其他框架相比如何改善用户体验？
当我思考Angular最大的优势和强项时，我通常会想到四点，其中一些是Angular与其他框架相比更独特的。
——明科·格切夫
- Angular 具有很强的规范性。这意味着最佳实践已经融入到框架和工具（例如 Angular CLI）中。在生成项目时，Angular CLI 使用内置的样式指南，因此您看到的 Angular 应用程序大多具有相似的结构。您从一开始就使用 TypeScript，这为您带来了诸多优势。此外，Angular 还鼓励您使用依赖注入，这也被认为是一种最佳实践。
- Angular 的可扩展性非常出色——无论是简单的 Hello World 应用，还是代码量达数百万行的应用（例如 Firebase 控制台），它都能轻松应对。当然，Angular 并非万能——当代码量达到数百万行时，你仍然需要考虑状态管理以及如何架构应用。不过，Angular 已经提供了相应的构建系统和工具，并且经过验证，能够在大规模场景下稳定运行。
- Angular 具有常青特性：广泛的测试覆盖确保 Angular 的变更和拉取请求不会引入任何破坏性问题。在 Google 的单体仓库中，有超过 2600 个 Angular 应用。每个应用都使用不同的功能，这些功能都由各自的测试用例覆盖。这使得 Angular 能够提供自动迁移功能，将您的代码更新到最新版本，并且这些更新已经在所有这些项目中进行了测试。这样，每个人都可以自动使用最新版本的框架，而无需手动操作。
- 社区：有很多社区项目，例如状态管理框架、组件和工具。