eHow to efficiently manage state in Angular 16 using Signals and NgRx?

[learningjsfor6m-ui]

Body

I’m working on an enterprise Angular 16 application and exploring the new Signals API alongside NgRx for state management.

• What are the recommended best practices for combining Signals with NgRx selectors?
• Should Signals replace NgRx in certain scenarios, or are they better used together?
• Are there performance considerations when migrating existing NgRx-based apps to Signals?
  Any code examples or migration strategies would be greatly appreciated.

Guidelines

• I have read and understood this category's guidelines before making this post.

[amirsuh]

Angular 16 signals with NgRx selectors best practices

• Keep responsibilities clear: Use NgRx for global, shared, and long‑lived state (entities, caching, cross‑feature coordination, effects, devtools), and use Signals for local UI state, ephemeral view logic, and fine‑grained derivations inside components.
• Prefer signal selectors where available: Wrap NgRx selectors in signal form to avoid manual subscription management and to leverage Angular’s fine‑grained reactivity.
• Co-locate derivations in the view: Derive presentation‑specific data with computed() in the component, even when the source is from NgRx. Keep domain derivations (e.g., complex aggregates) in feature selectors.
• Unidirectional data flow stays the same: Dispatch actions to change global state; don’t mutate NgRx state via Signals. Signals read/derive, actions write.
• Encapsulate with SignalStore for feature modules: For mid-size features, NgRx’s SignalStore reduces boilerplate while preserving predictability and testability.

When to use signals vs. NgRx

• Use Signals alone when:
  Local UI state (form control visibility, toggles), component-scoped derivations, lightweight pages without cross-feature coordination, or zoneless/fine-grained performance tuning.
• Use NgRx alone when:
  Complex side effects, server synchronization, entity collections with caching, undo/redo, time-travel/debugging, or auditability across teams.
• Use both together when:
  Enterprise features where global consistency matters but the view needs fast, granular reactivity, and you want clean component code (NgRx for source of truth; Signals for UI derivations and ergonomics).

Performance considerations in migrations

• Reduced change detection churn: Signals enable precise updates, which can cut unnecessary component re-renders compared to broad observable chains.
• Less subscription overhead: Signal selectors avoid manual subscribe/unsubscribe patterns and reduce memory leaks and microtask overhead.
• Avoid double work: Convert a selector to a signal once per component and derive everything from that signal to prevent redundant recomputation.
• Memoize with computed(): Heavy computations should be encapsulated in computed() signals; they run only when dependencies change.
• Effects still matter: Keep NgRx Effects for IO and orchestration; Signals don’t replace deterministic side-effect handling in enterprise flows.

Code examples
Wrapping NgRx selectors with signals in a component
import { Component, computed, signal } from '@angular/core';
import { Store } from '@ngrx/store';
// If using NgRx's signal integration:
// import { selectSignal } from '@ngrx/store'; // Adjust import based on your NgRx version
import { toSignal } from '@angular/core/rxjs-interop';
import { selectTodos, selectLoading } from '../state/todo.selectors';

@component({
selector: 'app-todo-list',
template: <section *ngIf="!loading()"> <h3>Completed: {{ completedCount() }}</h3> <ul> <li *ngFor="let t of todos()">{{ t.title }}</li> </ul> </section>,
})
export class TodoListComponent {
// Option A: Using toSignal for existing observable selectors
todos = toSignal(this.store.select(selectTodos), { initialValue: [] });
loading = toSignal(this.store.select(selectLoading), { initialValue: false });

// Option B: If your NgRx version supports signal selectors
// todos = this.store.selectSignal(selectTodos);
// loading = this.store.selectSignal(selectLoading);

completedCount = computed(() => this.todos().filter(t => t.done).length);

constructor(private store: Store) {}
}


Combining local UI signals with global NgRx actions
import { Component, signal } from '@angular/core';
import { Store } from '@ngrx/store';
import { applyFilter } from '../state/todo.actions';

@component({
selector: 'app-todo-filters',
template: <button (click)="setShowCompleted(true)">Show Completed</button> <button (click)="setShowCompleted(false)">Show All</button>,
})
export class TodoFiltersComponent {
showCompleted = signal(false);

constructor(private store: Store) {}

setShowCompleted(val: boolean) {
this.showCompleted.set(val);
this.store.dispatch(applyFilter({ completedOnly: val }));
}
}

Using NgRx SignalStore to reduce boilerplate in a feature
import { signalStore, withState, withSelectors, withMethods } from '@ngrx/signals';
import { computed } from '@angular/core';

type Todo = { id: string; title: string; done: boolean };

export const TodosStore = signalStore(
withState({ todos: [] as Todo[], loading: false }),

withSelectors(({ todos, loading }) => ({
completed: computed(() => todos().filter(t => t.done)),
count: computed(() => todos().length),
isLoading: loading,
})),

withMethods((store) => ({
setTodos(t: Todo[]) { store.patch({ todos: t, loading: false }); },
toggle(id: string) {
const next = store.todos().map(t => t.id === id ? { ...t, done: !t.done } : t);
store.patch({ todos: next });
},
startLoading() { store.patch({ loading: true }); }
}))
);

// Usage in a component
// const todos = inject(TodosStore);
// todos.startLoading();



Migration strategies

• Inventory your state:
  Classify each slice as global (shared, persisted, audited) vs. local (UI, ephemeral). Keep global in NgRx; migrate local to Signals.
• Wrap selectors progressively:
  Convert frequently used selectors to signals in components (store.selectSignal(...) or toSignal(...)). Replace derived observable pipelines with computed() where practical.
• Move view-only derivations to components:
  Shift formatting, filtering, and counts into computed() signals near the template. Keep domain-level selectors intact.
• Adopt SignalStore for feature modules:
  Refactor mid-size features to SignalStore to trim boilerplate while preserving testable methods and explicit state transitions.
• Maintain effects and actions:
  Retain NgRx actions/effects for IO and cross-cutting concerns. Signals should not replace deterministic effect handling.
• Measure before and after:
  Track change detection cycles and interaction latency. Optimize hot paths with signals; avoid premature rewrites of stable NgRx flows.
• Phase rollout:
  Start with non-critical components, document patterns, and establish a checklist for new features to choose Signals, NgRx, or both.