One of the most practical Angular state management decisions is choosing NgRx Store vs local component state. Use local state for short-lived UI details and use Store for shared, long-lived, globally relevant state. Interviewers expect clear rules for global vs local state in Angular and when NgRx is worth it.
NgRx Store vs local component state in Angular: global vs local, and when to use NgRx
Preparing for interviews?
Use guided tracks for structured prep, then practice company-specific question sets when you want targeted interview coverage.
Quick Answer
Answer
Core idea
Don’t 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.
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 |
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 |
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 |
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.
Similar questions
Guides