This article summarizes the module concepts and the organizaton of modules.

1 Basic Concepts

An Angular module, called NgModule or simply module, is a class marked by the @NgModule decorator that takes a metadata object. The metadata provides the following information:

  • how to compile a component’s template.
  • how to configure an injector at runtime.
  • what are declared in this module: components, directives, and pipes.
  • what other modules are imported and used by this module.
  • what declarable (declared here or imported) are exported to public.
  • what services are provided to public.
  • what other modules (either imported here or not imported) are exported. The exported modules are available to those that import this module.

NgModules consolidate declarables and services into cohesive blocks of functionality for a feature area. Angular libraries are NgModules, such as FormsModule, HttpClientModule, RouterModule, Material Design, Ionic and AngularFire2.

Every Angular app has at least one module, the root module that is bootstrapped to launch the application.

Be careful when you provide a service in a moddule because it will create a new instance of the service when the service is injected into the importing module.

2 Types of Modules

It is a little bit messy in Angular’s official document about types of modules and their usage. The following classification is different from the official one and is easier to understand and easier to use.

  • The Root module: it is the root AppModule that lauches the app. This module be as simple as possible. For exaple, it should only use one, not many, top-level feature module to organize the UI.
  • Feature module: feature modules handles UI features. It has two sub types.
    • eager-loading feature modules: these modules provide the UI features required in application start. Usually a feature module has a top component and many supporting sub-components. It declares and exports the top componnent but hides the sub-components. It is usually imported by the root module and other eager-loading modules. For simplicity, it is called eager-loading module or eager module.
    • routed feature module: these modules proide the UI features that are targets of navigation routes. They can be preloaded or lazy loaded. They don’t declare and export components because they are loaded by the router and are usd independently. They are also called as routed modules.
  • Routing module: a routing module provides routing configuration for a routed module and should have a matching name. For example, the root module AppModule has a routing module AppRoutingModule. A routed moudle FooModule should have a routing module FooRoutingModule. It defines routes, guards and resolver servcie providers. It should re-exports the RouterModule thus its corresponding routed mdoule can use route services. To configure routes, the AppModule calls RouterModule.forRoot(routes) and a feature module calls RouterModule.forChid(routes). A routing module should not have declarations.
  • Service module: a service module provides utility services such as data access. It should only has providers and have no declarations. The root AppModule is the only module that should import service modules. If a service is only used locally in a feature module, then it should be defined as a service class, not in a module, inside the feature module folder.
  • Widget module: a widget module defines shareable components, directives, and pipes for other feature modules. It should only have exported declarables and should not have providers.

The following table summarizes the module types.

Type Declarations Providers Exports Imported by
Root No No No None
Eager Yes Rare Top components Root, Feature
Routed Yes Rare No None
Routing No Yes (Guards) RouterModule Root, Feature
Service No Yes No Root
Widget Yes Rare Yes Feature

The “Rare” means that noramlly you should not provider definitions in that type.