State: signals and the NgRx Signal Store

W10.1 built the workspace, W10.2 cuts it by domain. This lesson asks where state lives inside a domain: the list of contacts, the selected contact, the filter, the loading state. For that we write a store with NgRx Signal Store in kontakte-data-access, bind it to the feature library, and test it. W9 (signals, HttpClient, tests) and the workspace from W10.1 are assumed.

State of the checks. Run (Node 24.22.3, Nx 24.0.6, Angular 22.2, @ngrx/signals 22.0.1, Vitest 4.1.12, throwaway workspace outside the repository that grew out of W10.1): store, service, component and tests below; nx test kontakte-data-access exit 0 with 6 tests, nx run-many -t lint test build exit 0 for six projects. Read: Fetching ngrx.io gave us only the skeleton of the pages. The statements about signalStore, rxMethod, providedIn, protectedState, setAllEntities and the testing page come from excerpts of the ngrx.io pages that a documentation service delivered (pages "SignalStore", "Entity Management", "Testing"); we did not read the pages themselves in a browser. Open (not read): signalState, signalStoreFeature, withHooks, the events API, stability notes ("Preview" or similar) and what the page says about choosing between a store and a service. Not run: a service with signals in the section "Where state lives" (a sketch only), Redux DevTools and other extensions.

Where state lives

State has a place, and the place determines who may change it and when it disappears.

The rule of this course: as close to the use as possible. A signal in the component is enough as long as only it needs the value. If two need it, it moves into a service. A store pays off when several parts change state that belongs together and rules apply to it (filter and list, loading and error), and a test should check these rules without a UI. A service with signals is the standard way and needs no extra package (sketch, not run):

@Service()
export class AuswahlDienst {
  readonly gewaehlt = signal<number | null>(null);
  waehle(id: number | null): void {
    this.gewaehlt.set(id);
  }
}

Compared with this service, the store brings a form: state, derived values and methods sit in fixed places, and the state cannot be written from outside (see below). Whether a team needs this form is a matter of taste and team size; we did not read NgRx's page on the choice. Server state is something else: The contacts belong to the server, the client holds a copy. resource and httpResource (W9 0202) model exactly that: a request, its result, loading and error. In the store lives what the client decides (filter, selection), and a loaded page that it wants to change and pass on. Having both side by side is not a contradiction; how far to mix httpResource and a store, we have not tried out.