si usa provideIn, el inyectable se registra como proveedor del Módulo sin agregarlo a los proveedores del módulo.

De Docs

El servicio en sí es una clase que generó la CLI y está decorada con @Injectable. De forma predeterminada, este decorador está configurado con una propiedad provideIn, que crea un proveedor para el servicio. En este caso, provideIn: 'root' especifica que el servicio debe proporcionarse en el inyector raíz.

provideIn le dice a Angular que el inyector raíz es responsable de crear una instancia de su Servicio. Los servicios que se brindan de esta manera están automáticamente disponibles para toda la aplicación y no es necesario que se incluyan en ningún módulo.

Las clases de servicio pueden actuar como sus propios proveedores, por lo que definirlas en el decorador @Injectable es todo el registro que necesita.

Según la Documentation :

Registrar el proveedor en los metadatos @Injectable() también permite que Angular optimice una aplicación eliminando el servicio de la aplicación compilada si no se usa.

providedIn: 'root' es la forma más fácil y eficiente de proporcionar servicios desde Angular 6:

1. El servicio estará disponible en toda la aplicación como un singleton sin necesidad de agregarlo a la matriz de proveedores de un módulo (como Angular <= 5).
2. Si el servicio solo se usa dentro de un módulo de carga diferida, se cargará de forma diferida con ese módulo
3. Si nunca se usa, no estará contenido en la construcción (árbol sacudido).

Para obtener más información, considere leer la documentación y las preguntas frecuentes de NgModule

Por cierto:

1. Si no desea un singleton para toda la aplicación, use la matriz de un componente del proveedor en su lugar.
2. Si desea limitar el alcance para que ningún otro desarrollador use su servicio fuera de un módulo en particular, use la matriz de providers de NgModule en su lugar.

De Documentos

¿Qué es el decorador inyectable?

Marca una clase como disponible para Injector para su creación.

 import { Injectable } from '@angular/core'; @Injectable({ providedIn: 'root', }) export class UserService { }

El servicio en sí es una clase que generó la CLI y está decorada con @Injectable().

¿Qué hace exactamente provideIn?

Determina qué inyectores proporcionarán el inyectable, ya sea asociándolo con un @NgModule u otro InjectorType, o especificando que este inyectable debe proporcionarse en el inyector 'raíz', que será el inyector de nivel de aplicación en la mayoría de las aplicaciones.

 providedIn: Type<any> | 'root' | null

proporcionado en: 'raíz'

Cuando proporciona el servicio en el nivel raíz, Angular crea una única instancia de servicio compartida y la inyecta en cualquier clase que lo solicite. Registrar el proveedor en los metadatos @Injectable() también permite que Angular optimice una aplicación eliminando el servicio de la aplicación compilada si no se usa.

proporcionado en: módulo

También es posible especificar que un servicio debe proporcionarse en un @NgModule en particular. Por ejemplo, si no desea que un servicio esté disponible para las aplicaciones a menos que importen un módulo que haya creado, puede especificar que el servicio debe proporcionarse en el módulo

 import { Injectable } from '@angular/core'; import { UserModule } from './user.module'; @Injectable({ providedIn: UserModule, }) export class UserService { }

Se prefiere este método porque permite la sacudida de árboles (la sacudida de árboles es un paso en un proceso de compilación que elimina el código no utilizado de una base de código) del servicio si nada lo inyecta.

Si no es posible especificar en el servicio qué módulo debe proporcionarlo, también puede declarar un proveedor para el servicio dentro del módulo:

 import { NgModule } from '@angular/core'; import { UserService } from './user.service'; @NgModule({ providers: [UserService], }) export class UserModule { }

ver Excelente explicación de @Nipuna ,

Me gustaría extenderlo agregando ejemplos.

si solo usa el decorador inyectable sin la propiedad providedin , como,

 @Injectable()

entonces tendría que escribir el nombre del servicio en la matriz de providers del módulo respectivo.

Me gusta esto;

servicio.de.datos.ts ↴

 import { Injectable } from '@angular/core'; @Injectable() export class DataService { constructor() {} // Code . . . }

aplicación.módulo.ts ↴

 import { AppComponent } from './app.component'; import { DataService } from './core/data.service'; @NgModule({ declarations: [AppComponent], providers: [DataService], // ⟵ LOOK HERE WE PROVIDED IT imports: [...], bootstrap: [AppComponent], }) export class AppModule {}

Pero, si usa providedIn: 'root' , así:

servicio.de.datos.ts ↴

 import { Injectable } from '@angular/core'; @Injectable({ providedIn: 'root', }) export class DataService { constructor() {} // Code . . . }

Entonces nuestro módulo se vería así:

aplicación.módulo.ts ↴

 import { AppComponent } from './app.component'; import { DataService } from './core/data.service'; @NgModule({ declarations: [AppComponent], providers: [], imports: [...], bootstrap: [AppComponent], }) export class AppModule {}

vea que no DataService en la matriz de providers esta vez, porque no es necesario.

Buenas practicas

Esto podría ser útil, de Angular Guides

Proporcione un servicio con el inyector raíz de la aplicación en el decorador @Injectable del servicio.

¿Por qué? El inyector Angular es jerárquico.

¿Por qué? Cuando proporciona el servicio a un inyector raíz, esa instancia del servicio se comparte y está disponible en cada clase que necesita el servicio. Esto es ideal cuando un servicio comparte métodos o estado.

¿Por qué? Cuando registra un servicio en el decorador @Injectable del servicio, las herramientas de optimización, como las que usan las compilaciones de producción de Angular CLI, pueden realizar sacudidas de árbol y eliminar servicios que no usa su aplicación.

¿Por qué? Esto no es ideal cuando dos componentes diferentes necesitan diferentes instancias de un servicio. En este escenario, sería mejor brindar el servicio en el nivel de componente que necesita la instancia nueva y separada.