Injecting services with an abstract class is a common practice in Angular library modules

Question

Injecting services with an abstract class is a common practice in Angular library modules

In my development workflow, I have established an Angular Component Library that I deploy using NPM (via Nexus) to various similar projects. This library includes a PageComponent, which contains a FooterComponent and a NavbarComponent. Within the NavbarComponent, there is a button that triggers a function called logout. To enable this functionality, the function must be provided through a PageService specific to each project. For this purpose, I introduced an AbstractPageService within the Angular Component Library (PageService extends AbstractPageService).

Initially, I addressed this requirement by using an EventEmitter. However, as it necessitated providing a separate logout function for every new page, I sought a more efficient solution employing a single service per project. I achieved this by passing the respective PageService (for each project) using the forRoot() method of the Angular Component Library.

Although everything functions as intended, I am curious to explore whether there might be a more optimal approach or if this current solution suffices?

Below is the implementation of this solution:

Components Lib - components.module.ts

// Inserted code for ComponentsModule

Component Lib - page.component.ts

// Inserted code for PageComponent

Component Lib - abstract-page.service.ts

// Inserted code for AbstractPageService

Utilization within a project is demonstrated below:

Project - app.module.ts

// Inserted code for AppModule

Project - page.service.ts

// Inserted code for PageService

angular typescript

Answer 1

Answer №1

After implementing this strategy, I encountered a common issue:

I noticed that the PageService was not behaving as expected in my application. Due to the fact that it is utilized in multiple modules (both in the application module and library module), each module generates a new instance of the service.

To work around this problem, I decided to provide my service using a string within the application module:

// app.module.ts located in the root directory of the application
providers: [
  {
    provide: 'PageService',
    useClass: PageService
  }
]

Then, whenever necessary, I injected the service by utilizing @Inject()

// anywhere within the root application where the service is required
constructor(@Inject('PageService') private pageService: PageService) {}

Subsequently, within the library, I established a basic interface:

export interface AbstractPageService {
  logout(): void;
}

This allowed me to easily inject the service in the library by employing the Inject() decorator and specifying its type using the interface (without having to implement the interface in the root application):

// anywhere in the library where the service is used
constructor(@Inject('PageService') private pageService: AbstractPageService) {}

As a result, both the main application and the library now share the same singleton instance of the PageService, thanks to the provision made in the root application.

Answer 2

After implementing this strategy, I encountered a common issue:

I noticed that the PageService was not behaving as expected in my application. Due to the fact that it is utilized in multiple modules (both in the application module and library module), each module generates a new instance of the service.

To work around this problem, I decided to provide my service using a string within the application module:

// app.module.ts located in the root directory of the application
providers: [
  {
    provide: 'PageService',
    useClass: PageService
  }
]

Then, whenever necessary, I injected the service by utilizing @Inject()

// anywhere within the root application where the service is required
constructor(@Inject('PageService') private pageService: PageService) {}

Subsequently, within the library, I established a basic interface:

export interface AbstractPageService {
  logout(): void;
}

This allowed me to easily inject the service in the library by employing the Inject() decorator and specifying its type using the interface (without having to implement the interface in the root application):

// anywhere in the library where the service is used
constructor(@Inject('PageService') private pageService: AbstractPageService) {}

As a result, both the main application and the library now share the same singleton instance of the PageService, thanks to the provision made in the root application.

Answer 3

Answer №2

To utilize a singleton pattern

Include in the main appModule.ts file

{ provide: 'currentCompanyService', useFactory: getCompanyServiceInstance, deps: [AppInitService]}

Create a factory function that simply returns the injected instance.

export function getCompanyServiceInstance(appInitService: AppInitService): AppInitService {
 return appInitService;
}

Use in a component of the library

public CustomLibraryComponent {

   private companyService: AppInitService;

   constructor(@Inject('currentEnvironment') environment: any,
               @Inject('currentCompanyService') companyService: AppInitService) {
       this.environment = environment;
       this.companyService = companyService;
   }
}

Answer 4

To utilize a singleton pattern

Include in the main appModule.ts file

{ provide: 'currentCompanyService', useFactory: getCompanyServiceInstance, deps: [AppInitService]}

Create a factory function that simply returns the injected instance.

export function getCompanyServiceInstance(appInitService: AppInitService): AppInitService {
 return appInitService;
}

Use in a component of the library

public CustomLibraryComponent {

   private companyService: AppInitService;

   constructor(@Inject('currentEnvironment') environment: any,
               @Inject('currentCompanyService') companyService: AppInitService) {
       this.environment = environment;
       this.companyService = companyService;
   }
}

Answer 5

Answer №3

According to Sunil Singh, the recommended approach is to use a standard abstract class as the solution, without the need for @Injectable.

export abstract class AbstractPageService {

  abstract logout(): void;

}

Answer 6

According to Sunil Singh, the recommended approach is to use a standard abstract class as the solution, without the need for @Injectable.

export abstract class AbstractPageService {

  abstract logout(): void;

}

Answer 7

Answer №4

It appears that 'useValue' should be used instead of 'useClass'.

export class ComponentsModule {
  static forRoot(pageService): ModuleWithProviders {
    return {
      ngModule: ComponentsModule,
      providers: [
        {provide: 'PageService', useValue: pageService}
      ]
    };
  }
}

Answer 8

It appears that 'useValue' should be used instead of 'useClass'.

export class ComponentsModule {
  static forRoot(pageService): ModuleWithProviders {
    return {
      ngModule: ComponentsModule,
      providers: [
        {provide: 'PageService', useValue: pageService}
      ]
    };
  }
}

Injecting services with an abstract class is a common practice in Angular library modules

Answer №1

Answer №2

Include in the main appModule.ts file

Use in a component of the library

Answer №3

Answer №4

Similar questions

Retrieve a list of class names associated with a Playwright element

retrieve asynchronous data from the server using ngrx

Revamping every Angular component

dynamic padding style based on number of elements in array

What causes the function endpoint to become unreachable when a throw is used?

What is the best way to transfer the API Response Time from one Fetch function to a separate asynchronous function?

Issue: The inject() function can only be executed within an injection context. Issue: An untruthy value was expected to be truth

How to incorporate a custom JavaScript file into an Angular 7 application

Encountering issues during the installation of JSNLog

Variable Scope is not defined in the TypeScript controller class of an AngularJS directive

The correct procedure for refreshing a page in Angular 8

Using Angular 2 to efficiently recycle a subcomponent with the same form across multiple parent components while maintaining its state

What is the best way to integrate ng-bootstrap into an nx mono repository?

Is it possible for Angular Components to be dynamically generated based on a parameter?

Alternating the main access point from a separate module

Error: Unexpected input detected in `ts.resolveTypeReferenceDirective`. This issue may lead to a debug failure

The index type 'X' is not allowed for use in this scenario

Angular 4 incorporates ES2017 features such as string.prototype.padStart to enhance functionality

Implementing Basic Authentication for HTTP Requests in Angular 7

The Error message "Property 'data' is not present in Type <void> | AxiosHttpResponse<any>" is indicating that the data property is missing on