Most Angular apps don't have a state-management problem. They have a state-ownership problem.
In enterprise Angular projects, the pattern is almost always the same:
A team starts a project. Someone says, "we'll need state management eventually."
NgRx gets added on day one.
Six months later, they're maintaining 400+ lines of boilerplate — actions, reducers, effects, selectors — just to manage a loading spinner and a modal toggle.
This isn't an NgRx problem. It's an ownership problem.
🚩Ownership defines architecture. Without it, even the best tools become unnecessary complexity.
📚 Table of Contents
The Real Question Isn't "Which Library?"
The Real Question Isn't "Which Library?"
It's "Who owns this state?"
Most teams reach for a global store before they understand their state boundaries. They assume "reactive" means "global." It doesn't.
Angular Signals fundamentally changes this conversation.
What Signals Actually Changed
Before Signals, even local state was awkward. You'd reach for a BehaviorSubject, expose an observable, subscribe somewhere, handle takeUntil cleanup. It worked — but it was ceremonial.
Now:
// That's it. Reactive. Zero ceremony.
const count = signal(0);
const doubled = computed(() => count() * 2);
// Update
count.update(n => n + 1);
Two lines. No subscription management. No boilerplate.
Your modal state, filter toggles, tab selection, loading indicators — all handled. Locally. Elegantly.
"Signals gave us the ability to start simple and add complexity only when boundaries prove insufficient."
The State Spectrum (Tool-Agnostic)
Not all states are created equal. Before choosing a tool, define the scope:
| Scope | Ownership | Angular Solution |
|---|---|---|
| Local | Component-owned. Lives and dies with the component. |
signal() + computed()
|
| Shared | Service-managed. Multiple components in the same feature. | Injectable service + Signals |
| Global | Cross-feature. Event-sourced. Auditable. | NgRx (SignalStore or full) |
The mistake is treating everything as global by default.
When You DON'T Need a Global Store
✅ Modal visibility
✅ Filter selections
✅ Tab active state
✅ Loading indicators
✅ Form field state
✅ Pagination cursor
✅ Local UI preferences
None of these need NgRx. None of them ever did. Signals just made that obvious.
When NgRx Is Actually Justified
Let me be clear: NgRx still matters. Just not for everything.
You should consider NgRx when:
- 🔄 Complex multi-step workflows — checkout flows, multi-stage forms, wizard-style processes.
- 📋 Auditability requirements — compliance needs every state change logged and replayable.
- 👥 Distributed team boundaries — multiple teams writing to the same domain with clear contracts.
- ⚡ Event-heavy orchestration — actions as the single source of truth across features.
- 🐛 Time-travel debugging — when you genuinely need to replay state changes.
What NgRx gives you at scale:
-➡️ Actions as documented contracts.
-➡️ Reducers as pure, predictable transformations.
-➡️ Effects for side-effect isolation.
-➡️ DevTools for distributed debugging.
-➡️ Feature state isolation via modules.
The Blast Radius Framework
When deciding on state architecture, ask one question:
"What's the blast radius of this state change?"
| Blast Radius | Solution |
|---|---|
| 1 component affected |
signal() locally |
| 1 feature (3–5 components) | Service + Signals |
| Multiple features / teams | NgRx SignalStore |
| Cross-app events + compliance | Full NgRx |
This removes opinion from the decision and replaces it with architecture logic.
The Senior Developer's Rule
State complexity should justify architecture complexity. Never the reverse.
If your state-management setup is harder to explain than the business problem it solves, you've already shipped the wrong answer.
Don't scale your tooling faster than your app scales.
The Modern Angular Answer (Hybrid Model)
It's not "NgRx vs. Signals."
It's Signals locally, services for shared scope, NgRx for organizational scale.
◼️ signal() — Local Component State (Simplest)
// LOCAL: Component state with signals
@Component({...})
export class DashboardComponent {
activeTab = signal(0);
filtersOpen = signal(false);
}
// modal.component.ts — No NgRx needed here
@Component({
selector: 'app-modal',
standalone: true
})
export class ModalComponent {
// ✅ Local state — stays local
protected isOpen = signal(false);
protected title = signal('');
// ✅ Derived state — automatic reactivity
protected headerClass = computed(() =>
`modal-header ${this.isOpen() ? 'active' : 'hidden'}`
);
open(title: string) {
this.title.set(title);
this.isOpen.set(true);
}
close() {
this.isOpen.set(false);
}
}
◼️ Service-based Shared State (Mid-tier)
// SHARED: Service-scoped signals
@Injectable({
providedIn: 'root'
})
export class UserPreferencesService {
// ✅ Private write, public read
private _theme = signal<Theme>('light');
private _language = signal<string>('en');
// ✅ Public signals (read-only surface)
theme = this._theme.asReadonly();
language = this._language.asReadonly();
// ✅ Derived computed state
isDark = computed(() => this._theme() === 'dark');
setTheme(t: Theme) {
this._theme.set(t);
}
setLanguage(l: string) {
this._language.set(l);
}
}
◼️ NgRx SignalStore — Scalable Domain State (Enterprise)
// GLOBAL: NgRx SignalStore for enterprise scale
// order.store.ts — When NgRx is justified
import { signalStore, withState, withMethods, withComputed } from '@ngrx/signals';
type OrderState = {
orders: Order[];
selectedId: string | null;
loading: boolean;
};
export const OrderStore = signalStore(
withState<OrderState>({
orders: [],
selectedId: null,
loading: false
}),
withComputed(({ orders, selectedId }) => ({
selectedOrder: computed(() =>
orders().find(o => o.id === selectedId()) ?? null
),
pendingCount: computed(() =>
orders().filter(o => o.status === 'pending').length
),
})),
withMethods((store, orderService = inject(OrderService)) => ({
async loadOrders() {
patchState(store, { loading: true });
const orders = await orderService.getAll();
patchState(store, { orders, loading: false });
},
}))
);
◼️ computed() — Derived State Pattern (Reactive)
// cart.component.ts — Derived state without manual subscriptions
@Component({
standalone: true
})
export class CartComponent {
private items = signal<CartItem[]>([]);
private discount = signal(0);
// ✅ All derived from signals — always in sync
subtotal = computed(() =>
this.items().reduce((sum, i) => sum + i.price * i.qty, 0)
);
discountAmt = computed(() => this.subtotal() * this.discount());
total = computed(() => this.subtotal() - this.discountAmt());
isEmpty = computed(() => this.items().length === 0);
itemCount = computed(() =>
this.items().reduce((n, i) => n + i.qty, 0)
);
}
◼️ Hybrid — Signals Local + NgRx Global (Architecture)
// checkout.component.ts — Hybrid architecture pattern
@Component({
standalone: true
})
export class CheckoutComponent {
// ✅ Global: complex order domain → NgRx
private orderStore = inject(OrderStore);
selectedOrder = this.orderStore.selectedOrder; // Signal from store
// ✅ Local: UI-only state → Signals
protected activeStep = signal(1);
protected isReviewing = signal(false);
// ✅ Bridge: derived from both worlds
protected canConfirm = computed(() =>
this.activeStep() === 3 && !!this.selectedOrder() && this.isReviewing()
);
}
Signals vs. Store: A Balanced Discussion
This isn't about picking a winner. It's about picking the right tool for the job.
| Aspect | Signals + Services | NgRx Store |
|---|---|---|
| Learning curve | Minimal | Steep |
| Boilerplate | Near zero | High |
| DevTools | Limited | Excellent |
| Audit trails | Manual | Built-in |
| Team boundaries | Convention | Enforced |
| Cross-domain events | Complex | Native |
| Performance | Granular | Predictable |
Use Signals when:
- State is a component/feature local
- Team understands reactive boundaries
- No audit requirements
- Simple to moderate complexity
Use NgRx when:
- Multiple teams write to the same state
- Compliance needs action logging.
- Complex cross-domain workflows.
- Time-travel debugging provides value.
Enterprise Reality Check
Large Angular systems have real needs that Signals alone cannot address at team-scale:
- Predictable workflows across features
- Ownership boundaries between teams
- Debugging visibility across deployment environments
- Scalable orchestration for complex event flows
NgRx addresses these organizational problems — not just technical ones.
The mistake is importing this complexity before the organization needs it.
What I Apply as an Architect
Start simple. Escalate when complexity demands it. Never reverse this order.
Default to signal() + computed() for component-local state
Use injectable services with Signals for feature boundaries
Add ComponentStore or SignalStore when patterns repeat
Reach for full NgRx only when organizational scale justifies it
The best Angular state management is the one you don't notice. If new developers ask about your store setup before understanding the business domain, you probably overengineered it.
Signals gave us a gift: the ability to start simple and add complexity only when boundaries prove insufficient.
Use that gift wisely.
Let's Discuss
What's the FIRST sign your Angular app actually needs a global state library?
Drop your answer below. Let's build an architecture checklist together.
Possible answers:
🔄 Multiple teams writing to the same state
📊 Audit and compliance requirements
🐛 Time-travel debugging needs
👥 Team coordination overhead
Further Reading
Angular Signals Guide
NgRx SignalStore Documentation
Found this useful? Follow for more Angular architecture insights.
📌 More From Me
I share daily insights on web development, architecture, and frontend ecosystems.
Follow me here on Dev.to, and connect on LinkedIn for professional discussions.
🌐 Connect With Me
If you enjoyed this post and want more insights on scalable frontend systems, follow my work across platforms:
🔗 LinkedIn — Professional discussions, architecture breakdowns, and engineering insights.
📸 Instagram — Visuals, carousels, and design‑driven posts under the Terminal Elite aesthetic.
🧠 Website — Articles, tutorials, and project showcases.
🎥 YouTube — Deep‑dive videos and live coding sessions.
Top comments (0)