state-management

State Management

This document covers state management patterns using Angular signals and migration from RxJS patterns.

Table of Contents

• When to Use Signals vs Plain Properties
• Immutable Update Patterns for Signals
• Effect vs Observables
• linkedSignal for Mutable Derived State
• BehaviorSubject + combineLatest Migration
• Migrating Classes That Extend BehaviorSubject
• Migrating Token Interfaces
• Signal-Based Change Detection

---

When to Use Signals vs Plain Properties

Core principle: Signals exist to feed Angular's reactive graph. If a value has no reactive consumer, making it a signal adds tracking overhead for no benefit.

Decision Rule

Does anything REACTIVE read this value?
│
├─ YES (template, host binding, computed, effect)
│   └─▶ Use signal()
│
└─ NO (only used in imperative methods, cleanup, caching)
    └─▶ Use plain property

Use signal() when the value drives the UI

// 1. Template reads it
protected readonly count = signal(0);
// <span>{{ count() }}</span>

// 2. Host binding reads it
protected readonly isActive = signal(false);
// host: { '[class.active]': 'isActive()' }

// 3. A computed() derives from it
protected readonly price = signal(100);
protected readonly quantity = signal(2);
protected readonly total = computed(() => this.price() * this.quantity());

// 4. An effect() should re-run when it changes
protected readonly theme = signal<'light' | 'dark'>('light');
// effect(() => { document.body.setAttribute('data-theme', this.theme()); });

Do NOT use signal() for internal bookkeeping

// 1. One-time initialization flag — no reactive consumer
private _initialized = false;

// 2. Cached DOM measurement — used imperatively only
private _cachedRect: DOMRect;

// 3. Subscription/observer reference — just for cleanup
private _resizeObserver: ResizeObserver | null = null;

// 4. Intermediate calculation variable — method-scoped
private _formatValue(raw: number): string {
    const rounded = Math.round(raw * 100) / 100;
    return `${rounded}%`;
}