Saltar al contenido

Cómo poner en práctica los servicios y la inyección de dependencia en angular

Para los módulos de carga, Angular tiene dos estrategias muy diferentes:

  1. Módulos cargados con entusiasmo
  1. 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.

Cómo poner en práctica los servicios y la inyección de dependencia en angular
Cómo poner en práctica los servicios y la inyección de dependencia en angular

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.