Written for Angular 22.1 (stable release, July 29, 2026).
A team ships a five-component admin panel. Two weeks later, they have 14 action files, 6 reducers, 9 selectors, and roughly 200 lines of boilerplate wrapping state that would fit in two signals and one computed value. Every new field means touching four files, and onboarding a contractor takes three days instead of three hours.
That is the over-engineering trap, and it is the most common Angular state management mistake in small and mid-sized teams. The opposite failure exists too: a 40-route app where six teams mutate the same shared service, and nobody can explain why the cart total went stale after logout.
This guide gives you concrete thresholds for app size, domain complexity, team size, cross-feature reach, and audit needs, so you can pick between a signal service, NgRx SignalStore, and classic NgRx Store without guessing. You will get a decision matrix, escalation triggers, and one worked example from state size to final pattern.
In this guide:
- Choose the Smallest State Boundary That Solves the Problem
- Start With Component Signals for Local Interaction State
- Share Feature Data With a Service-Backed Store
- Add SignalStore When a Shared Feature Needs Structure
- Use Classic NgRx Store for Auditable Cross-Feature Workflows
- Adopt a State Architecture That Can Evolve
Choose the Smallest State Boundary That Solves the Problem
The rule that saves the most cleanup work: put state at the narrowest scope that still solves the problem, and only widen it when a specific trigger fires.
Most state architecture arguments are really scope arguments. A team debates NgRx versus signals when the real question is whether the cart total belongs to one component, one feature, or the whole app.
Classify Component, Feature, and Global State
Sort every piece of state into one of three buckets before you pick a library.
- Component state: lives and dies with one component. A dropdown’s open flag, a table’s sort direction, an accordion’s expanded index, all common in Angular Material component trees.
- Feature state: shared by components inside one routed feature. A product list’s filters, pagination cursor, and selected item.
- Global state: touched by unrelated features. The signed-in user, permissions, feature flags, the shopping cart.
If you cannot name at least three unrelated features that read a value, it is not global state. Auth tokens and permissions almost always qualify. A checkout wizard’s step index almost never does.
Separate UI State, Domain State, and Server State
These three have different lifetimes, and mixing them causes most stale-data bugs.
| State type | Examples | Where it belongs |
| UI state | Modal open, active tab, sidebar collapsed | Component signals |
| Domain state | Cart items, draft order, selected workspace | Feature service or SignalStore |
| Server state | Product list, user profile fetched from an API | Service with caching plus resource(), httpResource(), or an HTTP-backed signal. httpResource() is the purpose-built Angular primitive for HTTP-fetched server state; it handles loading, error, and value signals automatically and integrates directly with the signal graph. |
The failure mode when you merge them: a shared service with three subscribers re-triggers the same GET /products call on every route change because loading state and cached data live in the same untracked object.
Use Escalation Triggers Instead of App Size Alone
Component count is a weak signal. A 60-component dashboard with one data source is simpler than a 20-component billing app with five write paths.
Escalate one level when any of these fire:
- Cross-cutting reach: 5 or more unrelated features read or write the same slice.
- Component tree depth: you are passing the same value through 4+ levels of input() bindings just to reach a leaf.
- Multi-team ownership: two or more teams own different slices of the same domain and deploy on different schedules.
- Audit requirements: compliance or support needs a replayable record of who changed what, in order.
- Debug cost: you cannot answer “what changed this value?” in under five minutes.
None of those triggers firing? Stay with a service and signals. Angular reactive forms, Angular module federation, and Angular control flow each shift these thresholds, and the sections below cover how.
Start With Component Signals for Local Interaction State
Angular signals are the default state primitive now. For local interaction state, they are usually the whole answer.
Model Writable Values With signal()
signal() returns a WritableSignal. You read it by calling it, and write with .set() or .update().
import { Component, signal } from '@angular/core';
@Component({
selector: 'app-counter',
template: `
<p>Count: {{ count() }}</p>
<button (click)="inc()">Increment</button>
`,
})
export class Counter {
count = signal(0);
inc() { this.count.update(n => n + 1); }
}No standalone: true here. It has been the default since Angular 19, and Angular’s linter flags it as redundant.
Calculate Derived Values With computed()
Never store what you can derive. A computed() signal only tracks the signals it reads, and only recalculates when one of those changes.
subtotal = computed(() =>
this.items().reduce((sum, i) => sum + i.price * i.qty, 0)
);
tax = computed(() => this.subtotal() * 0.0875);
total = computed(() => this.subtotal() + this.tax());Storing total as its own writable signal is how teams end up with three sources of truth that disagree after a partial refund.
Keep Effects Outside Derived State
effect() is for pushing values out of the signal graph: logging, localStorage writes, canvas draws, third-party library sync. It runs after change detection and is not meant for computing state.
Writing to a signal inside an effect to derive another value creates order-dependent bugs that are hard to reproduce. Use computed() or linkedSignal() instead. linkedSignal() handles the common case of a writable value that resets when a source changes, like a selected row that clears when the filter changes.
Understand Signal Reads and Change Detection
When a template calls count(), Angular records the dependency. On write, only components that read that signal get marked for check.
That fine-grained tracking is why heavier state libraries rarely help performance in current Angular. Practitioners commonly report fewer wasted change detection cycles after moving from a mutable shared object to signals, though the size of the gain depends on component tree depth and how many templates read the value. Adding NgRx will not fix a template that recalculates a filtered array on every pass; a computed() will.
One more context shift worth naming: zoneless change detection became the default for new projects in Angular 21. If your app was generated after Angular 21, Zone.js is excluded by default from ng new.
Existing apps keep Zone.js until you actively opt out. The onpush_zoneless_migration schematic automates the OnPush and zoneless conversion for most components. The practical implication for state architecture: in a zoneless app, signals are the primary mechanism that tells Angular when to update the view, so the signal-first approach in this guide is the natural fit rather than an alternative to consider.
Scaffold with ng generate component from the Angular CLI, bootstrap with bootstrapApplication, and start with a CounterStore-style class only when two components need the same value.
For a worked example of signal-based state under real load, see Building a Chat App with Angular.
Share Feature Data With a Service-Backed Store
As soon as a second component needs the same value, lift it into an injectable service. This pattern covers most maintainable applications, and many teams never need to go further.
Build a Signal Service With Private Writes and Public Reads
Expose reads, hide writes. Components should call methods, not mutate state directly.
@Injectable({ providedIn: 'root' })
export class CartStore {
private readonly _items = signal<CartItem[]>([]);
readonly items = this._items.asReadonly();
readonly count = computed(() => this._items().length);
readonly subtotal = computed(() =>
this._items().reduce((s, i) => s + i.price * i.qty, 0)
);
add(item: CartItem) {
this._items.update(list => [...list, item]);
}
clear() { this._items.set([]); }
}asReadonly() is the enforcement mechanism. Without it, any component can call .set() and you lose your single source of truth in week three.
Scope matters: providedIn: ‘root’ gives one instance for the app. For per-route isolation, list the service in that route’s providers array so it resets on navigation.
Use BehaviorSubject for Observable-First Workflows
RxJS still wins when you need stream semantics: debounceTime on a search box, switchMap to cancel in-flight requests, retry with backoff, or merging multiple data streams.
Use BehaviorSubject when downstream code expects an Observable. Bridge with toSignal() for templates and toObservable() when a signal needs to feed an RxJS pipeline. Do not run both a BehaviorSubject and a signal for the same value; pick one owner.
Handle API Calls and Loading State Without Duplicate Requests
The classic bug: three components inject the service, each calls load() in ngOnInit, and you fire three identical GET /orders requests on every navigation.
Two fixes that work:
- Guard with a status signal: if (this.status() !== ‘idle’) return; before firing the request.
- Share the stream: shareReplay({ bufferSize: 1, refCount: true }) on the HTTP observable so concurrent subscribers reuse one call.
Model loading as a single field, not three booleans. status = signal<‘idle’ | ‘loading’ | ‘loaded’ | ‘error’>(‘idle’) prevents the impossible loading: true, error: true combination.
Define Reset Rules for Routes, Logout, and Feature Teardown
Write down when each store clears. Undefined reset rules cause the “previous user’s cart appears after login” bug.
- On logout: clear every store holding user-scoped data. Keep a single reset() method per store and call them all from one auth handler.
- On route exit: for route-provided services, Angular destroys the instance for you.
- On feature teardown: use DestroyRef with onDestroy() to cancel timers and open subscriptions.
Add SignalStore When a Shared Feature Needs Structure
@ngrx/signals gives you the structure of a state management library without the action-reducer-selector file spread. Reach for it when a service crosses roughly 150 lines or when three or more developers edit the same store.
Define Feature State With withState
withState sets the shape and initial values. Each top-level key becomes its own signal, so consumers subscribe only to what they read.
export const OrdersStore = signalStore(
{ providedIn: 'root' },
withState({
orders: [] as Order[],
filter: 'all' as OrderFilter,
status: 'idle' as RequestStatus,
})
);Encapsulate Commands With withMethods
withMethods holds your write API. Updates go through patchState, which applies an immutable partial update.
withMethods((store, api = inject(OrdersApi)) => ({
setFilter(filter: OrderFilter) {
patchState(store, { filter });
},
}))patchState replaces the touched keys rather than mutating in place, so computed dependents fire correctly. Mutating an array with .push() will not notify anything.
Create Read Models With withComputed
withComputed builds derived state on top of the raw slice. This is where filtered lists, counts, and formatted views belong.
withComputed(({ orders, filter }) => ({
visibleOrders: computed(() =>
filter() === 'all' ? orders() : orders().filter(o => o.status === filter())
),
openCount: computed(() => orders().filter(o => o.status === 'open').length),
}))Coordinate Reactive Work With rxMethod and withHooks
rxMethod wraps an RxJS pipeline as a callable store method, which is how you get switchMap cancellation and debounceTime without leaking subscriptions. withHooks runs onInit and onDestroy logic, useful for kicking off the initial load or cleaning up side effects.
AI tooling helps here in a narrow, checkable way: paste an existing 180-line signal service into Copilot or Cursor and ask it to restructure it as withState / withMethods / withComputed. The mechanical split is reliable. Review the rxMethod pipelines by hand, because AI tools routinely pick mergeMap where you need switchMap, which reintroduces the race condition you were trying to remove.
Use Classic NgRx Store for Auditable Cross-Feature Workflows
Classic @ngrx/store costs the most to maintain and pays off in exactly one situation: when you need a full, replayable record of every state transition across features.
Apply the Redux Pattern to Explicit State Transitions
The Redux pattern gives you unidirectional data flow. Components dispatch actions, reducers produce new state, selectors read it, and nothing writes directly to the store.
That constraint is the product. In a 12-team app, it means no engineer can silently mutate the AppState from a component.
Model Commands With Actions and Immutable Reducers
Actions name events, not setters. [Checkout Page] Payment Submitted tells you where it came from and what happened; setPayment tells you nothing during a bug hunt.
export const paymentSubmitted = createAction(
'[Checkout Page] Payment Submitted',
props<{ orderId: string; method: PaymentMethod }>()
);
export const checkoutReducer = createReducer(
initialState,
on(paymentSubmitted, (state, { method }) => ({
...state,
method,
status: 'submitting' as const,
}))
);Reducers stay pure. No HTTP, no Date.now(), no randomness, or replay breaks.
Read Stable Views Through Memoized Selectors
createSelector memoizes. If the inputs don’t change by reference, the projector doesn’t re-run and dependent templates don’t re-render.
Use @ngrx/entity for collections. It gives you normalized ids plus entities, which stops the O(n) array scans that show up on lists past a few thousand rows.
Move HTTP and Other Side Effects Into NgRx Effects
Effects listen for actions, run async work, and dispatch results. Keeping switchMap cancellation inside effects means a user who clicks “Search” four times gets one result, not four racing responses.
Recognize When Time-Travel Debugging Justifies the Boilerplate
Redux DevTools replay is worth the file count when:
- Support engineers must reconstruct a user session from an action log to explain a wrong invoice.
- Compliance requires an audit trail of state changes tied to user identity.
- A multi-step workflow (loan application, insurance quote, order fulfillment) spans 5+ features and hours of wall-clock time.
If nobody on your team has opened Redux DevTools in the last month, that is your answer.
When to stay simple:
- 1 to 3 developers on the codebase
- Under roughly 30 components
- State fits in one or two services
- No compliance or audit trail requirement
- Nobody is asking “what changed this value?” more than once a week
When to add complexity:
- 5 or more unrelated features touch the same slice
- Two or more teams own different slices of one domain
- You need replayable state transitions for support or compliance
- Multi-step workflows span routes and survive page reloads
- Onboarding a new engineer to your state layer takes over a day
Adopt a State Architecture That Can Evolve
Pick a pattern you can grow out of cheaply. Each of these approaches can scale to the next without rewriting your components, as long as components read from a service interface rather than the state container directly.
Team size shapes this as much as the state layer does. See our guide on matching Angular’s structure to team size for the hiring side of this same tradeoff.
Use a Decision Matrix for Team and Domain Complexity
One change in Angular 22.1 directly affects multi-year architecture decisions: Angular is switching to annual major releases, dropping every June. Angular 23 is scheduled for June 2027, Angular 24 for June 2028, and each major version gets two years of active support instead of eighteen months.
For teams making a state architecture decision today, this changes the upgrade math; one predictable major upgrade per year is significantly easier to budget for than two, especially on micro-frontend architectures where each remote has its own upgrade window. The patterns in this guide are all stable across the 22.x series and are designed to survive major version boundaries without component rewrites.
| App size | Domain complexity | Team size | Recommended pattern |
| Small (under ~30 components) | Low | 1-3 | Component signals plus one root service with signal() and computed() |
| Small | Medium | 1-3 | Service + signals, one store per feature, asReadonly() on all reads |
| Small | High | 4-10 | NgRx SignalStore for the complex feature; signals everywhere else |
| Medium (~30-100 components) | Low | 1-3 | Service + signals, route-scoped providers for isolation |
| Medium | Low | 4-10 | Service + signals with a written ownership map per feature |
| Medium | Medium | 4-10 | NgRx SignalStore per feature, no global store |
| Medium | High | 10+ | SignalStore per feature plus classic NgRx for the shared cross-feature slice |
| Large (100+ components) | Low | 4-10 | Service + signals per feature, shared kernel service for auth and flags |
| Large | Medium | 10+ | NgRx SignalStore per feature, classic NgRx for auth, permissions, and cart |
| Large | High | 10+ | Classic NgRx Store with @ngrx/entity and Effects as the global store |
Migrate a Shared Service Without a Big-Bang Rewrite
Escalate one feature at a time, in this order:
- Add a resetAll() entry point and a status signal to the existing service so you can observe behavior before you touch structure.
- Wrap the service in a SignalStore for one feature. Keep the old service’s public method names so components need no edits.
- Delete the old service once the feature’s tests pass against the store.
- Repeat for the next feature. Do not migrate two features in the same pull request.
For classic NgRx, the same rule holds: introduce one feature slice with provideState() before touching the root store.
Set Ownership, Testing, and Observability Rules
- Ownership: one team owns each store file, listed in CODEOWNERS. Cross-team writes go through a method on that store, not patchState from outside.
- Testing: test computed() outputs and store methods directly. Component tests should not assert on internal state shape.
- Observability: log every reset and every failed load with the feature name. When the cart empties unexpectedly, you want a log line, not a bisect.
Avoid Common Failure Modes in Distributed Teams
Reactive Forms Are Local State
Angular reactive forms already hold their own values, validity, and dirty flags. Pushing every keystroke into a global store creates a second source of truth and a change detection cycle per character.
Keep the FormGroup in the component, submit the result to the store, and store only the submitted payload. Signal Forms reached stable status in Angular 22 and can be imported from @angular/forms/signals.
For new forms, Signal Forms are now the recommended approach, since they integrate directly with the signal graph and avoid the FormGroup/store duplication problem above; existing reactive forms remain fully supported and don’t need a forced migration.
Module Federation Needs Explicit Contracts
With Angular module federation, each remote can bundle its own copy of a store. The failure mode teams hit: providedIn: ‘root’ creates a separate AuthStore instance per remote, so the host logs the user out, and the remote still shows them as signed in.
Fix it by marking the shared library as a singleton in the shared config, or by defining a narrow contract (a shared service exposed from the host, or a typed event bus) instead of sharing the store object itself. Version skew across independently deployed remotes is the second failure: remote A ships a new state shape, remote B still reads the old key.
Angular Control Flow Affects Perceived State Cost
@if and @for are the built-in control flow in current Angular, and track is required on @for. A missing or unstable track key (track $index on a reordering list) makes Angular destroy and recreate DOM nodes on every update. Teams read that as “our state is too slow” and reach for NgRx, when the actual fix is track item.id. Check your control flow and your computed() usage before blaming the state layer.
Worked Example
A logistics SaaS: 68 components, 11 routes, 6 engineers on two squads. State inventory is 9 shipment fields, 4 filter fields, auth (user, roles, org), and a live tracking feed over WebSocket. Domain complexity is medium, team size is 4-10, app size is medium.
Following the matrix: NgRx SignalStore for the shipments feature (withState for the slice, rxMethod for the WebSocket subscription, withComputed for filtered views), and a plain signal service with asReadonly() for auth, because only three fields are involved and nobody audits them. No classic NgRx. Total state code is around 220 lines. When the compliance team later asked for an audit log of status changes, the team added one NgRx feature slice for shipment status transitions only, and left the rest alone.
Frequently Asked Questions
When should I use NgRx instead of Angular signals?
Use NgRx (classic Store, not SignalStore) when you need a replayable audit trail across features, such as compliance requirements or multi-step workflows spanning 5 or more features and multiple hours of wall-clock time. For most apps, especially under 100 components with 1 to 10 developers, signals and a signal-backed service or NgRx SignalStore cover the need without the action-reducer-selector overhead.
Do I still need NgRx for state management in Angular 22?
No, not by default. Angular signals, computed values, and a plain injectable service handle component- and feature-level state for most apps. NgRx SignalStore is the next step up for shared state that crosses 150 or more lines or gets edited by 3 or more developers, and classic NgRx Store is reserved for apps that need fully replayable state transitions for audit or compliance reasons.
What is the difference between Angular signals and NgRx SignalStore?
A signal is a single reactive value created with signal, computed, or linkedSignal. NgRx SignalStore is a structured container built on top of signals that adds withState, withMethods, and withComputed, giving you a consistent shape for state, write methods, and derived views once a service grows too large for one file. Use plain signals in a service first, and move to SignalStore only when that service becomes hard to navigate or gets multiple contributors.
Is RxJS still needed if I use Angular signals?
Yes, for stream-based work. RxJS still handles cases signals do not, including debouncing user input, canceling in-flight HTTP requests with switchMap, and retrying failed requests with backoff. Bridge between the two with toSignal for templates and toObservable when a signal needs to feed an RxJS pipeline, but avoid running a BehaviorSubject and a signal for the same value at the same time.
Should I use Signal Forms or reactive forms in Angular 22?
Signal Forms are stable in Angular 22 and are the recommended approach for new forms, since they integrate directly with the signal graph and avoid keeping a separate FormGroup in sync with your state layer. Existing reactive forms remain fully supported, so you don’t need to migrate working forms just to adopt Signal Forms.
Does module federation change how Angular state management works?
Yes. Each federated remote can bundle its own copy of a shared service, so a providedIn root service can end up with a separate instance per remote instead of one shared instance across the whole app. Fix this by marking the shared library as a singleton in your federation config, or by replacing the shared store object with a narrow contract such as a shared service exposed from the host or a typed event bus.
Why does my Angular app feel slow even though I use signals?
The most common cause is a missing or unstable track key on a for loop, which forces Angular to destroy and recreate DOM nodes on every update instead of reusing them. Check your control flow and computed usage before assuming the state layer is the bottleneck, since adding a heavier state library will not fix a tracking problem.
Hire Angular Engineers Who’ve Already Made This Call
If your team is weighing whether to introduce a global store or stay with signal-based services, you need Angular engineers who have made this call in production and lived with the consequences.
Arc pre-vets Angular developers for technical depth and English fluency before you see a profile. HireAI matches your requirements against a pool of vetted candidates and returns a shortlist in minutes, not weeks.
