Service-based state management in Angular - Step-by-Step Execution

Concept Flow - Service-based state management

Component A needs state

↓

Inject Service

↓

Service holds state

↓

Component A reads/updates state

↓

Component B needs same state

↓

Inject same Service

↓

Component B reads updated state

↓

State shared and synced

Components inject a shared service that holds the state. They read and update this state through the service, enabling shared, synced data.

Execution Sample

Angular

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

@Injectable({ providedIn: 'root' })
export class CounterService {
  count = signal(0);
  increment() { this.count.update(c => c + 1); }
}

A service holds a reactive count signal and an increment method to update it.

Execution Table

Step	Action	State Before	State After	Component View Update
1	Component A injects CounterService	count=0	count=0	Displays 0
2	Component A calls increment()	count=0	count=1	Displays 1
3	Component B injects CounterService	count=1	count=1	Displays 1
4	Component B calls increment()	count=1	count=2	Displays 2
5	Component A reads count	count=2	count=2	Displays 2
6	No further updates	count=2	count=2	No change

💡 No more actions; state remains stable at count=2

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
count	0	1	2	2

Key Moments - 3 Insights

Why do both components see the same count value?

Because both inject the same singleton service instance that holds the shared count signal, as shown in steps 3 and 5 of the execution_table.

What happens when increment() is called in one component?

The service updates the count signal, triggering all components using it to update their views, as seen in steps 2 and 4.

Why doesn't the count reset when a new component injects the service?

The service is provided in root, so Angular creates one instance shared across components, preserving state as shown in step 3.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What is the count value after Component B calls increment()?

A 1

B 2

C 0

D 3

💡 Hint

Check the 'State After' column at step 4 in the execution_table.

At which step does Component A first see the updated count value of 2?

A Step 5

B Step 3

C Step 2

D Step 6

💡 Hint

Look at when Component A reads count after Component B increments it in the execution_table.

If the service was not provided in root but in each component, what would happen to the count values?

A Count value would increment twice as fast

B Both components share the same count value

C Each component has its own count value starting at 0

D Count value would reset to 1 after each increment

💡 Hint

Consider the singleton nature of services provided in root versus component scope.

Concept Snapshot

Service-based state management in Angular:
- Create a service with state (e.g., signal).
- Provide it in root for singleton.
- Inject service in components.
- Components read/update shared state via service.
- State changes reflect in all components using it.

Full Transcript

Service-based state management in Angular means using a shared service to hold and manage state. Components inject this service to read and update the state. Because the service is a singleton provided in root, all components share the same state instance. When one component updates the state, others see the change immediately. This approach keeps state centralized and synchronized across components.

Practice

1. What is the main benefit of using a service for state management in Angular?

easy

A. It allows sharing state easily across multiple components.

B. It automatically updates the UI without any coding.

C. It replaces the need for components entirely.

D. It makes the app run faster by skipping change detection.

Solution

1. Step 1: Understand service role in Angular

   Services hold data and logic separate from components.

2. Step 2: Recognize state sharing benefit

   Services can be injected into many components, sharing the same state instance.

3. Final Answer:

   It allows sharing state easily across multiple components. -> Option A

4. Quick Check:

   Service-based state management = shared state [OK]

Hint: Services share data across components easily [OK]

Common Mistakes:

• Thinking services replace components
• Believing services auto-update UI without code
• Assuming services speed up app by skipping detection

2. Which decorator and property make an Angular service a singleton across the app?

easy

A. @NgModule({ providers: [] })

B. @Component({ selector: 'app-root' })

C. @Directive({ selector: '[appService]' })

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

Solution

1. Step 1: Identify Angular service decorator

   @Injectable marks a class as a service for dependency injection.

2. Step 2: Understand providedIn property

   Setting providedIn: 'root' makes the service a singleton app-wide.

3. Final Answer:

   @Injectable({ providedIn: 'root' }) -> Option D

4. Quick Check:

   Singleton service = @Injectable with providedIn root [OK]

Hint: Use @Injectable({ providedIn: 'root' }) for singleton services [OK]

Common Mistakes:

• Confusing @Component with service decorator
• Using @NgModule providers without providedIn
• Mistaking @Directive for service declaration

3. Given this service code, what will the console log after calling increment() twice?

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

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

  increment() {
    this.count.update(c => c + 1);
  }
}

const service = new CounterService();
service.increment();
service.increment();
console.log(service.count());

medium

A. 1

B. 0

C. 2

D. undefined

Solution

1. Step 1: Understand initial signal value

   The signal count starts at 0.

2. Step 2: Apply two increments

   Each increment adds 1, so after two calls, count is 2.

3. Final Answer:

   2 -> Option C

4. Quick Check:

   0 + 1 + 1 = 2 [OK]

Hint: Each update adds 1; two calls add 2 total [OK]

Common Mistakes:

• Forgetting to call the signal as a function to get value
• Assuming count resets after each increment
• Confusing update with set method

4. What is wrong with this Angular service code for state management?

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

@Injectable()
export class DataService {
  data = signal([]);

  addItem(item: string) {
    this.data().push(item);
  }
}

medium

A. The service is missing providedIn: 'root' for singleton scope.

B. The signal value is mutated directly, which breaks reactivity.

C. The addItem method should return the updated array.

D. The signal should be initialized with null, not an empty array.

Solution

1. Step 1: Check signal mutation method

   The code calls this.data() to get the array, then pushes directly.

2. Step 2: Understand signal immutability

   Directly mutating the array breaks Angular's reactivity; must use update() or set() to replace value.

3. Final Answer:

   The signal value is mutated directly, which breaks reactivity. -> Option B

4. Quick Check:

   Mutate signal value immutably to keep reactivity [OK]

Hint: Never mutate signal value directly; use update or set [OK]

Common Mistakes:

• Ignoring providedIn for singleton scope
• Expecting addItem to return value
• Thinking null is better initial value than []

5. You want to share a list of tasks across components using a service with Angular signals. Which approach correctly updates the tasks list immutably when adding a new task?

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

@Injectable({ providedIn: 'root' })
export class TaskService {
  tasks = signal([]);

  addTask(newTask: string) {
    // Which line correctly updates tasks?
  }
}

hard

A. this.tasks.set([...this.tasks(), newTask]);

B. this.tasks = signal([...this.tasks(), newTask]);

C. this.tasks().push(newTask);

D. this.tasks.update(tasks => { tasks.push(newTask); return tasks; });

Solution

1. Step 1: Understand immutable update with signals

   Signals require replacing the value immutably to trigger updates.

2. Step 2: Analyze options for correct update

   this.tasks.set([...this.tasks(), newTask]); uses set() with a new array including the new task, which is correct.

3. Final Answer:

   this.tasks.set([...this.tasks(), newTask]); -> Option A

4. Quick Check:

   Immutable update with set() = correct pattern [OK]

Hint: Use set() with new array copy to update signals immutably [OK]

Common Mistakes:

• Mutating array inside update without returning new array
• Directly pushing to signal value
• Reassigning signal variable instead of updating value