Para los módulos de carga, Angular tiene dos estrategias muy diferentes:
- Módulos cargados con entusiasmo
- Módulos de carga perezosa
Los módulos cargados con entusiasmo se importan en el AppModule raíz. Su paquete se descarga inicialmente junto con el AppModule y, por lo tanto, no es una estrategia óptima, aunque, para aplicaciones más pequeñas esto no debería ser un problema.los módulos cargados con pereza, por otra parte, se cargan siempre que se solicitan, por ejemplo, si tenemos un módulo llamado ShoppingModule, podemos controlar la forma en que se empaqueta convirtiéndolo en un módulo cargado con pereza. De esta manera, sólo cuando el usuario visita la página de Compras se descarga ese módulo, lo que reduce mucho el tamaño inicial del paquete. Esto puede ser realmente útil para aplicaciones más grandes que pueden tener muchos módulos diferentes y, si sabemos que el usuario no necesariamente visita ciertas áreas de nuestra aplicación, podemos convertirlas en módulos de carga lenta.

Ahora, veamos cómo la estrategia de carga de módulos tiene un impacto en términos de servicios.
Veremos diferentes ejemplos de prestación de servicios en un módulo cargado con entusiasmo vs. un módulo cargado con pereza y veremos los diferentes comportamientos.
La configuración básica es la misma; tenemos un CoreModule que es un módulo cargado con entusiasmo, mientras que el ShoppingListModule es cargado con pereza.
Echemos un vistazo a nuestro código de servicio de registro.
12345678exportclassLoggingService{ lastLog: string,printMessage(msg: string){console.log("El mensaje actual es "+ msg);console.log("El último mensaje registrado es "+this.lastLog);this.lastLog= msg;}}
javascript
Digamos que queremos consumir este servicio en AppComponent y ShoppingListComponent, mientras que el servicio se proporciona usando @Injectable en el logging.service.
12345678910111213import{Injectable}de$0027@angular/core$0027;@Injectable({ providedIn:$0027root$0027,})exportclassLoggingService{ lastLog: string,printMessage(msg: string){console.log("El mensaje actual es : "+ msg);console.log("El último mensaje registrado es : "+this.lastLog);this.lastLog= msg;}}
javascript
12345678910111213141516import{Componente,OnInit,OnDestroy}de$0027@angular/core$0027;import{LoggingService}from$0027./logging.service.ts$0027;@Componente({ selector:$0027app-root$0027, templateUrl:$0027./app. component.html$0027})exportclassAppComponentimentsOnInit,OnDestroy{constructor(private loggingService:LoggingService){}ngonInit(){this.loggingService.printMessage("Hello from AppComponent !")}}
javascript
12345678910111213141516import{Componente,OnInit,OnDestroy}de$0027@angular/core$0027;import{LoggingService}from$0027./logging.service.ts$0027;@Componente({ selector:$0027shopping-list$0027, templateUrl:$0027./shopping-list. component.html$0027})exportclassShoppingListComponentimentsOnInit,OnDestroy{constructor(private loggingService:LoggingService){}ngonInit(){this.loggingService.printMessage("Hello from ShoppingListComponent !")}}
javascript
Con la configuración anterior, digamos que el usuario está en la página de inicio inicialmente y luego navega a la página de compras. Con eso, vemos la siguiente salida que se registra en la consola:
Dado que, desde el ShoppingListComponent, podemos ver que el mensaje anterior se ha registrado correctamente, eso demuestra que estamos usando la misma instancia de LoggingService tanto en el AppComponent como en el ShoppingListComponent
Si quitamos el @Injectable del LoggingService y en su lugar proporcionamos el servicio en el AppModule, quedaría como sigue:
12345678910111213141516171819202122importar{Módulo de Navegador}de$0027@angular/plataforma-navegador$0027;importar{NgMódulo}de$0027@angular/núcleo$0027;importar{Módulo de Formas,Módulo de Formas Reactivas}de$0027@angular/formas$0027;importar{Componente de Aplicación}de$0027./app. component$0027;import{LoggingService}from$0027./logging.service$0027;@NgModule({ declaraciones:[AppComponent], importa:[BrowserModule,FormsModule,ReactiveFormsModule], proveedores:[LoggingService], bootstrap:[AppComponent]})exportclassAppModule{}
javascript
Incluso en el caso anterior, la salida de nuestra consola se mostraría como abajo:
Ahora, eliminaremos el servicio proporcionado en AppModule y, en su lugar, proporcionaremos el LoggingService en un módulo cargado con impaciencia (CoreModule), como se indica a continuación:
1234567891011importar{NgModule}de$0027@angular/core$0027;importar{LoggingService}de$0027./logging.service$0027;...@NgModule({importa:[BrowserModule], declaraciones:[AppComponent], bootstrap:[AppComponent], proveedores:[LoggingService]})exportclassCoreModule{}
javascript
Lo que observamos es que incluso cuando el servicio se presta en el módulo cargado con entusiasmo, nuestra producción sigue siendo la misma que la de abajo:
Esto se debe a que, si un módulo se carga con impaciencia, todo se agrupa inicialmente. Por lo tanto, cualquier servicio que agreguemos a los «proveedores» en un módulo cargado con impaciencia estará disponible en toda la aplicación con la misma instancia del servicio.
Por último, eliminemos el LoggingService de los proveedores del CoreModule y en su lugar lo añadiremos a los proveedores del AppModule y también a los proveedores del ShoppingListModule de carga lenta como se indica a continuación;
1234567891011importar{NgModule}de$0027@angular/core$0027;importar{LoggingService}de$0027./logging.service$0027;...@NgModule({importa:[BrowserModule], declaraciones:[AppComponent], bootstrap:[AppComponent], proveedores:[LoggingService]})exportclassShoppingListModule{}
javascript
Aquí está la parte interesante. Esta vez, la salida de la consola será ligeramente diferente, como se muestra a continuación:
Cuando navegamos por la página de compras después de visitar la página de inicio, vemos que el último mensaje registrado es «indefinido». Esto se debe a que, si el servicio se proporciona tanto en AppModule como en cualquier módulo de carga lenta, el servicio estaría disponible en toda la aplicación, pero el módulo de carga lenta obtendrá su propia instancia del servicio.