Singleton service behavior in Angular - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

How does Angular ensure a service is a singleton?

Consider an Angular service provided in the root injector. What happens when multiple components inject this service?

A All components receive the same instance of the service.

B Each component gets a new instance of the service.

C Only the first component gets the service instance; others get null.

D Angular throws an error if multiple components inject the same service.

💡 Hint

Think about how Angular's root injector works for services provided in 'root'.

When a service is provided in the root injector, Angular creates one instance shared across the app. This makes the service a singleton, so all components get the same instance.

❓ state_output

intermediate

What is the value of the counter after multiple component injections?

Given a singleton service with a counter property initialized to 0, two components increment it by 1 each. What is the final counter value?

Angular

export class CounterService {
  counter = 0;
  increment() { this.counter++; }
}

// Component A and Component B both inject CounterService and call increment() once.

A Error: counter is undefined

B 1

C 0

D 2

💡 Hint

Remember the service is a singleton shared by both components.

Since both components share the same service instance, each increment adds 1 to the same counter. So after two increments, the counter is 2.

🔧 Debug

advanced

Why does providing a service in a component break singleton behavior?

What happens if you provide a service in the providers array of two different components instead of in root?

A Angular still shares one instance across components.

B Angular throws a runtime error about multiple providers.

C Each component gets its own separate instance of the service.

D The service instance is shared only if components are siblings.

💡 Hint

Think about how Angular creates injectors for components with providers.

Providing a service in a component's providers array creates a new instance scoped to that component. So each component gets its own instance, breaking the singleton pattern.

🧠 Conceptual

advanced

How does Angular's injector hierarchy affect singleton services?

Which statement best describes how Angular's hierarchical injectors influence singleton service instances?

A A service provided in root is shared app-wide unless overridden in a child injector.

B Services provided in root are recreated for each lazy-loaded module automatically.

C Singleton services cannot be overridden in child injectors.

D Angular merges all injectors into one global injector at runtime.

💡 Hint

Consider how Angular allows overriding services in feature modules or components.

Angular uses a hierarchy of injectors. A service provided in root is a singleton app-wide unless a child injector (like a lazy-loaded module or component) provides its own instance, which overrides the root one locally.

📝 Syntax

expert

Which code snippet correctly provides a singleton service in Angular 17+ standalone component?

Choose the correct way to provide a singleton service in a standalone Angular component using Angular 17+ syntax.

A

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

@Component({
  standalone: true,
  providers: [MyService]
})
export class MyComponent {
  service = inject(MyService);
}

B

@Component({
  standalone: true
})
export class MyComponent {
  constructor(private service: MyService) {}
}

@Injectable({providedIn: 'root'})
export class MyService {}

C

@Component({
  standalone: true,
  providers: [{provide: MyService, useClass: MyService}]
})
export class MyComponent {
  service = inject(MyService);
}

@Injectable()
export class MyService {}

D

@Component({
  standalone: true
})
export class MyComponent {
  service = new MyService();
}

@Injectable({providedIn: 'root'})
export class MyService {}

💡 Hint

Remember that providing a service in 'root' makes it singleton app-wide, and standalone components can inject it via constructor.

Option B correctly uses @Injectable({providedIn: 'root'}) to make the service singleton and injects it via constructor in a standalone component. Option B provides the service in the component providers, creating a new instance. Option B provides the service locally without 'providedIn: root', so not singleton. Option B manually creates a new instance, bypassing Angular DI.

Practice

1. What does it mean when an Angular service is a singleton?

easy

A. There is only one shared instance of the service across the entire app.

B. A new instance of the service is created for every component.

C. The service can only be used in one component at a time.

D. The service is automatically destroyed after use.

Solution

1. Step 1: Understand singleton concept in Angular

   A singleton service means Angular creates one instance of the service and shares it everywhere.

2. Step 2: Compare options with singleton definition

   Only There is only one shared instance of the service across the entire app. correctly describes a single shared instance across the app.

3. Final Answer:

   There is only one shared instance of the service across the entire app. -> Option A

4. Quick Check:

   Singleton = one shared instance [OK]

Hint: Singleton means one instance shared app-wide [OK]

Common Mistakes:

• Thinking each component gets its own service instance
• Confusing singleton with service destruction
• Believing singleton limits service usage to one component

2. Which is the correct way to make an Angular service a singleton using the @Injectable decorator?

easy

A. @Injectable({ scope: 'singleton' })

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

C. @Injectable({ singleton: true })

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

Solution

1. Step 1: Recall Angular service singleton syntax

   Angular uses providedIn: 'root' to provide a singleton service at the app root level.

2. Step 2: Check each option's validity

   Only @Injectable({ providedIn: 'root' }) uses the correct syntax. Others are invalid or do not exist in Angular.

3. Final Answer:

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

4. Quick Check:

   Singleton service = providedIn: 'root' [OK]

Hint: Use providedIn: 'root' for singleton services [OK]

Common Mistakes:

• Using non-existent properties like singleton or scope
• Confusing component-level providers with root-level
• Omitting the @Injectable decorator

3. Given this Angular service and two components using it:

export class CounterService {
  count = 0;
  increment() { this.count++; }
  getCount() { return this.count; }
}

Both components call increment() once. What will getCount() return when called from either component?

medium

A. 0

B. 1

C. 2

D. Undefined

Solution

1. Step 1: Understand singleton service shared state

   Since the service is singleton, both components share the same count variable.

2. Step 2: Calculate increments from both components

   Each component calls increment() once, so total increments = 2.

3. Final Answer:

   2 -> Option C

4. Quick Check:

   Shared state increments twice = 2 [OK]

Hint: Singleton shares state; increments add up [OK]

Common Mistakes:

• Assuming each component has separate service instance
• Thinking count resets per component
• Ignoring shared service state

4. You created a service with @Injectable() but forgot to add providedIn: 'root'. What problem will occur when multiple components inject this service?

medium

A. Angular will throw a compile-time error.

B. The service will not be injectable anywhere.

C. The service will be singleton by default anyway.

D. Angular will create separate instances for each component, breaking singleton behavior.

Solution

1. Step 1: Understand default service provider behavior

   Without providedIn: 'root', Angular does not provide the service globally.

2. Step 2: Effect on multiple injections

   Each component that provides the service separately will get its own instance, so no singleton.

3. Final Answer:

   Angular will create separate instances for each component, breaking singleton behavior. -> Option D

4. Quick Check:

   Missing providedIn: 'root' = multiple instances [OK]

Hint: No providedIn: 'root' means no singleton [OK]

Common Mistakes:

• Assuming singleton is default without providedIn
• Expecting compile errors for missing providedIn
• Thinking service becomes unusable

5. You want to share user login status across multiple components using a singleton service. Which approach correctly ensures the service is singleton and updates are reflected everywhere?

hard

A. Create service with @Injectable({ providedIn: 'root' }) and use a BehaviorSubject to hold login status.

B. Create service without providedIn and add it to each component's providers array.

C. Create service with @Injectable({ providedIn: 'root' }) but store login status in a local variable inside each component.

D. Create service with @Injectable() and manually instantiate it in each component constructor.

Solution

1. Step 1: Ensure singleton service provision

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

2. Step 2: Use BehaviorSubject for reactive shared state

   BehaviorSubject allows components to subscribe and get updates when login status changes.

3. Step 3: Evaluate other options

   Options B, C, and D break singleton or do not share state properly.

4. Final Answer:

   Create service with @Injectable({ providedIn: 'root' }) and use a BehaviorSubject to hold login status. -> Option A

5. Quick Check:

   Singleton + reactive state = shared updates [OK]

Hint: Use providedIn: 'root' and BehaviorSubject for shared reactive state [OK]

Common Mistakes:

• Adding service to component providers breaking singleton
• Storing shared data only inside components
• Manually creating service instances instead of DI