Conceptualizing the Purpose of an Angular Module

At a high level, an Angular app is made up of three types of artifacts: components (which includes directives and pipes), child modules, and services. An Angular module encapsulates these artifacts as one compilation unit. In this guide, you will learn about the details of Angular modules and Angular's module hierarchy.

Modules are a way to organize an app and extend its capabilities with external libraries. Angular libraries are also built using Angular modules. Examples include FormsModule, HttpClientModule, and RouterModule. Many external libraries are also available as Angular modules, for example, Material Design, Ionic, and AngularFire2.

Angular components, directives, and pipes focus on particular feature areas, business domains, workflows, or common utilities. Angular services might be internally developed, like something you'd develop for yourself, or can be imported from external sources, such as the Angular router and HTTP client.

Modules can be eagerly loaded when the app starts or lazily loaded asynchronously by the router.

An Angular module's metadata, which is specified using the @NgModule decorator, does the following:

1. Declares which components, directives, and pipes belong to the module
2. Makes some of those components, directives, and pipes public so that other module's component templates can use them
3. Imports other modules with the components, directives, and pipes that components in the current module need
4. Provides services that other app components can use Source: https://angular.io/guide/ngmodules

Every Angular app has at least one module, which is called the root module or app-level module. You bootstrap this app-level module or root module to launch the application.

In a small app, the root module or app-level module is enough to organize different components, directives, pipes, and services. But as the app grows, you should refactor the root module into feature modules, which represents related functionality. You may then import these modules in the app-level module if you want these modules to be eagerly loaded or in the routing module through routes if you want them to be lazily loaded.

The following code is generated for the root module when you generate a new app using the Angular CLI:

Notice that in the NgModule directive, you are passing an object that has the following four array type properties:

1. declarations: In this array, you specify which components, directives, and pipes belong to this module.
2. imports: In this array, you import eagerly loaded modules.
3. providers: In this array, you specify all the services that can be used across the app in any component, directive, or pipe.
4. bootstrap: In this array, you specify the component that should be loaded at the start of the app.

Any feature module will have the first three arrays (declarations, imports, providers) but not the fourth array (bootstrap).

There are five types of feature modules:

1. Domain Feature Modules
2. Routed Feature Modules
3. Routing Modules
4. Service Feature Modules
5. Widget Feature Modules

The user experience, such as editing an event or placing an order, for a particular app is delivered by a domain feature module.

Domain feature modules rarely have providers. If they have providers, the lifetime of the provided services should be the same as the lifetime of the module. Domain feature modules are imported exactly once by a larger feature module.

They might be imported by the root AppModule of a small application that lacks routing.

In routed feature modules, the top components are the targets of router navigation routes. Their components never appear in the template of an external component. Routed feature modules rarely have providers. If they have providers, the lifetime of the provided services should be the same as the lifetime of the module.

The routing module define routes and provides the routing configuration. It adds router configuration to the module's import and separates routing concerns from its companion module. A routing module should only be imported by its companion module, and it does not have its own declarations.

Utility services such as messaging and accessing data are provided by service feature modules. These modules consist of providers only and have no declarations. The root AppModule is the only module that should import service modules.

Components, directives, and pipes are made available to external modules using widget feature modules. A widget feature module consists entirely of declarations and rarely has any providers.

Congratulations! You have learned about Angular's modular design and types of feature modules. Please refer to Module Types in Angular for more details.