Angular 的开发人员提出了一个 RFC(request for comment) 提案，考虑将 NgModules 设为可选。此举旨在将 Angular 转向更简单的重用模型，以改善开发人员体验。
该 RFC 于今年 10 月 8 日发布，预计最迟于 11 月 8 日结束。“此 RFC 的目标是与社区一起验证设计，征求对开放问题的反馈，并通过此提案中包含的非生产就绪原型进行实验。”
![]()
根据介绍，NgModules 是 Angular 的核心概念之一；刚接触 Angular 的开发者在创建哪怕是最简单的"Hello, World"应用程序之前，都需要了解这个概念。更重要的是，NgModules 充当着一个“推理和重用单元”的角色：
- libraries publish NgModules
- lazy-loading 是以 NgModule 为中心的，等等
鉴于 NgModule 在 Angular 中的核心作用，很难孤立地对组件、指令和管道进行推理。RFC 指出，在当下的 Angular 中，开发人员使用 NgModule 来管理依赖项。当一个组件需要使用另一个组件、指令、管道或 provider（无论是来自同一应用程序内，还是来自 NPM 上的第三方库）时，都不会直接引用依赖项。而当一个 NgModule 被导入，其中则包含导出的组件、指令和管道以及配置的 providers。因此即使是最简单的“Hello, World”，开发人员都必须创建一个 NgModule 来引导。
RFC 认为，让 Angular 在概念上以 NgModule 为中心会对开发人员体验产生负面影响；并进行了举例论证：
- 编写组件比编写类或模板更复杂。
- 围绕加载和渲染的 API 过于复杂且容易被误用。
- 阅读组件代码不足以理解组件行为。
- Angular 工具必须处理组件对其 NgModule 上下文的“隐式”依赖关系。
而该提案的好处就在于推动 Angular 向组件、指令和管道发挥更核心作用的方向发展，它们是独立的并且可以安全地直接导入/使用。
- 简化了 Angular 的 mental model
- 使新的 API 可以用于使用组件和指令（例如细粒度的延迟加载）
- 提高了 Angular 工具高效处理代码的能力。
所有这些好处结合起来将使得 Angular 更易于使用、更易于推理、不那么冗长且编译速度更快。
值得注意的是，该提案并不是要从 Angular 中删除 NgModule 的概念，而是让它在典型开发任务中成为可选项。不过 Angular 开发团队也表示，在将来的某个时刻，他们或许也会考虑完全删除 NgModules。
更多详细信息可查看提案。
