@Injectable decorator and providedIn in Angular - Step-by-Step Execution

Concept Flow - @Injectable decorator and providedIn

Define Service Class

↓

Add @Injectable Decorator

↓

Set providedIn Property

↓

Angular Registers Service

↓

Service Available for Injection

↓

Component or Other Service Requests Injection

↓

Angular Provides Singleton Instance

This flow shows how adding @Injectable with providedIn makes Angular register the service and provide a singleton instance wherever injected.

Execution Sample

Angular

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

@Injectable({ providedIn: 'root' })
export class MyService {
  value = 42;
}

Defines a service class with @Injectable and providedIn root, making it available app-wide as a singleton.

Execution Table

Step	Action	Evaluation	Result
1	Angular reads MyService class	Sees @Injectable decorator	Marks class as injectable
2	Reads providedIn: 'root'	Determines service scope	Registers service in root injector
3	Component requests MyService injection	Checks root injector	Provides singleton instance
4	Component uses service.value	Reads value property	Gets 42
5	Another component requests MyService	Checks root injector	Gets same singleton instance
6	Application runs	Service instance reused	No new instances created
7	Execution ends	No more injections	Service lifecycle managed by Angular

💡 Service registered once in root injector; all injections share the same instance.

Variable Tracker

Variable	Start	After Step 3	After Step 5	Final
MyService instance	undefined	Created singleton instance	Same singleton instance reused	Same singleton instance reused

Key Moments - 3 Insights

Why does Angular create only one instance of the service?

Because providedIn: 'root' registers the service in the root injector, making Angular provide the same singleton instance to all injections, as shown in execution_table steps 3 and 5.

What happens if we omit providedIn in @Injectable?

Angular won't automatically register the service; you must provide it manually in a module or component providers array. This is why step 2 in execution_table is crucial for automatic registration.

Can providedIn have values other than 'root'?

Yes, it can be 'platform', 'any', or a specific module. This changes the injector scope and instance sharing, but 'root' is the most common for app-wide singleton, as shown in the flow.

Visual Quiz - 3 Questions

Look at the execution table, what happens at step 3 when a component requests MyService?

A Angular provides the singleton instance from root injector

B Angular creates a new instance every time

C Angular throws an error because service is not registered

D Angular provides a different instance per component

💡 Hint

Check execution_table row 3 where Angular provides the singleton instance.

At which step does Angular register the service in the root injector?

A Step 1

B Step 2

C Step 4

D Step 6

💡 Hint

Look at execution_table row 2 where providedIn: 'root' is processed.

If providedIn is removed from @Injectable, what changes in the execution?

A Service is still registered automatically in root injector

B Angular registers service in platform injector instead

C Service is not registered automatically and injection fails unless manually provided

D Service becomes a transient instance created on each injection

💡 Hint

Refer to key_moments explanation about missing providedIn and manual registration.

Concept Snapshot

@Injectable decorator marks a class as injectable.
providedIn defines where Angular registers the service.
providedIn: 'root' means app-wide singleton.
Angular creates one instance per injector scope.
Without providedIn, manual provider registration is needed.

Full Transcript

The @Injectable decorator in Angular marks a class as a service that can be injected. The providedIn property inside @Injectable tells Angular where to register this service. When providedIn is set to 'root', Angular registers the service in the root injector, making it a singleton available throughout the app. When a component or another service asks for this service, Angular provides the same instance every time. If providedIn is omitted, Angular does not register the service automatically, so you must add it manually to a module or component providers. This flow ensures efficient reuse and easy dependency management.