Bird
Raised Fist0
Angularframework~30 mins

Service scope (root, module, component) in Angular - Mini Project: Build & Apply

Choose your learning style10 modes available
Understanding Angular Service Scopes: root, module, and component
📖 Scenario: You are building a simple Angular app that tracks how many times a button is clicked. You want to learn how Angular services can have different lifetimes depending on where they are provided: at the root, module, or component level.
🎯 Goal: Create an Angular service that counts clicks and explore how its scope changes when provided in root, a feature module, or a component. You will see how the count behaves differently depending on the service scope.
📋 What You'll Learn
Create a service called ClickCounterService with a count property and an increment() method.
Provide the service in the root injector in Step 2.
Create a feature module called FeatureModule and provide the service in this module in Step 3.
Provide the service in a component called ClickComponent in Step 4.
Observe how the click count behaves differently depending on the service scope.
💡 Why This Matters
🌍 Real World
Understanding service scope helps you manage shared data and state in Angular apps, avoiding bugs and improving performance.
💼 Career
Angular developers often need to decide where to provide services to control data sharing and component behavior effectively.
Progress0 / 4 steps
1
Create the ClickCounterService with count and increment method
Create an Angular service called ClickCounterService with a public property count initialized to 0 and a method increment() that increases count by 1.
Angular
Hint

Use @Injectable() without parameters. Define count as a number starting at 0. The increment() method should add 1 to count.

2
Provide ClickCounterService in the root injector
Modify the ClickCounterService to be provided in the root injector by adding { providedIn: 'root' } inside the @Injectable() decorator.
Angular
Hint

Add { providedIn: 'root' } inside @Injectable() to make the service singleton app-wide.

3
Provide ClickCounterService in a feature module
Create a feature module called FeatureModule and provide ClickCounterService in its providers array. Import NgModule from '@angular/core'.
Angular
Hint

Use @NgModule decorator with a providers array including ClickCounterService. Export the class FeatureModule.

4
Provide ClickCounterService in a component
Create a component called ClickComponent with a providers array that includes ClickCounterService. Import Component from '@angular/core'.
Angular
Hint

Use @Component with providers array including ClickCounterService. Inject the service in the constructor as public clickCounter. Use a button in the template that calls increment() and shows count.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard