Service scope (root, module, component) in Angular - Step-by-Step Execution

Concept Flow - Service scope (root, module, component)

App starts

↓

Inject Service

↓

Check Service Scope

When Angular injects a service, it checks where the service is provided: root, module, or component. This decides if the service is shared app-wide, shared in a module, or unique per component.

Execution Sample

Angular

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

@Injectable({ providedIn: 'root' })
export class DataService {
  count = 0;
}

Defines a service provided at root scope, so Angular creates one shared instance for the whole app.

Execution Table

Step	Action	Service Scope Checked	Instance Created?	Instance Shared?	Notes
1	App starts and component A requests DataService	root	Yes	Yes (singleton)	Service instance created at root level
2	Component B requests DataService	root	No	Yes (shared)	Same instance reused for component B
3	Module X requests DataService provided in module	module	Yes	Yes (module singleton)	New instance created for module X
4	Component C inside Module X requests DataService	module	No	Yes (shared in module)	Module instance reused
5	Component D requests DataService provided in component	component	Yes	No (unique)	New instance created for component D
6	Component E requests DataService provided in component	component	Yes	No (unique)	New instance created for component E
7	App ends	-	-	-	No new instances created

💡 Execution stops after all components and modules have requested the service and instances are created or reused based on scope.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	Final
DataService Instances	0	1 (root instance)	1 (root instance)	2 (root + module)	2 (root + module)	3 (root + module + comp D)	4 (root + module + comp D + comp E)	4 (final count)

Key Moments - 3 Insights

Why does requesting the service in component scope create multiple instances?

Because each component that provides the service gets its own instance, as shown in steps 5 and 6 where new instances are created for each component.

Why is the service instance shared between components when provided in root scope?

Because root scope creates a singleton instance shared app-wide, as seen in steps 1 and 2 where the same instance is reused.

What happens when a service is provided in a module?

A new singleton instance is created per module, shared by components inside that module, as shown in steps 3 and 4.

Visual Quiz - 3 Questions

Look at the execution table, how many DataService instances exist after step 4?

A 3

B 2

C 1

D 4

💡 Hint

Check the 'Instance Created?' and 'Instance Shared?' columns for steps 1 to 4.

At which step does a new instance get created for each component?

A Step 5

B Step 3

C Step 2

D Step 1

💡 Hint

Look for 'component' scope and 'Instance Created?' marked 'Yes' in the table.

If the service was only provided in root, what would happen at step 3?

A A new instance would be created for the module

B Multiple instances would be created for each component

C No new instance would be created; root instance reused

D The app would crash

💡 Hint

Refer to how root scope shares one instance app-wide in steps 1 and 2.

Concept Snapshot

Service scope in Angular decides how many instances of a service exist:
- providedIn: 'root' creates one singleton for the whole app
- providedIn: module creates one singleton per module
- providedIn: component creates a new instance per component
This affects sharing and state across components.

Full Transcript

When Angular starts, it creates service instances based on where the service is provided. If provided in root, one instance is shared by all components. If provided in a module, one instance is shared by components in that module only. If provided in a component, each component gets its own instance. This means state in the service can be shared or isolated depending on scope. The execution table shows steps where components request the service and whether a new instance is created or reused. Variable tracking shows how many instances exist over time. Key moments clarify why component scope creates multiple instances and root scope shares one. The quiz tests understanding of instance counts and scope effects.

Practice

1. What does setting a service's providedIn property to 'root' mean in Angular?

easy

A. The service is a singleton shared across the entire application.

B. The service is created separately for each module.

C. The service is only available inside a specific component.

D. The service is not injectable anywhere.

Solution

1. Step 1: Understand providedIn: 'root' meaning

   This setting makes Angular create one instance of the service for the whole app.

2. Step 2: Compare with other scopes

   Unlike module or component scopes, 'root' shares the same instance everywhere.

3. Final Answer:

   The service is a singleton shared across the entire application. -> Option A

4. Quick Check:

   Service scope 'root' = singleton app-wide [OK]

Hint: Root scope means one service instance for whole app [OK]

Common Mistakes:

• Thinking 'root' creates multiple instances
• Confusing 'root' with component scope
• Assuming 'root' limits service to one module

2. Which of the following is the correct syntax to provide a service only in a specific Angular module?

easy

A. Add the service to the module's providers array

B. @Injectable({ providedIn: 'module' })

C. @Injectable({ providedIn: 'root' })

D. Add the service to the component's providers array

Solution

1. Step 1: Recall how to scope service to a module

   Angular does not support providedIn: 'module'. Instead, you add the service to the module's providers array.

2. Step 2: Check other options

   @Injectable({ providedIn: 'root' }) scopes service app-wide, Add the service to the component's providers array scopes to component, @Injectable({ providedIn: 'module' }) is invalid syntax.

3. Final Answer:

   Add the service to the module's providers array -> Option A

4. Quick Check:

   Module scope = add to module providers [OK]

Hint: Module scope means add service to module providers array [OK]

Common Mistakes:

• Using 'providedIn: module' which is invalid
• Confusing component providers with module providers
• Assuming 'root' scopes service to module only

3. Given this Angular component code:

@Component({
  selector: 'app-example',
  template: `
{{counter}}
`,
  providers: [CounterService]
})
export class ExampleComponent {
  counter = 0;
  constructor(private counterService: CounterService) {
    this.counter = this.counterService.increment();
  }
}

If two instances of app-example are rendered, what will be the value of counter in each?

medium

A. Both will show 0 because service is not provided.

B. Both will show the same incremented value shared globally.

C. Both will show 1 because each has its own service instance.

D. Both will show an error because service is missing.

Solution

1. Step 1: Understand component-level service scope

   Providing CounterService in providers inside the component creates a new instance per component.

2. Step 2: Analyze two component instances

   Each component instance gets its own service instance, so each counter starts fresh and increments once to 1.

3. Final Answer:

   Both will show 1 because each has its own service instance. -> Option C

4. Quick Check:

   Component scope = separate service instances per component [OK]

Hint: Component providers create separate service instances per component [OK]

Common Mistakes:

• Assuming service is shared globally despite component providers
• Thinking service is not provided at all
• Confusing component scope with root scope

4. You have a service provided in a feature module's providers array. However, when injecting it in a lazy-loaded module, Angular throws an error that the service is not found. What is the likely cause?

medium

A. The service is provided in the root injector, causing conflicts.

B. The lazy-loaded module has its own injector and does not see the feature module's providers.

C. The service is declared but not exported from the module.

D. The service class is missing the @Injectable decorator.

Solution

1. Step 1: Understand lazy-loaded module injectors

   Lazy-loaded modules have their own injectors and do not inherit providers from eagerly loaded modules.

2. Step 2: Identify provider visibility issue

   Since the service is provided in a feature module not loaded by the lazy module, the lazy module injector can't find it.

3. Final Answer:

   The lazy-loaded module has its own injector and does not see the feature module's providers. -> Option B

4. Quick Check:

   Lazy modules have separate injectors = missing providers [OK]

Hint: Lazy modules have isolated injectors; providers must be re-declared [OK]

Common Mistakes:

• Assuming root injector shares providers with lazy modules
• Forgetting to add @Injectable decorator
• Confusing export with provider visibility

5. You want to create a logging service that keeps a separate log for each component instance but also shares some global settings. Which service scope setup is best?

hard

A. Provide the service in root and use a static variable for logs.

B. Provide the service in root and use internal state to separate logs per component.

C. Provide the service only in a feature module's providers array.

D. Provide the service in each component's providers array and inject a global settings service from root.

Solution

1. Step 1: Separate logs per component instance

   Providing the logging service in each component's providers creates a new instance per component, isolating logs.

2. Step 2: Share global settings

   Injecting a global settings service provided in root allows sharing common configuration across all logging instances.

3. Final Answer:

   Provide the service in each component's providers array and inject a global settings service from root. -> Option D

4. Quick Check:

   Component scope for logs + root scope for settings = best mix [OK]

Hint: Use component scope for instance data, root scope for shared config [OK]

Common Mistakes:

• Using root scope for logs causes shared state issues
• Providing only in module loses per-component isolation
• Using static variables breaks instance separation