关于 Angular 里 module 和 Component 包含粒度的一个讨论

有一位 Angular 开发者提出了这样一个问题：

我们有一个中型 Angular 应用程序，大概包含了 150 个 Component.

其中许多组件需要注入服务类并需要在应用程序中声明其他组件。

我们一直在尝试并寻找对开发人员更友好的一种方法。

目前的做法是，为每个组件创建一个模块。模块导入子组件模块并提供（或导入）组件所需的所有服务。它还导出组件本身，以便其他组件可以通过模块引用它。

它使组件的组合变得轻而易举，并且组件的测试 fixture 的设置非常简单（这是以前重复依赖项和子组件树依赖项的地方）。

这种方法似乎与基于组件的架构相匹配，并允许围绕组件依赖项进行封装。

一个问题是，拥有这么多模块(module)对性能（或其他）有什么影响？

回答

如果一个 module 依赖于其他组件，则可以只包含与每个直接依赖的组件相关的组件模块，而不需要关心间接依赖。

这种方法起初可能看起来需要更多的开发量，但从长远上来看，它会带来更少的维护问题。

考虑这样一个场景：

• Component A 依赖于 B，B 依赖于 C
• 那么首先创建 ModuleC，声明 Component C
• Module B 声明 Component B，同时导入 module C
• ModuleA 声明 Component A，同时导入 ModuleB. Module A 不需要直接导入 Module C.

如果由于项目原因，现在 Component B 需要依赖 Component D，比如在 HTML template 里使用如下语句：

<my-component-d>

于是我们只需要修改 Module B 即可，所有依赖于 Component B 的 Component 都可以继续正常工作。

Angular 里依赖管理的一个典型例子：

<script src="build/bundle.js"></script>

或者将 vendor.js 和 main.js 分开：

<script src="build/vendor.js"></script>
<script src="build/main.js"></script>

这样依赖关系可以通过形如 webpack 这种 module bundle 自动管理。

There is the approach of making a module with lots of components and just import it, but you end up importing several components that you don't use and if you use lazy loading, your modules may become huge, unless you import that module in AppModule, making your boot time increase.

在 Feature Module 里 import Component Module:

feature.module.ts:
imports: [
    ComponentAModule,
    ComponentBModule,
    ComponentCModule,
]