Signal Store konkret

NgRx Signal Store ist kein Redux. Es ist kein BehaviorSubject-Ersatz. Es ist ein Werkzeug für reaktiven Domänenzustand mit klaren Composables.

Was gut funktioniert

withState + withComputed: Der Kern. Zustand deklarativ definieren, abgeleitete Signale direkt daneben. Kein manuelle Subject-Subscription.

export const TasksStore = signalStore(
  withState({ tasks: [] as Task[], status: 'idle' as LoadingStatus }),
  withComputed(({ tasks }) => ({
    completedTasks: computed(() => tasks().filter((t) => t.status === 'done')),
    overdueCount: computed(() => tasks().filter((t) => t.isOverdue).length),
  })),
);

withMethods: Use-Case-Logik direkt im Store. Kein separates Effects-File, wenn der Effekt simpel ist.

withHooks: Lifecycle ohne ngOnInit in Services. onInit für automatisches Laden, onDestroy für Cleanup.

Was Vorsicht erfordert

Store-Granularität: Zu grobe Stores (ein Store für alles) werden unübersichtlich. Zu feine Stores (ein Store pro Komponente) verlieren den Sinn.

Derived State: computed() ist lazy und gecacht. Aber verschachtelte computed() über viele Ebenen sind schwer zu debuggen.

Mutation vs. Projection: patchState ist direkte Mutation. Für komplexe Zustandsübergänge ist eine semantische Methode klarer als direktes patchState in Komponenten.

Lessons Learned

• Store besitzt Zustand, Facade exponiert ihn kontrolliert
• withMethods trägt die Applikationslogik
• Komponenten bekommen nur Signals — keine Store-Interna
• Testing: Store ohne Komponente testbar, da kein DOM nötig