Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Angular: Lazy loading modules with services

I've been following this tutorial, to understand lazy loading, and below is my inference.

Scenario 1: Services are provided by putting them in the providers array of a child module

Scenario 2: Services are provided in a child module using the forRoot approach

With scenario 1 in context,

  • If a child module is eagerly loaded, an instance of the service is added to the root injector.
  • If a child module is lazily loaded, an instance of the service is added to the root injector and a new instance of the service is added to the child injector, which is not the usual use case.

With scenario 2 in context,

  • If a child module is eagerly loaded, an instance of the service is added to the root injector.

  • If a child module is lazily loaded, the same instance of the service is available in both the root and the child module, which is the usual use case.

They have mentioned the following.

At the beginning,

So, even when using modules, there's no way to have a "private" service unless... the module is being lazy loaded.

Finally,

Although this syntax is a little more convoluted than the original, it will guarantee us that only one instance of the CreditCardService is added to the root module. When the CreditCardModule is loaded (even lazy loaded), no new instance of that service is going to be added to the child injector.

If the instance is going to be available in the root injector as well, how do they say that the service is 'privitized'?

I'm confused. Someone please clarify.

like image 323
karthikaruna Avatar asked Jan 10 '18 11:01

karthikaruna


3 Answers

providedIn: 'root' is the easiest and most efficient way to provide services since Angular 6:

  1. The service will be available application wide as a singleton with no need to add it to a module's providers array (like Angular <= 5).
  2. If the service is only used within a lazy loaded module it will be lazy loaded with that module
  3. If it is never used it will not be contained in the build (tree shaked).

For further informations consider reading the documentation and NgModule FAQs

Btw:

  1. If you don't want an application-wide singleton, use the provider's array of a component instead.
  2. If you want to limit the scope so no other developer will ever use your service outside of a particular module, use the provider's array of NgModule instead.*

*UPDATE

'use the provider's array of NgModule instead' means to use the providers array of the lazy loaded module, eg:

import { NgModule } from '@angular/core';

import { UserService } from './user.service';

@NgModule({
  providers: [UserService],
})
export class UserModule {
}

OR to actually name the module in the injectable decorator:

import { Injectable } from '@angular/core';
import { UserModule } from './user.module';

@Injectable({
  providedIn: UserModule,
})
export class UserService {
}

Quote from the docs:

When the router creates a component within the lazy-loaded context, Angular prefers service instances created from these providers to the service instances of the application root injector.

Doc ref: https://angular.io/guide/providers#providedin-and-ngmodules

like image 185
Mick Avatar answered Oct 23 '22 15:10

Mick


This thread is pretty old but I'll answer what I learned while searching on this topic for the future stumblers on this thread.

The concept of privatizing a service with lazy loading is proper and for the below reasons:

  • When a module is lazily loaded it creates its own Injector context, which is the child of the root injector(it's parent injector to be precise). The services in them won't be pushed to the root injector as they were not instantiated when the root injector was being configured.
  • Angular Doc says that one of the ways to scope your service is to provide them to its own module(suppose Module-A). And only when any other module B imports module A, then it will have the provider of that service(from module A) and thus can access it. This actually works for lazy modules and not for eager modules for below reasons:

  • When you do implement the above scoping method for eager modules, it will create a provider for the services of that module(suppose module A). But when that particular module 'A' is imported into the root module(as all eager modules should be), the root injector will create a single instance of that service and would discard any duplicate instance of that service in the root injector's scope(if module A was imported in any other eager module). Thus all eager modules have access to a singleton service of any module which was imported in the root module.

  • Again at application load the root injector and module won't know about the lazy module and its services. Thus the lazy services are privatized in their own module. Now for the root module to have access to the lazy service, it needs to follow the angular way of importing the module. Which is basically importing the "supposed to be lazily loaded" module into the root module at application load time, and thus defeating the purpose of lazy loading.
  • If you still want to have access to the lazy service from the root injector. You can use the:

    @Injectable({ 
        providedIn: 'root'
    })
    

decorator in the lazy service and inject it in the root injector without loading the lazy module at application load.

The example you were following is not a true implementation of lazy loading if you have access to the lazy services in your root module, without the providedIn: root object. You can go through this link: https://angular.io/guide/providers#limiting-provider-scope-by-lazy-loading-modules

like image 25
Danish Aziz Avatar answered Oct 23 '22 15:10

Danish Aziz


Here is the way I do it: https://stackblitz.com/edit/angular-lazy-service-module?file=src%2Fapp%2Fapp.component.ts

This is a proof of concept. You need to watch out what injector you use (in case the lazy service need some dependencies) and how you manage the life-cycle of the lazy loaded service (how many instances you create, etc.).

My use case is that there is a pretty big service (export to excel, over 400 KB gziped) that is used in multiple areas of the application but I don't want to load/parse it until it's actually needed - faster initial load! (I actually also used a delay preload strategy that loads the modules after a few seconds).

The basic idea is that you define it as a lazy module in a route (that you don't actually use) but you trigger the load manually. You also resolve the service from that module (once you have it) by using an injection token.

lazy module

import { NgModule } from '@angular/core';

import { LazyService } from './lazy-service.service';
import { LAZY_SERVICE_TOKEN } from './lazy-service.contract';

@NgModule({
  providers: [{ provide: LAZY_SERVICE_TOKEN, useClass: LazyService }],
})
export class LazyServiceModule {
}

lazy service

import { Injectable } from '@angular/core';
import { LazyService as LazyServiceInterface } from './lazy-service.contract';

@Injectable()
export class LazyService implements LazyServiceInterface {
  process(msg: string) {
    return `This message is from the lazy service: ${msg}`;
  }
}

app module

@NgModule({
  imports: [BrowserModule,
    RouterModule.forRoot([
      // whatever other routes you have
      {
        path: '?$lazy-service', //some name that will not be used
        loadChildren: 'app/lazy-service/lazy-service.module#LazyServiceModule',
      },
    ])],
  declarations: [AppComponent],
  bootstrap: [AppComponent]
})
export class AppModule { }

using it inside a component

constructor(
  private loader: NgModuleFactoryLoader,
  private injector: Injector,
) {
}

async loadServiceAndCall() {
  const factory = await this.loader.load('app/lazy-service/lazy-service.module#LazyServiceModule');
  const moduleRef = factory.create(this.injector);
  const service: LazyService = moduleRef.injector.get(LAZY_SERVICE_TOKEN);
  this.value = service.process('"from app.component.ts"')
}
like image 4
Andrei Tătar Avatar answered Oct 23 '22 15:10

Andrei Tătar