Signal Store Anatomy

## What `signalStore()` returns A **SignalStore** comes from the `@ngrx/signals` package. You do not write a class for it; you call `signalStore()` with a list of **features**, and it returns a class for you. Angular can inject that class like any service. Each time Angular creates an instance, the constructor runs the features in order, and each feature adds members to the instance. For a conference schedule planner, the store might hold the list of `sessions`, the attendee's `favouriteIds` and a `trackFilter`. Components inject the store, read its signals in templates and call its methods from event handlers. ## The building blocks | Feature | What it adds | Schedule-planner example | |---|---|---| | `withState` | one signal per root state slice | `sessions`, `favouriteIds`, `trackFilter` | | `withComputed` | derived, read-only signals | `visibleSessions` filtered by track | | `withMethods` | functions that read state and call `patchState` | `setTrack()`, `toggleFavourite()` | | `withHooks` | `onInit` / `onDestroy` for the store instance | load the schedule when the store is created | Other features (`withProps`, `withLinkedState` and reusable custom features) extend the same pattern, but these four are what most stores are made of. ## Reading and writing state - **Reading.** Every root slice is a signal: `store.trackFilter()` in a template or a `computed`. When a slice holds an **object literal**, the store wraps it in a `DeepSignal`, so `store.filter()` returns the whole object and `store.filter.day()` is its own signal, created lazily on first access. Arrays and primitives stay plain signals. - **Writing.** The exposed signals are typed as read-only `Signal`s, with no `set()` or `update()`. State changes go through `patchState(store, partialState)` or `patchState(store, (state) => partialState)`, which updates only the slices you name. - **Snapshot.** `getState(store)` returns a plain object of the current state; inside a reactive context such as `computed` or Angular's `effect()` it also tracks every slice. - **Protection.** By default the store is created with **protected state**. The type a component sees exposes state read-only, so `patchState(this.store, ...)` in a component does not compile. Writes belong in methods defined by `withMethods`, which names every change the store allows. ## How it compares with a service that holds signals A plain Angular service with `private readonly _favourites = signal<string[]>([])` and a public `favourites = this._favourites.asReadonly()` can do the same job. The difference is who enforces the shape. | Concern | Hand-written signal service | NgRx SignalStore | |---|---|---| | Read-only public state | you remember `asReadonly()` per field | protected state by default | | Nested object fields | one signal per object, or manual splitting | `DeepSignal` per object literal slice | | Partial updates | a `set`/`update` call per signal | one `patchState` call with several slices | | Lifecycle logic | constructor plus `DestroyRef` by hand | `withHooks` with `onInit` / `onDestroy` | | Reuse across stores | inheritance or copy-paste | features composed into several stores | For a service with two fields the difference is small. For a team with many feature stores, the fixed structure means every store reads the same way. ## Where the store is provided `signalStore()` registers the class with **no** injector by default. You either: 1. pass a config object first, `signalStore({ providedIn: 'root' }, withState(...))`, for one instance shared by the whole app; or 2. list the store in a component's or route's `providers` array, which gives that component subtree its own instance. In the planner, the schedule store sits at root, while each session-detail component provides a small store of its own for the open session. ## Common misunderstandings - A SignalStore is **not** a module-level object you import and mutate; it is a class that Angular instantiates. - A plain SignalStore has **no actions or reducers**; methods change state directly through `patchState`. The global NgRx Store is a separate model, and the optional Events plugin is what adds a Flux-style layer to SignalStore. - Its state signals are typed **read-only** from outside; a `set()` call on them does not compile. - To type a variable or constructor parameter as the store, use `InstanceType<typeof ScheduleStore>`, because `ScheduleStore` itself is a class value, not a type. ## Functional definition versus a class Because `signalStore()` returns a class, a team can also write `export class ScheduleStore extends signalStore(...) { ... }` and add members in the class body. The NgRx docs allow this but recommend the functional style shown above: every member then comes from a feature, the order of features documents the dependencies, and protected state keeps working without extra configuration. Mixing both styles in one codebase makes stores harder to compare, so pick one and keep it.