有一位 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 裡使用如下語句：

```html
<my-component-d>
```

於是我們只需要修改 Module B 即可，所有依賴於 Component B 的 Component 都可以繼續正常工作。

Angular 裡依賴管理的一個典型例子：

```html
<div></div>
```

或者將 vendor.js 和 main.js 分開：

```html
<div></div>
<div></div>
```

這樣依賴關係可以透過形如 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:

```typescript

feature.module.ts:
imports: [
    ComponentAModule,
    ComponentBModule,
    ComponentCModule,
]
```</my-component-d>

關於 Angular 裡 module 和 Component 包含粒度的一個討論

相關文章