Is it recommended to include modules in the Imports section of SharedModule in Angular?

Question

Is it recommended to include modules in the Imports section of SharedModule in Angular?

Welcome to my SharedModule!

import { CommonModule } from "@angular/common";
import { NgModule } from "@angular/core";
import { FormsModule, ReactiveFormsModule } from "@angular/forms";
import { IconModule } from "@my-app/components/icon/icon.module";
import { RequiredActionDirective } from "@my-app/directives/required-action.directive";

@NgModule({
    imports: [
        CommonModule,
        IconModule
    ],
    declarations: [
        RequiredActionDirective
    ],
    exports: [
        CommonModule,
        IconModule,
        FormsModule,
        ReactiveFormsModule,
        RequiredActionDirective
    ]
})
export class SharedModule { }

I made the decision to include only CommonModule and IconModule in the Imports section because they are directly used in the RequiredActionDirective. However, I included more modules in the Exports section as they may be needed by other modules importing SharedModule.

It raises the question: is it correct that I do not have to add Modules to Imports unless directly using them in SharedModule? Could there potentially be unforeseen issues in the future despite everything working smoothly now?

angular typescript angular-module shared-module

Answer 1

Answer №1

It is important to be mindful when re-exporting modules and only import the necessary modules that the current module relies on. While importing poses no harm, exporting can create a division in the dependency tree for providers.

If a module re-exports another one, the parent module that imports it will not be able to override that import. This could potentially lead to issues in certain scenarios.

For instance;

@NgModule({
     imports: [HttpClientModule],
     provide: { provide: HTTP_INTERCEPTORS, useClass: ExampleInterceptor, multi: true },
     exports: [HttpClientModule]
})
export class SharedModule {}

In this case, AppModule will not be able to provide a different interceptor.

NgModule({
     imports: [SharedModule],
     provide: { provide: HTTP_INTERCEPTORS, useClass: AppInterceptor, multi: true }
     // ^^ interceptor is ignored
})
export class AppModule {}

The issue arises because the HttpClientModule is declared at the SharedModule level in the provider tree, which resolves all HTTP_INTERCEPTORS from that point onwards.

To address this, AppModule should import the HttpClientModule first, followed by the SharedModule.

NgModule({
     imports: [HttpClientModule, SharedModule],
     provide: { provide: HTTP_INTERCEPTORS, useClass: AppInterceptor, multi: true }
})
export class AppModule {}

By doing this, the HttpClientModule is now declared at the AppModule level, resolving all providers downwards, including those from the SharedModule. The sequence within the imports: [] array does not matter.

Answer 2

It is important to be mindful when re-exporting modules and only import the necessary modules that the current module relies on. While importing poses no harm, exporting can create a division in the dependency tree for providers.

If a module re-exports another one, the parent module that imports it will not be able to override that import. This could potentially lead to issues in certain scenarios.

For instance;

@NgModule({
     imports: [HttpClientModule],
     provide: { provide: HTTP_INTERCEPTORS, useClass: ExampleInterceptor, multi: true },
     exports: [HttpClientModule]
})
export class SharedModule {}

In this case, AppModule will not be able to provide a different interceptor.

NgModule({
     imports: [SharedModule],
     provide: { provide: HTTP_INTERCEPTORS, useClass: AppInterceptor, multi: true }
     // ^^ interceptor is ignored
})
export class AppModule {}

The issue arises because the HttpClientModule is declared at the SharedModule level in the provider tree, which resolves all HTTP_INTERCEPTORS from that point onwards.

To address this, AppModule should import the HttpClientModule first, followed by the SharedModule.

NgModule({
     imports: [HttpClientModule, SharedModule],
     provide: { provide: HTTP_INTERCEPTORS, useClass: AppInterceptor, multi: true }
})
export class AppModule {}

By doing this, the HttpClientModule is now declared at the AppModule level, resolving all providers downwards, including those from the SharedModule. The sequence within the imports: [] array does not matter.

Answer 3

Answer №2

An NgModule has the ability to export a mix of its own declarations, specific imported classes, and NgModules that have been brought in.

It is unnecessary to re-export pure service modules as they do not contain declarable classes that can be utilized by another NgModule. For instance, there is no benefit in re-exporting HttpClientModule since it does not export any items. Its main purpose is to simply incorporate http service providers into the entire application.

Answer 4

An NgModule has the ability to export a mix of its own declarations, specific imported classes, and NgModules that have been brought in.

It is unnecessary to re-export pure service modules as they do not contain declarable classes that can be utilized by another NgModule. For instance, there is no benefit in re-exporting HttpClientModule since it does not export any items. Its main purpose is to simply incorporate http service providers into the entire application.

Answer 5

Answer №3

Absolutely! It is possible to eliminate CommonModule from the imports in SharedModule. However, it's best to exercise caution as certain components may require it now or in the future.

Additionally, regarding CommonModule: Keep in mind that CommonModule gets automatically included in imports when generating a new module through CLI. While it can be safely removed since we already export it in SharedModule, it might come in handy for streamlining imports. Ultimately, the decision rests with you.

Answer 6

Absolutely! It is possible to eliminate CommonModule from the imports in SharedModule. However, it's best to exercise caution as certain components may require it now or in the future.

Additionally, regarding CommonModule: Keep in mind that CommonModule gets automatically included in imports when generating a new module through CLI. While it can be safely removed since we already export it in SharedModule, it might come in handy for streamlining imports. Ultimately, the decision rests with you.

Is it recommended to include modules in the Imports section of SharedModule in Angular?

Answer №1

Answer №2

Answer №3

Similar questions

The separator falls short of spanning the entire width of the page

The method Observable.combineLatest is not implemented

What are the drawbacks of combining exports through re-exporting in TypeScript?

Tips for continuously running a loop function until retrieving a value from an API within a cypress project

Svelte language switcher experiencing technical difficulties

Error encountered in Angular 6 Application running on .Net Core within a Docker Container due to Npm issue

Guide to linking properties to Bootstrap 5 components within Angular

What is the procedure for resetting the pagination tool?

Having trouble connecting to the API due to the error "No Access-Control-Allow-Origin" in Angular 2

Misunderstanding between Typescript and ElasticSearch Node Client

Using React, PIXI, and Zustand can sometimes lead to stale state issues when handling mouse events

TypeORM: Create case-insensitive search functionality

How to securely retrieve a document by integrating Angular 2 with a web API

Tips for packaging a Node TypeScript/JavaScript library using Webpack

Unable to transfer variable from a function to the test in Protractor

Injecting pipes into directives in Angular: A guide

Avoiding Maximum Call Stack Size Exceeded in Observables: Tips and Tricks

Ensure the JSON file aligns with the TypeScript Interface

Angular 7 error: Form control with name property does not have a valid value accessor

The imported variables are of a union type