Dependency Injection

Dependency injection (DI) means a class doesn't build the things it needs — it asks for them, and something else decides what it gets. In Angular that "something else" is an injector: an object that knows how to create values for keys, creates each one at most once, and hands the same instance to everyone who asks it.

The mental model is a hotel front desk. A guest (your component) doesn't go into the kitchen and cook; they ring the desk and say "I need breakfast". The desk (the injector) knows which kitchen is on duty (the provider), sends the order there the first time, and keeps track of what's already been made. The guest never knows — or cares — whether breakfast came from the main kitchen or, in a test, from a vending machine. The general pattern is covered on the JavaScript site under Dependency injection; this chapter is about Angular's machinery for it.

export class ConsoleLogger {
  log(message: string) {
    console.log(message);
  }
}

export class OrderServiceHardWired {
  private readonly logger = new ConsoleLogger(); // decided here, forever

  place(id: string) {
    this.logger.log(`order ${id} placed`);
  }
}

import { Service, inject } from '@angular/core';
import { Logger } from './cart';

@Service()
export class OrderService {
  private readonly logger = inject(Logger);

  place(id: string) {
    this.logger.log(`order ${id} placed`);
  }
}

it('lets a test swap the dependency without touching OrderService', () => {
  const fakeLogger = { log: vi.fn() };
  TestBed.configureTestingModule({ providers: [{ provide: Logger, useValue: fakeLogger }] });
  TestBed.inject(OrderService).place('A-17');
  expect(fakeLogger.log).toHaveBeenCalledWith('order A-17 placed');
});

A service is just a class whose instance is meant to be shared: it holds state or logic that several components need, so it lives outside any one of them. In Angular 22 the standard way to write one is the new @Service() decorator plus the inject() function for its own dependencies. ng generate service in CLI 22.2 now emits @Service() by default (the generator has an --injectable flag that produces the old @Injectable({ providedIn: 'root' }) instead — I checked the schematic's template).

What @Service() does, exactly — from the ServiceDecorator declaration in @angular/core 22.2 and the compiler source:

• @Service() "marks a class as a service and makes it automatically available in the dependency injection system". At runtime it compiles to a provider definition with providedIn: 'root' — I logged CartService.ɵprov.providedIn and got root. So @Service() is the same scope as @Injectable({ providedIn: 'root' }): one lazily-created, tree-shakable singleton for the whole app.
• @Service({ autoProvided: false }) — "the service won't be exposed to the dependency injection system automatically. It is up to the user to expose it in a providers list." (see Opting out of root providing).
• @Service({ factory: () => value }) — "creates a service that is automatically provided and uses the value returned from the factory function". The class becomes a typed token and the factory supplies what you get.
• The compiler is stricter than with @Injectable: a @Service class cannot use constructor injection (error NG2028), cannot carry another Angular decorator (NG1006), must be called (@Service, without parentheses, is "@Service must be called"), and autoProvided must be a literal true/false.

import { Component, Service, computed, inject, signal } from '@angular/core';

@Service()
export class Logger {
  readonly lines = signal<string[]>([]);

  log(message: string) {
    this.lines.update((lines) => [...lines, message]);
  }
}

@Service()
export class CartService {
  private readonly logger = inject(Logger);
  private readonly items = signal<string[]>([]);

  readonly count = computed(() => this.items().length);

  add(item: string) {
    this.items.update((items) => [...items, item]);
    this.logger.log(`added ${item}`);
  }
}

@Component({
  selector: 'app-add-to-cart',
  template: `<button (click)="cart.add('book')">Add</button>`,
})
export class AddToCart {
  protected readonly cart = inject(CartService);
}

@Component({
  selector: 'app-cart-badge',
  template: `<span>{{ cart.count() }} items</span>`,
})
export class CartBadge {
  protected readonly cart = inject(CartService);
}

// The factory form: the class is only a typed token; the factory supplies the value.
@Service({ factory: () => inject(DOCUMENT).defaultView!.localStorage })
export abstract class BrowserStorage {
  abstract getItem(key: string): string | null;
  abstract setItem(key: string, value: string): void;
}

@Injectable is the decorator Angular has used for services since Angular 2, and it isn't deprecated in 22. @Service() covers the common case — root singleton, inject() style — but @Injectable still does several things @Service deliberately doesn't:

• Constructor injection. Older code (and NgModule-era apps like techStatus on Angular 16) wires dependencies through constructor parameters. @Injectable is what lets the compiler generate a factory that reads those parameter types.
• Not providing itself. @Injectable() with no providedIn only makes the class injectable; someone must still list it in providers. (@Service({ autoProvided: false }) now covers this too.)
• Other scopes. providedIn: 'platform' (shared by every app on the page) and the deprecated providedIn: SomeNgModule / 'any'.
• Inline provider options. @Injectable({ providedIn: 'root', useFactory: … }), useClass, useExisting and useValue in the decorator itself.
• Everything already written. Angular's own classes and every library you depend on use it.

// The older equivalent of @Service(): still valid, and still needed for constructor injection.
@Injectable({ providedIn: 'root' })
export class LegacyUserApi {
  constructor(
    private http: HttpClient,
    private logger: Logger,
  ) {}

  load(id: number) {
    this.logger.log(`loading ${id}`);
    return this.http.get(`/api/users/${id}`);
  }
}

@Injectable()
export class NewLogger {
  readonly id = ++created;
  log(msg: string) {
    return `[new #${this.id}] ${msg}`;
  }
}

There are two ways for a class to receive a dependency. The old way is constructor parameters: Angular reads each parameter's type and uses it as the token. The modern way is the inject() function, called in a field initializer or the constructor body, which takes the token as an ordinary argument.

The @Inject(token) parameter decorator exists because of a gap in the old way. TypeScript types disappear at runtime, so a parameter typed string gives Angular nothing to look up — and lots of useful dependencies (an API URL, a config object) aren't classes. @Inject(API_URL) says "ignore this parameter's type; use this token". inject() doesn't have the gap at all, because you always pass the token explicitly.

export const API_URL = new InjectionToken<string>('API_URL');

// Old style: constructor parameters + @Inject for non-class tokens.
@Injectable({ providedIn: 'root' })
export class OldStyleClient {
  constructor(
    @Inject(API_URL) readonly baseUrl: string,
    private logger: Logger, // a class type is its own token — no @Inject needed
  ) {}
}

// Modern style: inject() takes the token directly.
@Service()
export class NewStyleClient {
  readonly baseUrl = inject(API_URL);
  private readonly logger = inject(Logger);
}

Four words get used loosely, and interviews love to check you can separate them:

• Token — the key you ask for. A class (CartService), an InjectionToken (API_URL), or rarely a string. It identifies what you want, not how to make it.
• Provider — the recipe registered under a token: "for Logger, use this class / value / factory / other token". @Service() and providedIn: 'root' are providers declared on the class itself; providers: [...] arrays declare them from outside.
• Injector — the container that holds providers, runs a recipe the first time a token is requested, and caches the result. Injectors form a tree.
• Instance — the value the injector produced and cached. One per provider per injector.

The analogy that sticks: a token is the name on a coat-check ticket, a provider is the instruction "if nobody's collected it yet, fetch it from rack B", an injector is the coat-check desk, and the instance is the coat. Two people holding tickets with the same name at the same desk get the same coat; a different desk (a component's own injector) can hold a different coat under the same name.

it('without multi, the last provider wins', () => {
  TestBed.configureTestingModule({
    providers: [
      { provide: API_URL, useValue: 'first' },
      { provide: API_URL, useValue: 'second' },
    ],
  });
  expect(TestBed.inject(API_URL)).toBe('second');
});

A provider object always has provide (the token) plus one recipe. There are four recipes:

The shorthand providers: [NewLogger] means { provide: NewLogger, useClass: NewLogger }.

The one interviewers probe is useClass vs useExisting, because they look alike and behave very differently. My spec proves it with a counter that numbers every NewLogger the injector creates:

let created = 0;

@Injectable()
export class NewLogger {
  readonly id = ++created;
  log(msg: string) {
    return `[new #${this.id}] ${msg}`;
  }
}

// The class the rest of the app already injects everywhere.
@Injectable()
export class OldLogger {
  log(msg: string) {
    return `[old] ${msg}`;
  }
}

it('useExisting: two tokens, ONE instance', () => {
  TestBed.configureTestingModule({
    providers: [NewLogger, { provide: OldLogger, useExisting: NewLogger }],
  });
  const viaOld = TestBed.inject(OldLogger);
  const viaNew = TestBed.inject(NewLogger);
  expect(viaOld).toBe(viaNew);
  expect(viaOld.log('hi')).toBe('[new #1] hi');
});

it('useClass: two tokens, TWO instances', () => {
  TestBed.configureTestingModule({
    providers: [NewLogger, { provide: OldLogger, useClass: NewLogger }],
  });
  const viaOld = TestBed.inject(OldLogger);
  const viaNew = TestBed.inject(NewLogger);
  expect(viaOld).not.toBe(viaNew);
  expect(viaOld.log('hi')).toBe('[new #1] hi');
  expect(viaNew.log('hi')).toBe('[new #2] hi');
  expect(viaOld instanceof NewLogger).toBe(true);
});

it('useFactory picks an implementation at runtime, once per injector', () => {
  let calls = 0;
  TestBed.configureTestingModule({
    providers: [
      { provide: LOCALE, useValue: 'fr' },
      {
        provide: Greeter,
        useFactory: () => {
          calls++;
          return inject(LOCALE) === 'fr' ? new FrenchGreeter() : new EnglishGreeter();
        },
      },
    ],
  });
  expect(TestBed.inject(Greeter).greet('Rohit')).toBe('Bonjour, Rohit');
  TestBed.inject(Greeter);
  expect(calls).toBe(1);
});

it('useFactory with the older deps array', () => {
  TestBed.configureTestingModule({
    providers: [
      { provide: LOCALE, useValue: 'en' },
      {
        provide: Greeter,
        useFactory: (locale: string) => (locale === 'fr' ? new FrenchGreeter() : new EnglishGreeter()),
        deps: [LOCALE],
      },
    ],
  });
  expect(TestBed.inject(Greeter).greet('Rohit')).toBe('Hello, Rohit');
});

export const LEGACY = new InjectionToken<OldLogger>('LEGACY');

providers: [
  NewLogger,
  { provide: OldLogger, useClass: NewLogger },
  { provide: LEGACY, useExisting: OldLogger },
]
// then, in this order (the counter starts at 0):
inject(NewLogger).id;
inject(LEGACY).id;
inject(OldLogger).id;

A token has to exist at runtime, because the injector looks providers up by object identity. Classes exist at runtime, so they work as their own tokens. But many things you want to inject aren't classes: a URL string, a config object described by an interface, a function, a Window. An interface vanishes when TypeScript compiles, so there's nothing to look up:

export interface AppConfig { apiUrl: string }

@Service()
export class UsesInterface {
  config = inject(AppConfig);
  // ✘ TS2693: 'AppConfig' only refers to a type, but is being used as a value here.
}

export interface AppConfig {
  apiUrl: string;
  retries: number;
}

// An interface has no runtime value, so it needs a token to stand in for it.
export const APP_CONFIG = new InjectionToken<AppConfig>('APP_CONFIG');

// A token can carry its own default — no provider needed anywhere.
export const WINDOW = new InjectionToken<Window>('WINDOW', {
  providedIn: 'root',
  factory: () => inject(DOCUMENT).defaultView!,
});

// providedIn left out: does it still provide itself?
export const NOW = new InjectionToken<() => number>('NOW', {
  factory: () => () => Date.now(),
});

it('multi providers collect values', () => {
  TestBed.configureTestingModule({
    providers: [
      { provide: VALIDATORS, useValue: 'required', multi: true },
      { provide: VALIDATORS, useValue: 'email', multi: true },
    ],
  });
  expect(TestBed.inject(VALIDATORS)).toEqual(['required', 'email']);
});

inject() is not magic global lookup. It works only while Angular is in the middle of creating something through DI — that's the injection context. Angular sets a "current injector" before it runs a constructor or factory and clears it afterwards; inject() simply reads that current injector. Call it at any other moment and there's no injector to read.

Places that are an injection context:

• A class's field initializers and constructor body, when DI creates the class (components, directives, pipes, services).
• Factory functions of providers (useFactory, @Service({ factory }), InjectionToken factories).
• Functional guards, resolvers and HTTP interceptors — the router and HttpClient run them in one.
• Any function passed to runInInjectionContext(injector, fn).

Places that are not: event handlers, lifecycle hooks such as ngOnInit, setTimeout/subscribe callbacks, async code after an await, and module top level.

@Component({
  selector: 'app-profile',
  template: `<button (click)="onSave()">Save</button>`,
})
export class Profile {
  private readonly logger = inject(Logger); // ✅ field initializer
  private readonly injector = inject(Injector); // ✅ capture the injector for later

  constructor() {
    inject(Logger).log('constructor ok'); // ✅ constructor
  }

  onSave() {
    inject(Logger).log('save'); // ❌ NG0203 — event handlers run outside the injection context
  }

  onSaveFixed() {
    runInInjectionContext(this.injector, () => inject(Logger).log('save via runInInjectionContext'));
  }
}

// Helper functions that call inject() are fine — as long as THEY are called in an injection context.
export function injectLogger(prefix: string) {
  const logger = inject(Logger);
  return (msg: string) => logger.log(`${prefix}: ${msg}`);
}

@Component({ selector: 'app-uses-helper', template: `` })
export class UsesHelper {
  readonly log = injectLogger('helper'); // ✅ field initializer
}

A provider listed in a component's providers array lives in that component's element injector. Every instance of the component gets its own injector, so every instance gets its own instance of the service, created with the component and destroyed with it. The component's children (its template, and their templates) see that instance, because lookups climb from child to parent and stop at the first match. Siblings and the rest of the app don't.

This is how you give each widget its own state — each counter, each wizard, each row editor — instead of one global singleton. It's also how you override a root service for one subtree.

@Service({ autoProvided: false })
export class CounterStore implements OnDestroy {
  readonly id = ++storeCount;
  readonly count = signal(0);
  static destroyed: number[] = [];

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

  ngOnDestroy() {
    CounterStore.destroyed.push(this.id);
  }
}

@Component({
  selector: 'app-counter-label',
  template: `<i>store #{{ store.id }} = {{ store.count() }}</i>`,
})
export class CounterLabel {
  protected readonly store = inject(CounterStore); // resolved from the nearest ancestor that provides it
}

@Component({
  selector: 'app-counter',
  imports: [CounterLabel],
  providers: [CounterStore], // each <app-counter> gets its own CounterStore
  template: `<button (click)="store.increment()">+1</button> <app-counter-label />`,
})
export class Counter {
  protected readonly store = inject(CounterStore);
}

@Component({
  selector: 'app-counters',
  imports: [Counter],
  template: `
    <app-counter />
    @if (showSecond()) {
      <app-counter />
    }
  `,
})
export class Counters {
  readonly showSecond = signal(true);
}

// Overriding a root service for one subtree.
@Component({
  selector: 'app-isolated',
  providers: [Logger], // a SECOND Logger, separate from the root one
  template: ``,
})
export class Isolated {
  readonly logger = inject(Logger);
}

@Service() provides itself in root. That's what you want for app-wide singletons, but wrong for state that should only exist inside a scope — a per-component store, a per-route wizard, a per-feature cache. If such a class were root-provided, forgetting to add it to providers wouldn't fail: some component would silently get the global instance and share state with every other one.

@Service({ autoProvided: false }) is Angular 22's way to say "this is a service, but I'll decide where it's provided". It compiles to providedIn: null — it's injectable, but no injector has it until you list it. It's the @Service equivalent of @Injectable() without providedIn.

it('autoProvided:false is not available from the root injector', () => {
  let message = '';
  try {
    TestBed.inject(CounterStore);
  } catch (e) {
    message = (e as Error).message;
  }
  expect(message).toContain('NG0201');
});

it('autoProvided:false can be provided at the application level too', () => {
  TestBed.configureTestingModule({ providers: [CounterStore] });
  expect(TestBed.inject(CounterStore)).toBe(TestBed.inject(CounterStore));
});

Sometimes a dependency is nice-to-have: an analytics client that only exists in production, a parent form a field can work without, a plugin token a library lets you fill in. By default, a missing provider is an error (NG0201). inject(token, { optional: true }) turns "missing" into null, and its return type becomes T | null so TypeScript makes you handle it. The old equivalent is the @Optional() parameter decorator.

export interface Analytics {
  send(event: string): void;
}
export const ANALYTICS = new InjectionToken<Analytics>('ANALYTICS');

@Service()
export class Tracker {
  private readonly analytics = inject(ANALYTICS, { optional: true }); // Analytics | null
  readonly sent: string[] = [];

  track(event: string) {
    if (this.analytics) {
      this.analytics.send(event);
    } else {
      this.sent.push(`(dropped) ${event}`);
    }
  }
}

The dependency inversion principle says high-level code should depend on an abstraction, not on a concrete low-level class. In Angular terms: Checkout should ask for "a payment gateway", not for "the HTTP-calling Stripe gateway". DI then plugs in the real one in the app and a fake one in tests, and Checkout never knows the difference.

The neat Angular 22 version uses an abstract class as the token and the @Service factory form to make the real implementation the default:

export interface ChargeResult {
  ok: boolean;
  id: string;
}

// The abstraction. The factory makes the real gateway the default,
// so the app needs no extra provider — but tests can swap it.
@Service({ factory: () => inject(HttpPaymentGateway) })
export abstract class PaymentGateway {
  abstract charge(cents: number): Promise<ChargeResult>;
}

@Service()
export class HttpPaymentGateway extends PaymentGateway {
  private readonly http = inject(HttpClient);

  charge(cents: number) {
    return firstValueFrom(this.http.post<ChargeResult>('/api/charges', { cents }));
  }
}

// High-level code depends only on the abstraction.
@Service()
export class Checkout {
  private readonly gateway = inject(PaymentGateway);
  readonly status = signal<'idle' | 'paid' | 'declined'>('idle');

  async pay(cents: number) {
    if (cents <= 0) throw new Error('amount must be positive');
    const result = await this.gateway.charge(cents);
    this.status.set(result.ok ? 'paid' : 'declined');
    return result.id;
  }
}

class FakeGateway extends PaymentGateway {
  calls: number[] = [];
  next: ChargeResult = { ok: true, id: 'ch_fake' };
  async charge(cents: number) {
    this.calls.push(cents);
    return this.next;
  }
}

it('uses the fake gateway — no HTTP at all', async () => {
  TestBed.configureTestingModule({
    providers: [{ provide: PaymentGateway, useValue: new FakeGateway() }],
  });
  const checkout = TestBed.inject(Checkout);
  const fake = TestBed.inject(PaymentGateway) as FakeGateway;

  expect(await checkout.pay(1999)).toBe('ch_fake');
  expect(checkout.status()).toBe('paid');
  expect(fake.calls).toEqual([1999]);

  fake.next = { ok: false, id: 'ch_declined' };
  await checkout.pay(500);
  expect(checkout.status()).toBe('declined');
});

Angular doesn't have one injector; it has a tree of them, in two layers:

• Environment injectors — the root injector (from bootstrapApplication providers and everything providedIn: 'root'), plus child environment injectors created for lazy-loaded routes with providers. Above root sits the platform injector, and above that a null injector that throws NG0201.
• Element injectors — one per element that has a component or directive with providers/viewProviders. They mirror the template tree: a component's element injector is the parent of the element injectors inside its template.

When something calls inject(token), Angular walks up the element injectors first — from the requesting element, to its parent element, through each component's host, up to the root component — and only if none of them has a provider does it switch to the environment injectors: the nearest environment injector, then its parents, root, platform, null. The first injector that has a provider wins, creates (or reuses) the instance, and the walk stops.

inject() takes options that change where the walk starts and stops:

export const THEME = new InjectionToken<string>('THEME', { factory: () => 'root-default' });

@Component({
  selector: 'app-theme-probe',
  template: `{{ theme }} | parent={{ fromParent ?? 'null' }} | self={{ own ?? 'null' }}`,
})
export class ThemeProbe {
  readonly theme = inject(THEME); // normal walk: element injectors, then environment injectors
  readonly fromParent = inject(THEME, { skipSelf: true, optional: true }); // start one level up
  readonly own = inject(THEME, { self: true, optional: true }); // only this element
}

@Component({
  selector: 'app-panel',
  imports: [ThemeProbe, HostTheme],
  providers: [{ provide: THEME, useValue: 'panel' }],
  template: `<p class="inside" appHostTheme><app-theme-probe /></p>`,
})
export class Panel {}

@Component({
  selector: 'app-page',
  imports: [Panel, ViewPanel, ThemeProbe, HostTheme],
  template: `
    <div class="outside" appHostTheme><app-theme-probe /></div>
    <app-panel />
    <app-view-panel />
  `,
})
export class Page {}

// A probe that provides THEME on its own element.
@Component({
  selector: 'app-self-probe',
  providers: [{ provide: THEME, useValue: 'self' }],
  template: `{{ theme }} | parent={{ fromParent }} | self={{ own }}`,
})
export class SelfProbe {
  readonly theme = inject(THEME);
  readonly fromParent = inject(THEME, { skipSelf: true });
  readonly own = inject(THEME, { self: true });
}

@Component({
  selector: 'app-self-page',
  imports: [SelfProbe],
  providers: [{ provide: THEME, useValue: 'page' }],
  template: `<app-self-probe />`,
})
export class SelfPage {}

// host: true — search stops at the host element of the component whose template this directive is in.
@Directive({ selector: '[appHostTheme]', host: { '[attr.data-host-theme]': 'theme ?? "null"' } })
export class HostTheme {
  readonly theme = inject(THEME, { host: true, optional: true });
}

@Component({
  selector: 'app-view-panel',
  imports: [HostTheme],
  viewProviders: [{ provide: THEME, useValue: 'view-panel' }],
  template: `<p class="view-inside" appHostTheme></p>`,
})
export class ViewPanel {}