Performance of a shared Angular Material module that may include many Component modules?

Question

The Angular Material component usage guide suggests creating a shared module to include multiple components. My question here is about shared module usage.

Shared Angular Material Module

import {MatButtonModule} from '@angular/material/button';
import {MatCheckboxModule} from '@angular/material/checkbox';

@NgModule({
  imports: [MatButtonModule, MatCheckboxModule],
  exports: [MatButtonModule, MatCheckboxModule],
})
export class MyOwnCustomMaterialModule { }

This shared module could contain many component modules. Maybe 50 or more. Let's say I have imported this shared module into another module where it needs only one material module. In such cases, is there a performance penalty, for example, for loading time? Are shared modules cached?

Answer 1

The NgModule FAQs include the following notes.

What if I import the same module twice?

That's not a problem. When three modules all import Module 'A', Angular evaluates Module 'A' once, the first time it encounters it, and doesn't do so again.

That's true at whatever level A appears in a hierarchy of imported NgModules. When Module 'B' imports Module 'A', Module 'C' imports 'B', and Module 'D' imports [C, B, A], then 'D' triggers the evaluation of 'C', which triggers the evaluation of 'B', which evaluates 'A'. When Angular gets to the 'B' and 'A' in 'D', they're already cached and ready to go.

Angular doesn't like NgModules with circular references, so don't let Module 'A' import Module 'B', which imports Module 'A'.

---

There is an additional performance benefit by only including the Angular Material component modules needed for a specific application.

The deprecation notice for Angular Material beta.3 states:

MaterialModule

MaterialModule (and MaterialRootModule) have been marked as deprecated. We've found that, with the current state of tree-shaking in the world, that using an aggregate NgModule like MaterialModule leads to tools not being able to eliminate code for components that aren't used.

In order to ensure that users end up with the smallest code size possible, we're deprecating MaterialModule, to be removed in the a subsequent release.

To replace MaterialModule, users can create their own "Material" module within their application (e.g., GmailMaterialModule) that imports only the set of components actually used in the application.

This same advice still applies as of 2019. The Angular Material getting started guide states:

Alternatively, you can create a separate NgModule that imports and then re-exports all of the Angular Material components that you will use in your application. By exporting them again, other modules can simply include your CustomMaterialModule wherever Material components are needed, and automatically get all of the exported Material modules. A good place for importing/exporting the application-wide Material modules is the SharedModule.