Angular resolves dependencies through an injector hierarchy. A root-provided service can be shared across the application, while a component provider can give that component subtree a separate instance. The right scope depends on who should share the state.

These Angular interview questions use two sibling draft editors. If each editor should hold an independent draft, a shared mutable root service would create the wrong behavior even if dependency injection worked exactly as configured.

How can each editor receive a local draft?

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

@Injectable({ providedIn: 'root' })
export class DraftStore {
  readonly text = signal('');
}

@Component({
  selector: 'draft-editor',
  standalone: true,
  providers: [DraftStore],
  template: '<label>Draft <input [value]="store.text()" ' +
    '(input)="store.text.set($any($event.target).value)"></label>'
})
export class DraftEditor {
  readonly store = inject(DraftStore);
}

Mount two draft-editor instances in a parent that imports DraftEditor. Each component-level provider supplies a separate DraftStore for its subtree. Removing that provider makes resolution fall back to the root service in this example, so the editors share its text.

Why keep the root declaration in this exercise?

It makes the contrast visible: the same token can resolve to a local provider or an ancestor provider. In a real design, remove an unnecessary root default if missing local setup should fail rather than silently share state.

The nearest applicable provider wins according to Angular's resolution rules. Environment and element injectors have related but distinct roles. Use the hierarchy documentation when route-level providers or resolution modifiers make the example more complex.

What should happen when the editor closes?

A component-scoped service shares the component subtree's lifetime. When that instance is destroyed, a later new editor gets new local state. If a draft must survive closing the editor, move it to an owner with the needed lifetime or save it through the application's persistence workflow.

Subscriptions and other resources owned by the service still need appropriate cleanup. A local provider is not a reason to leave timers or external listeners running after destruction.

How do you test the difference?

  • Render two sibling editors.
  • Type a unique value into the first.
  • Verify the second remains blank with local providers.
  • Repeat a separate fixture with the root-only setup and observe sharing.
  • Destroy and recreate an editor to check the intended reset.

A service class test alone cannot establish this result. You need a component or injector test that creates the hierarchy. State the setup so another developer can reproduce the ownership behavior.

What is a common mistake?

Adding the same stateful service to providers at several levels can create unexpected separate instances. Developers then wonder why an update is visible in one subtree but absent in another. Check where the token is provided before adding manual synchronization.

The opposite mistake is putting every draft at root and clearing it on every navigation. That can couple independent workflows and make resets race. Scope the service to the intended shared owner.

Interview answer to practice

“These editors need independent drafts, so I provide the store at each editor boundary. If they must edit one shared draft, I move the provider to their common owner. I test the hierarchy and the reset lifetime, not only the store's methods.”

References and next practice

angular.dev — ng di

angular question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud