Andes.Extensions.AI: Skill for Claude Code

NgRx Signal Store

Production guidance for @ngrx/signals. Pinned to 21.1.1 (sources.json); refresh with /ngrx-signals-sync.

This is not classic NgRx. There are no actions, reducers, effects, or dispatch unless you deliberately opt into the Events plugin. If you catch yourself reaching for createAction or createReducer, you are in the wrong library.

Mental model

A store is a composition of features, evaluated left to right. Each feature sees everything the features before it added, and contributes state, computed signals, props, or methods to what follows. signalStore(...) returns an injectable service.

State is a deeply-signalized tree: every object-literal member becomes a DeepSignal you can drill into (store.filter.query()), while primitives stay plain signals. State is protected by default — only the store's own methods may write to it, via patchState.

Production defaults

• Leave protectedState on. It is the default, and it is what stops components from reaching in and mutating state. signalStore({ protectedState: false }, …) exists, but it trades away the one guarantee that keeps data flow one-directional. Tests do not need it — use unprotected() from @ngrx/signals/testing instead.
• Choose the lifetime deliberately. signalStore({ providedIn: 'root' }, …) gives one app-wide instance. Listing the store in a component's or route's providers: [] ties its lifetime to that component, which is what you want for local, disposable state.
• Inject via default parameters — withMethods((store, books = inject(BooksService)) => ({ … })). It keeps the feature a plain function and stays testable.
• Write state updaters as standalone functions returning PartialStateUpdater<T>, not as store methods. They tree-shake, they test in isolation, and they compose in a single call: patchState(store, setAllEntities(books), setFulfilled()).
• Prefix private members with _. _totals, _load() — inaccessible from outside the store, so the public surface stays intentional.
• One store per entity type. Multiple collections in one store are supported, but the docs recommend dedicated stores, and it keeps each store's methods coherent.
• Never mutate in an updater. patchState updaters must return new objects; mutating in place silently breaks change propagation.