Interview answer drill

Use this Angular interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow 30-day foundations study plan Practice more Angular interview questions

NgRx Store vs local component state in Angular: global vs local, and when to use NgRxFrontend interview answer

HighIntermediateAngular

By FrontendAtlas Team · Updated Apr 19, 2026

Interview focus

This Angular interview question tests whether you can explain NgRx Store vs component state in Angular: shared state boundaries and cost trade-offs, connect it to production trade-offs, and handle common follow-up questions.

NgRx Store vs component state in Angular: shared state boundaries and cost trade-offs explanation without falling back to memorized docs wording
Store and State Management reasoning, edge cases, and production failure modes
How you would answer the most likely Angular interview follow-up

Practice more Angular interview questions

Interview quick answer

The real NgRx question is not whether Store is good, but whether the state is shared, long-lived, or business-critical enough to justify actions, reducers, selectors, and explicit transitions. Short-lived UI state should usually stay local.

Full interview answer

State-boundary question

Do not ask "Is NgRx good or bad?" Ask: who needs this state, how long should it live, and does it need traceable transitions? If state is screen-local and short-lived, keep it in the component. If it is shared, persistent, or business-critical across features, move it to Store.

Worked example

A modal open flag, tab selection, or temporary form draft often belongs in component state. Auth state, cart totals, entity caches, or cross-feature workflow state usually belong in Store because multiple parts of the app read them and the transitions need to be explicit.

Decision matrix

Ephemeral UI: component state.
Shared cross-feature state: Store.
Business-critical or traceable transitions: Store is usually worth the boilerplate.
If the cost of actions, reducers, and selectors is higher than the sharing problem, keep it local.

State example	Best home	Why
Modal open/close	Component local state	Purely visual, page-specific, short lifetime
Form draft on one screen	Component local state (or form state service)	Usually local workflow; avoid global complexity too early
Authenticated user/session	NgRx Store	Needed across app (header, guards, permissions, API flows)
Shared filters used by multiple pages/widgets	NgRx Store (or URL + Store facade)	Multiple consumers need consistent synchronized state
Server-backed entity cache (users/orders/products)	NgRx Store	Shared read model, dedupe/loading/error handling, normalized updates

Decision matrix: global vs local state in Angular

Put it in Store if...	Why this is a good signal
More than one feature/component tree needs it	Store gives a single source of truth
You need time-travel/debuggable action history	Actions + reducers make transitions explicit
You need robust loading/error/retry flows for shared data	Effects + selectors centralize async behavior and read models
You need derived state reused across screens	Memoized selectors prevent duplicated transformation logic
State must survive route changes or be rehydrated	Global state lifetime matches app-level concerns

Practical rule set for when to use NgRx

TYPESCRIPT

// Example split: local UI state + global business state
@Component({
  selector: 'app-products-page',
  template: `...`
})
export class ProductsPageComponent {
  // local UI state (ephemeral)
  isFilterPanelOpen = false;

  // global shared state (Store)
  readonly vm$ = this.store.select(selectProductsVm);

  constructor(private store: Store) {}

  ngOnInit(): void {
    this.store.dispatch(loadProducts());
  }

  onFilterChanged(filter: ProductFilter): void {
    this.store.dispatch(setSharedProductFilter({ filter }));
  }

  togglePanel(): void {
    this.isFilterPanelOpen = !this.isFilterPanelOpen;
  }
}

Anti-pattern	Why it hurts	Better approach
Putting every tiny UI flag in Store	Action/reducer noise, slower iteration, harder readability	Keep ephemeral view state in component
Keeping cross-feature business state in random components	Duplicate logic, drift, race conditions between screens	Promote to Store with selectors/effects
Using Store as a dump of raw API payloads only	Components become transformation-heavy and inconsistent	Create memoized selectors for derived view models
Mixing local and global ownership without boundaries	Unclear source of truth and hard-to-debug updates	Document state ownership per feature

What senior reviewers usually call out

Interview summary

Use local component state for UI-ephemeral, screen-specific concerns. Use NgRx Store for shared, durable, business-relevant state that multiple parts of the app depend on. The best architecture is mixed: local for view mechanics, Store for app-level truth.