Component modules – Organizing Your Application

The purpose of this module is to group directive components and pipes that will be reused by business domain components and even other components. Even using a component library such as Angular Material, your system will need custom components according to the business rules of your business domain.

This type of component has components, directives, and pipes declared in the declaration attribute and exported in the exports attribute, as shown in the following example:
import { NgModule } from ‘@angular/core’;
import { CommonModule } from ‘@angular/common’;
import { StatesSelectorComponent } from ‘./states-selector/states-selector.component’;
import { MatSelectModule } from ‘@angular/material/select’;
@NgModule({
 declarations: [StatesSelectorComponent],
 imports: [CommonModule, MatSelectModule],
 exports: [StatesSelectorComponent],
})
export class ComponentsModule {}

Separating the project into business domain modules and components will organize your code and improve its maintainability. Let’s analyze a common anti-pattern in Angular applications.

Avoiding anti-pattern – single module app

When we are starting to study and develop with Angular, it is very common not to pay much attention to the organization and use of the application modules. As we studied at the beginning of this chapter, NgModules are so fundamental to Angular that as soon as we start a project, the Angular CLI creates the first module for the project, AppModule.

In theory, only this module is necessary for your application to work. From there, we can declare all the components and directives, and import all the libraries that the project might need, as we can see in the following example:
import { NgModule } from ‘@angular/core’;
.
.
.
@NgModule({
 declarations: [
   AppComponent,
   StatesSelectorComponent,
   HomeComponent,
   SimulationComponent
 ],
 imports: [
   BrowserModule,AppRoutingModule,
   BrowserAnimationsModule,HttpClientModule,
   ReactiveFormsModule,LayoutModule,
   MatToolbarModule,MatButtonModule,
   MatSidenavModule,MatIconModule,
   MatListModule,
 ],
 bootstrap: [AppComponent]
})
export class AppModule { }

This approach has some problems and is an anti-pattern that we’ll call a single-module app.

The problems we have here are as follows:

• Disorganized folder structure: The team will soon not know which components belong to which area of the project. As the project grows, this file will get bigger and more confusing.
• Bundle size and build time: Angular has several build and bundle optimizations that depend on the definition of application modules. Staying in just one module, these optimizations are not very effective.
• Component maintainability and update issues: As this file grows, the team will have difficulties deprecating no longer used components or updating those components where the Angular CLI is unable to update automatically.

The solution to this anti-pattern is to apply what we learned in this chapter: separating modules into business domain (or feature) and component modules.

We can use NgModel to reduce the repetition of importing common components in the application, as we will see in the next section about the SharedModule pattern.