Angular Signals State Patterns

Purpose

Use this skill to design or review local state with Angular Signals.

Signals are best for synchronous, local, derived UI state. They simplify stateful components when the state boundary is clear and the problem does not require stream orchestration.

The core rule is simple:

Use Signals for local state and derivations, not for every async workflow.

When to Use

Use this skill when:

• local component state is becoming noisy
• derived state should be explicit
• a feature wants signal-first local state
• computed values would reduce duplicate logic
• effect may be needed for a controlled side effect

Do

Prefer a small local state model:

readonly count = signal(0);
readonly doubled = computed(() => this.count() * 2);

increment(): void {
  this.count.update((value) => value + 1);
}

Use effect for controlled side effects only:

effect(() => {
  console.log("count changed", this.count());
});

Keep Signals near the component or feature boundary unless you have a documented shared-state contract.

Do Not

Avoid replacing HTTP orchestration or cancellation-heavy streams with effect.

Avoid global signal stores for trivial local state.

Avoid using Signals without a clear state ownership boundary.

Avoid mixing multiple state models without a reason.

Review Checklist

• State is local and synchronous enough for Signals.
• Derived state is expressed with computed.
• effect is used only for intentional side effects.
• RxJS remains available for async orchestration.
• The state boundary is explicit.

Expected Output

1. Classify the state lifetime and synchronicity.
2. Recommend signal-based local state where appropriate.
3. Separate derivation from mutation.
4. Flag misuse of effect for orchestration.
5. Explain when RxJS remains the better fit.