Angular modules

In AngularJS, we have the concept of modules. Modules there are responsible for grouping pieces of related functionality together and registering it internally during the bootstrap process. Unfortunately, they didn't provide features such as encapsulation and lazy loading.

Angular introduced the NgModules as part of the fifth release candidate of the framework. The main purpose of the new modules is to give a context for the Angular compiler and achieve a good level of encapsulation. For instance, if we are building a library with NgModules, we can have a number of declarations, which are used internally but not exported as part of the public interface. Let's take a look at the following example:

import {NgModule} from '@angular/core';
import {CommonModule} from '@angular/common';
import {TabComponent} from './tab.component';
import {TabItemComponent} from './tab-item.component';

@NgModule({
  imports: [CommonModule],
  declarations: [TabComponent, TabItemComponent],
  exports: [TabComponent]
})
class TabModule { }

Do not worry if you're not familiar with the TypeScript syntax in the preceding example; we will take a deep dive into the language in the next chapter.

In the preceding code snippet, using the @NgModule decorator, we declare TabModule. Note that in the list of declarations, we include both TabComponent and TabItemComponent, but in the list of exports, we have only TabComponent. This way, we can achieve a level of encapsulation for our library. The users of the module will be able to use only TabComponent, so we don't have to worry about backward compatibility of the API of TabItemComponent since it's accessible only internally, within the boundaries of our module. Finally, by setting the imports property of the object literal passed to @NgModule, we can list modules that we want to use inside of the current module. This way, we will be able to take advantage of all the exports and providers (we'll discuss providers in Chapter 6, Dependency Injection in Angular) declared by them.