Anatomy of an Angular Module

In Angular, we get modules, known as NgModules, to act as the unit that glues together an app or features within an app. All Angular apps have one root module, the app module, that deals with unifying the whole app together. It’s also a best practice to breakdown individual features of an app into their own module. This practice enables things such as lazy loading or preloading certain features.

This post covers NgModules in Angular 2+

Angular modules are not to be confused with ES6 modules. They are two distinct things.

Here’s what a barebones NgModule looks like:

// ...ES6 module imports

  declarations: [ ... ],
  imports: [ ... ],
  providers: [ ... ],
  bootstrap: [ ... ],
  entryComponents: [ ... ],
  exports: [ ... ]
export class MyModule { }

And here’s an example of what it can look like with actual members:


import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { MaterialModule } from '@angular/material';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

import { AppComponent } from './app.component';
import { VideoPlayerComponent } from './video-player/video-player.component';
import { ConfirmationDialogComponent } from './confirmation-dialog/confirmation-dialog.component';

import { VideoService } from './services/video.service';

  declarations: [
  imports: [
  providers: [VideoService],
  bootstrap: [AppComponent],
  entryComponents: [ConfirmationDialogComponent]
export class AppModule { }

Breaking It Down

Let’s briefly explain each entry in the @NgModule decorator:


This is to specify the components, pipes and directives that should be part of the module.


This is to import other modules that have exported members to be used in templates of components that are part of the NgModule. For example, BrowserModule re-exports CommonModule, which makes available the built-in NgIf and NgFor directives.

RouterModule, BrowserModule, FormsModule, HttpModule and BrowserAnimationsModule are examples of commonly imported modules.


If you want to export members of the module so that they can be used in component templates of other modules, these members would go in the exports array.

In the case of the CommonModule, for example, COMMON_DIRECTIVES and COMMON_PIPES are exported, which is what is made available to component templates when you import BrowserModule or CommonModule into your own NgModules.


This is to define the root component, which is often called AppComponent. This means that bootstrap should contain only one member, and that it should be defined only in the main app module.


This is where injectables go. Things like services, route guards and http interceptors are example of injectables that should be part of the providers array. They will be made available everywhere in the app once they have been provided. This is why services are often provided in the root app module.


This is for components that can’t be found by the Angular compiler during compilation time because they are not referenced anywhere in component templates. It’s common for routed components not to be referenced at all in templates, but Angular takes care of adding those to entryComponents automatically, so there’s no need to add those yourself.

Components that should go into entryComponents are not that common. A good example would be Angular Material dialogs, because they are created dynamically, and the Angular compiler wouldn’t know about them otherwise.

✖ Clear

🕵 Search Results

🔎 Searching...