Week 17: State Management at Scale

1. Signal-Based State Services (the "Poor Man's Store")

The simplest real state-management pattern in Angular is a plain injectable service holding a signal, with methods that update it — everything you already know from Week 9, applied to shared state instead of a single feature.

import { Injectable, signal, computed } from '@angular/core';

interface CartItem { id: string; price: number; quantity: number; }

@Injectable({ providedIn: 'root' })
export class CartState {
  private items = signal<CartItem[]>([]);

  readonly cartItems = this.items.asReadonly();
  readonly itemCount = computed(() => this.items().reduce((n, i) => n + i.quantity, 0));
  readonly total = computed(() => this.items().reduce((sum, i) => sum + i.price * i.quantity, 0));

  addItem(item: CartItem) {
    this.items.update((list) => [...list, item]);
  }

  removeItem(id: string) {
    this.items.update((list) => list.filter((i) => i.id !== id));
  }
}

.asReadonly() is the detail worth internalizing — it exposes a read-only signal to consumers, so only CartState's own methods can actually mutate items. Any component can read cartItems, but only this service controls how it changes — the same encapsulation principle from Week 9, applied to state.

This pattern alone covers the majority of real apps. Reach for something heavier only once you hit a problem it doesn't solve well — Section 3 covers exactly when that happens.

2. NgRx Signal Store Fundamentals

@ngrx/signals provides a more structured version of the same idea — state, computed values, and methods declared together with a consistent shape, plus a convention for how updates happen.

import { signalStore, withState, withComputed, withMethods, patchState } from '@ngrx/signals';
import { computed } from '@angular/core';

interface CartItem { id: string; price: number; quantity: number; }
interface CartStateShape { items: CartItem[]; }

export const CartStore = signalStore(
  { providedIn: 'root' },
  withState<CartStateShape>({ items: [] }),
  withComputed(({ items }) => ({
    itemCount: computed(() => items().reduce((n, i) => n + i.quantity, 0)),
    total: computed(() => items().reduce((sum, i) => sum + i.price * i.quantity, 0)),
  })),
  withMethods((store) => ({
    addItem(item: CartItem) {
      patchState(store, (state) => ({ items: [...state.items, item] }));
    },
    removeItem(id: string) {
      patchState(store, (state) => ({ items: state.items.filter((i) => i.id !== id) }));
    },
  }))
);

patchState() is the one required way to update a Signal Store's state — it's a small but deliberate constraint: every state change goes through one recognizable call, which is what makes the DevTools story in Section 5 possible.

import { Component, inject } from '@angular/core';
import { CartStore } from './cart.store';

export class CartSummary {
  cart = inject(CartStore);
  // cart.items(), cart.itemCount(), cart.total(), cart.addItem(...) -- all directly available
}

3. When (and When Not) to Reach for NgRx/Redux-Style State

Compare directly against Section 1's plain service:

• Plain signal-based service fits: most apps, most of the time. Less ceremony, no new dependency, and every technique is one you already know from Week 9.
• Signal Store fits: state shared across many features with a real need for consistent structure — a large team wanting every feature's state to look the same, or state complex enough that withComputed's composition and a single patchState convention genuinely earns its keep.

The failure mode worth avoiding is reaching for a Signal Store (or worse, full NgRx with actions/reducers/effects) for a feature with two pieces of state and one component that reads them — that's Section 1's pattern, with less code and nothing lost. State-management tooling should follow a real scaling problem, not precede one.

4. Entity State Patterns

"Entity state" means storing a normalized collection — a flat map keyed by ID, rather than a raw array — which makes lookups, updates, and removals by ID all O(1) instead of requiring an array scan.

interface ProductsStateShape {
  entities: Record<string, Product>;
  ids: string[]; // preserves order, since object key order isn't guaranteed to be stable
}

// Looking up a product by ID: O(1)
const product = state.entities[productId];

// Rendering in order:
const orderedProducts = state.ids.map((id) => state.entities[id]);

This matters once a collection grows past a trivial size — updating one product by ID in a plain array means .map()-ing the whole array to find and replace it; updating it in entity-shaped state is a single object-key write. @ngrx/signals ships an entities feature implementing exactly this pattern, so you rarely need to hand-write the normalization logic yourself.

5. DevTools & Time-Travel Debugging

Because every Signal Store update goes through patchState(), tooling can intercept and log each one — Redux DevTools (originally built for Redux, and usable with NgRx) shows a timeline of every state change, and lets you "time travel" by replaying state back to any previous point.

import { withDevtools } from '@angular/core'; // conceptual -- actual API varies by NgRx version

// Wire the store (or a root-level state) through a devtools integration in dev builds only,
// so every patchState() call becomes a visible, inspectable entry in the Redux DevTools timeline.

The practical value: when a bug report says "the cart total was wrong," you can scrub backward through the exact sequence of addItem/removeItem calls that produced it — far faster than reproducing the bug from scratch by guessing at user actions.

6. Testing Stateful Services

Both patterns from this lesson are testable with the same technique from Week 9 — a plain signal-based service needs nothing special at all:

import { CartState } from './cart-state.service';

describe('CartState', () => {
  it('computes the total price correctly', () => {
    const cart = new CartState();

    cart.addItem({ id: '1', price: 10, quantity: 2 });
    cart.addItem({ id: '2', price: 5, quantity: 1 });

    expect(cart.total()).toBe(25);
  });
});

A Signal Store needs TestBed, since signalStore() relies on Angular's injector internally:

import { TestBed } from '@angular/core/testing';
import { CartStore } from './cart.store';

describe('CartStore', () => {
  it('computes the total price correctly', () => {
    TestBed.configureTestingModule({ providers: [CartStore] });
    const store = TestBed.inject(CartStore);

    store.addItem({ id: '1', price: 10, quantity: 2 });
    store.addItem({ id: '2', price: 5, quantity: 1 });

    expect(store.total()).toBe(25);
  });
});

Either way, the assertions themselves read identically to any other signal-based test — state management doesn't need special-cased testing techniques once it's built on signals.

7. Hands-on Exercise

8. Knowledge Check

Four quick questions. Expand each to check your answer.