In an NgRx SignalStore, how do withState, withComputed and withMethods build the store, and why does the order of features matter?

## Features are functions applied in order In `@ngrx/signals`, a **feature** such as `withState(...)` is a function that takes the store being built and returns an enriched copy. `signalStore(f1, f2, f3)` starts from an empty inner store and applies `f1`, then `f2`, then `f3` inside the generated class's constructor. The result is copied onto the instance: state signals, props (computed signals are props) and methods. Two consequences follow: - A feature's factory sees **only what earlier features added**. The TypeScript types enforce this: `withComputed(({ favouriteIds }) => ...)` placed before `withState({ favouriteIds: [] })` does not compile. - Every factory runs **during construction, in the injection context**, so a factory can call `inject()` (commonly as a default parameter: `withMethods((store, api = inject(SessionsApi)) => ...)`). ## What each core feature receives and adds | Feature | Factory receives | Adds | Can call `patchState`? | |---|---|---|---| | `withState` | nothing (an object, or a factory run in the injection context) | one signal per root slice | not applicable | | `withComputed` | state signals, earlier props and methods | derived signals, as props | **no**: no writable state source | | `withMethods` | state signals, props, methods **and** the writable state source | methods | **yes** | `withComputed` accepts either ready-made `computed()` signals or plain functions, which it wraps in `computed()` for you. It is in fact built on top of `withProps`: its results are props that happen to be signals. ## `patchState` in detail `patchState(store, ...updaters)` is the standard write API for a SignalStore (and for `signalState`). It works like this: 1. It takes the current state as a snapshot, outside any reactive tracking. 2. It applies each argument in order. A **partial object** is merged in; an **updater function** receives the state as it stands after the earlier arguments and returns a partial object. 3. For each resulting slice, it calls `set()` on that slice's signal **only if the reference changed**. A slice you did not mention is untouched. 4. In dev mode, a key that is not in the initial state produces a console warning and is **ignored**; root slices cannot be added after creation. So `patchState(store, { trackFilter: 'web' }, (state) => ({ favouriteIds: [] }))` applies two changes in one call, and the updater already sees `trackFilter` as `'web'`. Named updater functions that return a partial state are a common way to reuse such changes across methods. Because the comparison is by reference, updaters must be **immutable**. Pushing into `favouriteIds` and returning the same array changes nothing observable. A dev-mode freeze that would have thrown on such mutations shipped in the 19.0.0 beta and was reverted in 19.0.1, so nothing warns you. ## Why order matters in practice - **Dependencies point backwards.** Put `withState` first, then `withComputed` that reads it, then `withMethods` that uses both. A method can call a computed signal only if `withComputed` came earlier. - **Hooks see what precedes them.** A `withHooks` placed before `withMethods` cannot call those methods. - **Names are unique.** Adding a member whose name already exists logs `SignalStore members cannot be overridden` in dev mode. Rename rather than shadow. - **Same-feature references.** Inside one `withMethods` factory, `store` does not yet contain the methods you are defining. Either define a local helper in the factory and call it from both methods, or split into two `withMethods` features. The NgRx docs prefer the local helper, which keeps related code in one place. ## Reading state inside a method Inside a method, read the current value of a slice by calling its signal, `store.trackFilter()`, or take a plain snapshot of all slices with `getState(store)`. Both are fine in ordinary methods. Prefer the updater form of `patchState` when the new value depends on the old one: the updater receives the state as it is at the moment of the update, including changes made by earlier arguments in the same call, so the method never works from a value it read too early. ## Pitfalls - Trying to write state from `withComputed`: the factory has no writable source, which is deliberate. Derivations stay pure. - Passing a whole new state to `patchState` out of habit: it is a partial update, so pass only what changes. - Expecting a mutated array to re-render: return a new array. - Injecting a service in the component and passing it into methods: inject it inside the store's factory instead, where the injection context is available.