What is the difference between providing a service in root vs in a component?

Q: What is the difference between providing a service in root vs in a component?

**Target Audience:** Developers who know what a service is and now need to reason about how many instances exist and how long they live. **Difficulty:** Medium > **How to read this doc:** Ideas are explained in plain language first, then tagged with 📌 Interview term: so you also learn the words an interviewer listens for. The construction and destruction logs in section 5 were printed by the example running on Angular 22.2.3, and the bundle observation in section 6 comes from an ng build with CLI 22.2.3. ## 1. Why This Even Matters — A Story First A school has one **main library**. Anyone in any classroom can borrow from it, and a book returned by one class is there for the next. That is convenient, and it is also the problem: if one class scribbles in a book, every class sees the scribbles. Some classrooms also keep a **classroom shelf**. When a new class starts in room 4, it gets a fresh empty shelf. When the class ends, the shelf is cleared. Room 5 has

The problem

Question presented to candidate: "We have a CartService. One teammate put providedIn: 'root' on it, another added it to a component's providers array, and now some screens see an empty cart. Explain the difference between those two ways of providing it."

What a strong answer should cover:

providedIn: 'root' registers the service in the root environment injector: one singleton for the whole app, created on first use, living until the app is destroyed.
providers: [CartService] on a component registers it in that component's element injector: a new instance per component instance, shared with that component's children, destroyed with it (its ngOnDestroy runs).
Lookup walks up from the requesting component, so a component-level provider shadows the root one for its subtree; that is why some screens saw a different, empty cart.
When to use each: root for app-wide state and stateless helpers; component-level for per-widget state that must reset when the widget goes away.
Root providers are tree-shakable by design (no providers array references the class), while a class listed in providers is always bundled.

Clarifying questions expected:

"Should every screen share one cart, or should each widget own its own state?"
"Is the component that provides it rendered more than once, for example in a list?"

Code / implementation expected: Yes — count instances created and destroyed under each option.

di
providedin

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Developers who know what a service is and now need to reason about how many instances exist and how long they live. Difficulty: Medium

How to read this doc: Ideas are explained in plain language first, then tagged with 📌 Interview term: so you also learn the words an interviewer listens for. The construction and destruction logs in section 5 were printed by the example running on Angular 22.2.3, and the bundle observation in section 6 comes from an ng build with CLI 22.2.3.

1. Why This Even Matters — A Story First

A school has one main library. Anyone in any classroom can borrow from it, and a book returned by one class is there for the next. That is convenient, and it is also the problem: if one class scribbles in a book, every class sees the scribbles.

Some classrooms also keep a classroom shelf. When a new class starts in room 4, it gets

The solution is hidden so you can try first

9 min read · 10 sections

Read the code

AngularCounting constructions: one root singleton vs one instance per component

Open in playground

import { Component, Injectable, OnDestroy, inject, signal } from "@angular/core";

let created = 0;

// One class, two ways to provide it.
@Injectable({ providedIn: "root" })
export class CartService implements OnDestroy {
  readonly id = ++created;
  readonly items = signal(0);
  constructor() { console.log(`CartService #${this.id} created`); }
  ngOnDestroy() { console.log(`CartService #${this.id} destroyed`); }
}

// No providers: asks the tree, finds the root singleton.
@Component({
  selector: "app-shared-cart",
  template: `<p>shared uses #{{ cart.id }} items={{ cart.items() }}
    <button (click)="cart.items.update(n => n + 1)">add</button></p>`,
})
export class SharedCart { cart = inject(CartService); }

// providers: [CartService] gives THIS component (and its children) a fresh instance.
@Component({
  selector: "app-own-cart",
  providers: [CartService],
  template: `<p>own uses #{{ cart.id }} items={{ cart.items() }}
    <button (click)="cart.items.update(n => n + 1)">add</button></p>`,
})
export class OwnCart { cart = inject(CartService); }

@Component({
  selector: "app-root",
  imports: [SharedCart, OwnCart],
  template: `
    <app-shared-cart />
    <app-shared-cart />
    @if (showOwn()) { <app-own-cart /> <app-own-cart /> }
    <button (click)="showOwn.set(!showOwn())">toggle own carts</button>
  `,
})
export class AppComponent {
  showOwn = signal(true);
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.