All topics
Stateadvanced

NgRx Component Store

Explain Component Store as a lighter-weight, locally-scoped alternative to the global NgRx Store.

NgRx Component Store solves a real gap the global Store leaves open: not all state genuinely belongs in a centralized, app-wide store — a lot of state is legitimately local to one component or one small feature (a wizard's current step, a data table's sort/filter/pagination state, an accordion's expanded panels) and forcing it through global actions and reducers adds ceremony without a corresponding benefit, since nothing outside that feature actually needs to observe or coordinate around it.

The global NgRx Store is like a city's central records office handling official, publicly relevant documents; Component Store is like a personal notebook each department keeps for its own day-to-day working notes — perfectly organized and reactive within its own scope, without needing to file every scratch note with the central city archive.

Key Concepts

1
Component Store is a self-contained, injectable class (typically provided at the component level via a providers array, giving it the same scoped-instance-per-subtree lifecycle discussed under Hierarchical Injectors) that bundles state, selectors, updaters, and effects together in one class, without requiring separate global action types, a reducer registered in a root store, or DevTools-visible dispatches for every tiny local interaction.
providers
2
Its API mirrors NgRx's core concepts at a smaller scale: this.state$ and .select() for reading state reactively (backed by an internal BehaviorSubject, tying back to that topic directly), .updater() for defining pure state-transition functions similar to reducer case handlers, and .effect() for handling asynchronous side effects that eventually call an updater — giving you the same overall reactive discipline as full NgRx, just scoped to exactly the component/feature that needs it, with dramatically less setup ceremony.
this.state$.select()BehaviorSubject.updater().effect()
3
A balanced interview answer positions Component Store and the global Store as complementary, not competing: many real applications use the global Store for genuinely cross-cutting, shared application state (current user, feature flags, cart contents) while using Component Store for local, feature-scoped UI state that doesn't need to be globally observable — picking the right one per piece of state, rather than defaulting everything into one or the other.
Store