Signal Store Events - lösningen för stora Angular-applikationer
Introduktion
Angulars nya Signals-system (infört i Angular v16) har förenklat hur vi hanterar reaktivt tillstånd (state). Med NgRx SignalStore kan utvecklare skapa lokala “stores” som utnyttjar signals istället för traditionella RxJS-strömmar. Som standard uppdateras tillstånd i SignalStore genom att anropa metoder direkt på store-objektet. Nu introducerar NgRx ett Events-lager för SignalStore – ett frivilligt, Flux-inspirerat mönster som påminner om Redux. I denna artikel går vi igenom vad Signal Store Events är, hur de kan användas för ett Redux-liknande unidirektionellt dataflöde, och hur det skiljer sig från den metodbaserade hanteringen. Vi visar konkreta exempel på hur man definierar events (actions), reducerar state baserat på events, samt strukturerar en SignalStore enligt Redux-mönstret. Vi diskuterar också när detta mönster är lämpligt och vilka för- och nackdelar det har jämfört med andra sätt att hantera state med signals.

Vad är Signal Store Events?
Signal Store Events är ett event-driven tillägg till NgRx SignalStore som inför Redux-liknande designmönster i signalbaserad state-hantering. I ett klassiskt Redux/Flux-arkitektur flödar data ensidigt: View → Action → Reducer → Store → View. Med SignalStore Events får vi en lättviktig variant av samma cykel, fast inbäddad i Angulars signals-system. Komponenter dispatchar events (motsvarande Redux “actions”), store-objektet reagerar på events via reducers (för att uppdatera tillståndet) och effects (för att hantera asynkrona sidoeffekter), och tillståndet lagras som signals som automatiskt uppdaterar vyn. Allt detta sker lokalt inom en SignalStore – ingen global store krävs – vilket ger struktur och prediktibilitet utan att införa all boilerplate från ett fullskaligt NgRx Store.
Varför events? Det metodbaserade sättet (där komponenter anropar metoder på en store) fungerar utmärkt för enkla, isolerade tillstånd. Men i mer komplexa applikationer kan ett event-drivet angreppssätt ge bättre lös koppling och tydligare dataflöde. Komponenter behöver inte känna till några specifika metoder i en store, utan endast dispatcha ett event – vad som hände separeras från hur state ska förändras. Detta möjliggör att flera olika stores eller delar av applikationen kan reagera på samma event, samt underlättar debugging (t.ex. via Redux DevTools) eftersom varje state-förändring kan spåras via en sekvens av events.

Definiera events (actions) i SignalStore
För att införa event-mönstret börjar man med att definiera de events (actions) som ens funktionalitet behöver. I NgRx SignalStore görs detta vanligtvis genom eventGroup, där man grupperar relaterade events med ett gemensamt ursprung (källa). Varje event ges ett namn och en payload-typ som beskriver eventets data. Exempel:

import { eventGroup, type } from '@ngrx/signals/events';

export const counterEvents = eventGroup({
  source: 'Counter',  // valfri beskrivning av var eventen kommer från
  events: {
    increment: type<void>(),                   // ett event utan payload
    decrement: type<void>(),
    loadCount: type<{ id: number }>(),         // event för att ladda data (med payload)
    loadCountSuccess: type<{ value: number }>(), // event vid lyckad asynkron hämtning
    loadCountError: type<{ error: string }>()    // event vid fel
  }
});
I koden ovan definierar vi fem events för en räknare: increment och decrement (ingen ytterligare data behövs), loadCount (för att t.ex. ladda ett räknevärde från en server med ett ID som payload), samt loadCountSuccess och loadCountError för resultatet av den asynkrona hämtningen. Alla dessa events delar source: 'Counter' vilket underlättar spårning av varifrån de kommer vid debugging. Att definiera events på detta sätt liknar hur man i Redux skulle definiera action-typer och payloads.

Reducers: hantera state-förändringar med events
Med våra events definierade kan vi skapa själva store:en och ange hur tillståndet ska uppdateras när ett event inträffar. Istället för att direkt ändra state i en metod, deklarerar vi reducers som lyssnar på specifika events. SignalStore erbjuder funktionen withReducer tillsammans med hjälpfunktionen on(event, handler) för detta ändamål. En reducer-handler tar emot eventets data (payload) och returnerar antingen en partiell ny state eller en updater-funktion som beräknar ny state baserat på det gamla.
Låt oss skapa en CounterStore som hanterar räknarexemplet ovan:

import { signalStore, withState } from '@ngrx/signals';
import { on, withReducer } from '@ngrx/signals/events';
import { counterEvents } from './counter.events';  // filen där events definieras

interface CounterState {
  count: number;
  loading: boolean;
  error: string;
}

// Initialt tillstånd
const initialState: CounterState = { count: 0, loading: false, error: '' };

export const CounterStore = signalStore(
  { providedIn: 'root' },           // gör store:en tillgänglig globalt (singleton)
  withState(initialState),          // lägg till state i store:en
  withReducer(
    // När 'loadCount' dispatchas: sätt loading true (börja ladda) och rensa ev. fel
    on(counterEvents.loadCount, ({ payload }) => ({
      loading: true,
      error: ''
    })),

// Vid lyckad hämtning: uppdatera count med värdet och stäng av loading
    on(counterEvents.loadCountSuccess, ({ payload }) => ({
      count: payload.value,
      loading: false
    })),

// Vid fel vid hämtning: spara felmeddelande och stäng av loading
    on(counterEvents.loadCountError, ({ payload }) => ({
      error: payload.error,
      loading: false
    })),

// Hantera lokala increment/decrement events
    on(counterEvents.increment, () => 
      (state) => ({ count: state.count + 1 })  // returnerar en updater-funktion som ökar nuvarande count
    ),
    on(counterEvents.decrement, () => 
      (state) => ({ count: state.count - 1 })
    )
  )
);
I ovanstående kod definierar withReducer flera on(...) cases:
on(counterEvents.loadCount, ...) – när ett loadCount-event sker, returnerar vi ett objekt som patchas in i state: vi sätter loading: true (för att indikera laddning pågår) och rensar eventuell error. (Här behövde vi inte titta på tidigare state alls, så vi returnerar bara ett nytt partial state direkt.)
on(counterEvents.loadCountSuccess, ...) och on(...Error, ...) – vi uppdaterar state baserat på payload från resultatet: antingen sätter vi det nya värdet i count och stänger av loading, eller sätter ett felmeddelande och stänger av loading.
on(counterEvents.increment, ...) och on(counterEvents.decrement, ...) – dessa events ska öka eller minska count. För att beräkna nya värdet behöver vi det gamla, därför returnerar vi en funktion (state) => {...} som tar nuvarande state och returnerar ett uppdaterat partial state (ökat eller minskat count). SignalStore anropar denna funktion med det aktuella state-värdet och patchar in resultatet.
Notera att reducers i SignalStore kan returnera antingen en partial state (objekt med ändrade fält) eller en funktion (en updater som tar state som argument). Båda sätten ovan är illustrerade. Under huven ser SignalStore till att det befintliga state-objektet inte muteras utan att ett nytt immutabelt objekt skapas (vilket upprätthåller Redux-principen om oföränderligt tillstånd). Med reducers definierade på detta sätt är all logik för hur state förändras centraliserad och kopplad till tydliga event, vilket liknar Redux-reducers fast inom en lokal store.

Effekter: asynkrona operationer med events
För synkrona state-uppdateringar räcker reducers, men ofta behöver vi även hantera asynkrona operationer (t.ex. HTTP-anrop). I Redux sker detta via effects (sidoeffekter) som reagerar på actions, gör en asynkron handling och dispatchar nya actions när operationen är klar. SignalStore Events erbjuder en liknande mekanism via funktionen withEffects. En effect i detta sammanhang är en RxJS-ström som lyssnar på inkommande events och mappar dem till utgående events.
I vår CounterStore vill vi att när loadCount-eventet triggas (t.ex. för att ladda ett räknevärde från backend), ska en effect anropa en service och sedan dispatcha antingen loadCountSuccess eller loadCountError. Så här kan vi lägga till en effect i store:en:

import { inject } from '@angular/core';
import { Events, withEffects } from '@ngrx/signals/events';
import { switchMap, map, catchError, of } from 'rxjs';

export const CounterStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withReducer(
    /* ... reducers som i föregående kod ... */
  ),
  // withProps kan användas för att injicera tjänster i store:en
  withProps(() => ({
    _apiService: inject(ApiService),    // antag att ApiService har metoden fetchCount(id)
    _events: inject(Events)            // Events-servicen gör att vi kan lyssna på event-strömmen
  })),
  withEffects((store) => ({
    // Effect som lyssnar på loadCount-eventet
    loadCount$: store._events.on(counterEvents.loadCount).pipe(
      switchMap(({ payload }) => 
        store._apiService.fetchCount(payload.id).pipe(
          map(value => counterEvents.loadCountSuccess({ value })),      // vid svar, emitta success-event
          catchError(err => of(counterEvents.loadCountError({ error: err.message || 'Fel vid hämtning' }))) // vid fel, emitta error-event
        )
      )
    )
  }))
);
I koden ovan:
Med withProps injicerar vi nödvändiga beroenden: _apiService (en hypotetisk tjänst för API-anrop) och _events (NgRx Events-servicen som ger oss tillgång till den gemensamma event-bussen).
withEffects tar en funktion där vi definierar ett objekt med en eller flera effekter. Varje egenskap (här loadCount$) är en Observable. Vi använder store._events.on(...) för att filtrera inkommmande events – i detta fall tar vi bara emot events av typen loadCount.
När counterEvents.loadCount dispatchas, fångar vår effect upp det och med switchMap gör vi ett asynkront anrop store._apiService.fetchCount(payload.id).
Svaret från servicen mappas (map) om till ett nytt event counterEvents.loadCountSuccess med det hämtade värdet. Om ett fel inträffar fångar vi det med catchError och returnerar ett loadCountError-event (vi använder of(...) för att omvandla det till en Observable-ström).
Dessa utgående events (loadCountSuccess eller loadCountError) skickas sedan automatiskt tillbaka in i SignalStores event-system. Vår reducer (som vi definierade tidigare) lyssnar redan på dessa events och uppdaterar state när de inträffar. På så vis hålls cykeln igång: komponenten dispatchar loadCount → effect gör API-anrop → effect dispatchar success/error-event → reducer uppdaterar state → vy uppdateras via signals.
En viktig detalj är att effekterna i SignalStore Events använder RxJS under huven (de ska inte blandas ihop med Angular Signals effect-funktion, trots samma namn). Detta betyder att hantering av prenumerationer och fel följer RxJS regler – vi måste t.ex. se till att catchError används, annars kan strömmen dö vid ett ohanterat fel. I vårt exempel returnerar vi ett error-event så att flödet fortsätter även vid fel.

Att dispatcha events från komponenter
Nu när vi har definierat events, reducers och effekter i vår store, behöver vi veta hur komponenter faktiskt utlöser dessa events. Istället för att anropa en metod på store:en (som i metodbaserad hantering) kommer komponenten att dispatcha ett event. NgRx Signals tillhandahåller en Dispatcher-service för detta ändamål.
I Angular kan vi injicera Dispatcher-servicen och använda dess dispatch()-metod. Exempel på användning i en komponent:

import { Component } from '@angular/core';
import { Dispatcher } from '@ngrx/signals/events';
import { counterEvents } from './counter.events';

@Component({ /*...*/ })
export class CounterComponent {
  constructor(private dispatcher: Dispatcher) {}

onIncrement() {
    this.dispatcher.dispatch(counterEvents.increment());
  }

onRefreshCount(id: number) {
    // Dispatcha event för att ladda nytt värde (effekt kommer hantera API-anropet)
    this.dispatcher.dispatch(counterEvents.loadCount({ id }));
  }
}
Här injicerar vi Dispatcher i konstruktorn. När användaren klickar på en knapp som anropar onIncrement(), dispatchar vi helt enkelt counterEvents.increment(). Detta event fångas omedelbart upp av vår stores reducer (on(counterEvents.increment, ...)) som uppdaterar count. Om vi istället anropar onRefreshCount(42), dispatchas loadCount-eventet med ett ID; vår effect lyssnar på detta event, gör API-anropet och genererar success/error events som i sin tur uppdaterar state via reducer. Notera att komponenten inte behöver känna till hur dessa events hanteras i store:en – den bara skickar iväg en “intention” (increment, ladda data etc.). Detta är en viktig skillnad från metodbaserad användning där komponenten direkt anropar en specifik metod (t.ex. counterStore.loadCount(42)).
För att konsumera state i en komponent använder vi SignalStores exponerade signals. Om CounterStore exempelvis exponerar sin count som en signal eller via en selector (t.ex. withComputed), kan komponenten injicera store:en och läsa av store.count() som vanligt. Skillnaden med event-mönstret ligger främst i hur vi triggar förändringar.

Jämförelse: event-baserad vs metodbaserad state-hantering
Det finns viktiga skillnader mellan att använda det nya event-baserade mönstret och den traditionella metodbaserade hanteringen i SignalStore:
Anrop från komponent:
 – Metodbaserat: Komponenter anropar direkt en metod på store-instansen, t.ex. counterStore.increment().
 – Eventbaserat: Komponenter känner inte till några store-metoder, de dispatchar istället ett event via Dispatcher.dispatch(counterEvents.increment()). Store:en som lyssnar på eventet hanterar det. Detta innebär lösare koppling – komponenten behöver bara veta om eventtypen, inte vilken store eller hur den hanteras.
State-uppdateringens plats:
 – Metodbaserat: State ändras inuti store-metoder med hjälp av t.ex. patchState eller andra updaters. Logiken för att uppdatera tillstånd är kapslad i imperativa kommandometoder (ofta definierade via withMethods i signalStore).
 – Eventbaserat: State ändras i reducer-funktioner (withReducer + on(...)). Dessa liknar Redux-reducers och separerar vad som hände (eventet) från hur state ändras (reducerlogiken). Kodstrukturen blir mer deklarativ och event-driven.
SidEffects (asynkron logik):
 – Metodbaserat: Asynkrona anrop hanteras ofta inuti metoder, ibland med hjälp av rxMethod (en utility för att integrera RxJS i SignalStore-metoder). T.ex. en metod loadData() skulle inuti sig anropa en service och uppdatera state när svaret kommer, ev. via en prenumeration.
 – Eventbaserat: Asynkron logik läggs i withEffects som lyssnar på events. Effekterna är separata från reducers och returnerar nya events vid resultat. Detta ger en tydlig åtskillnad mellan utlösande event, sidoeffektens logik, och state-uppdateringen via reducer.
Koppling och återanvändning:
 – Metodbaserat: Tightare koppling mellan komponent och store – komponenten måste veta vilken store den pratar med och anropa rätt metod. Mönstret passar bra när en store främst konsumeras av en enda komponent/feature.
 – Eventbaserat: Lösare koppling – flera olika delar av appen (eller flera stores) kan dispatcha eller lyssna på samma events. Det möjliggör enklare cross-store communication, där t.ex. en uppdatering i en detail-store kan trigga en list-store att uppdatera sin data (genom att dispatcha ett event som list-storens reducer hanterar). Arkitekturen blir mer modulär och skalbar vid större applikationer.
Boilerplate och komplexitet:
 – Metodbaserat: Generellt mindre boilerplate – man skriver bara de metoder som behövs, och kan direkt uppdatera state. Koden kan vara enklare att följa för småskaliga flöden eftersom allt händer i en metod.
 – Eventbaserat: Kräver lite mer kodstruktur – events måste definieras, reducers och ev. effekter skrivs separat. För enkla fall kan detta kännas onödigt omständligt. Dock ger det strukturen fördelar vid komplexitet, som vi ser nedan.
Sammanfattningsvis kan man säga att metodbaserad SignalStore är idealisk för lokalt tillstånd i enskilda komponenter eller features med begränsad komplexitet, där komponenten och store:en är tätt relaterade. Eventbaserad SignalStore glänser i mer omfattande scenarion med många interaktioner, flera konsumenter av samma state eller krav på mer formellt, förutsägbart dataflöde.

När passar Redux-mönstret med SignalStore Events?
Det Redux-liknande event-mönstret är inte obligatoriskt för alla situationer, men det är särskilt lämpligt i följande fall:
Större applikationer med komplex state: Om din applikation har mycket delat state och många komponenter som behöver koordinera uppdateringar, ger events ett tydligare mönster. Det blir lättare att följa vad som händer eftersom varje förändring loggas som ett event med en tydlig typ.
Flera stores som samverkar: Ibland behöver olika delar av appen reagera på samma händelse. Med events kan du dispatcha en gång och låta flera stores (eller olika delar av samma store) lyssna och reagera. Till exempel kan ett “userLoggedOut”-event få alla relevanta stores att nollställa sitt tillstånd utan att de direkt känner till varandra.
Önskan om bättre debugging och verktyg: Event-mönstret liknar Redux tillräckligt för att verktyg som Redux DevTools ska kunna användas. Med en enkel integration (withDevtools från ett community-paket eller liknande) kan man se historiken av dispatchade events och state-ändringar över tid, vilket underlättar felsökning. I metodbaserad hantering är det svårare att få en överblick av sekvensen av state-förändringar, eftersom de inte är namngivna på samma sätt som events.
Team som är vana vid Redux/NgRx: Om ditt team har erfarenhet av Redux-mönstret (t.ex. traditionell NgRx Store) kan SignalStore Events kännas bekant och ge en trygg struktur, samtidigt som ni drar nytta av signals prestanda och enklare API. Det kan vara en mjukare inlärningskurva för att börja använda signals utan att släppa taget om unidirektionellt flöde och actions.

Å andra sidan finns det situationer där event-lagret inte är nödvändigt. För enkla use-cases, som en komponent med lite lokalt UI-state (en togglad meny, en enkel räknare etc.), är det antagligen överkurs att definiera fulla event/reducer-cykler – där räcker det gott att använda en SignalStore med metoder, eller till och med direkt använda signal och effect i komponenten själv. Det fina med NgRx SignalStore är att du kan välja: använd metod-mönstret för enkelhet när det passar, och införa event-mönstret endast för de delar av applikationen som har mest nytta av det.

Fördelar och nackdelar med SignalStore Events
Fördelar:
Prediktibelt och spårbart flöde: Varje förändring sker genom ett event → reducer, vilket liknar Redux. Det blir lätt att resonera om appens tillstånd och följa flödet, särskilt med verktyg som loggar events.
Lös koppling & skalbarhet: Komponenter behöver inte känna till detaljer om state-hanteringen, de dispatchar bara events. Flera delar av appen kan delta i flödet utan hårda kopplingar, vilket är bra för större appar och teamutveckling.
Bättre organisering av kod: Separering av concerns – events definieras centralt, uppdateringslogik i reducers, asynkrona anrop i effects. Detta kan leda till renare, mer testbar kod. Reducers och effects är i stort sett rena funktioner/strömmar som är enklare att enhetstesta än komplexa metoder med både logik och anrop.
Redux DevTools-stöd: Möjlighet att använda Redux DevTools för time-travel debugging och inspektion av state-historik. Genom att koppla in devtools kan utvecklare se sekvensen av events och tillstånd direkt i webbläsarens utvecklarverktyg, vilket underlättar felsökning enormt i komplexa scenarion.
Återanvändbara patterns: Event-/reducer-mönstret är välkänt. Många utvecklare har förståelse för actions, reducers, effects sedan tidigare (NgRx, Redux, etc.), så kunskap och best practices kan återanvändas i Signals-konteksten.
Nackdelar:
Mer boilerplate vid enkla fall: För småskaliga tillståndshanteringsproblem kan events vara överdrivet. Att skriva events, reducers och effects innebär fler filer/rader kod jämfört med att bara använda en signal eller en enkel store-metod som uppdaterar state. Det kan kännas tungrott om mönstret inte verkligen behövs.
Ökad komplexitet: Ett eventdrivet mönster introducerar fler abstraktioner (Dispatcher, event definitions, etc.) som utvecklaren måste förstå. För utvecklare ovana vid Redux kan det initialt vara förvirrande jämfört med att bara kalla en metod och ändra en signal direkt.
Inte nödvändigt för allt: Alla stores/drivor av state behöver inte en full Flux-behandling. Om mönstret tillämpas slentrianmässigt kan man hamna i onödig komplexitet där en enklare lösning hade räckt. Det gäller att utvärdera när den extra strukturen ger mervärde.
Experimentell status: I skrivande stund (Angular/Ngrx v20) är Events-lagret för SignalStore en relativt ny och “experimentell” funktion. API:et kan komma att förändras något över tid, och den officiella stödet (t.ex. devtools-integration) håller på att mogna. Det innebär att dokumentation och community-erfarenheter inte är lika omfattande ännu som för mer etablerade mönster.

Slutsats
SignalStore Events ger Angular-utvecklare möjligheten att införa beprövade Redux-principer i den nya signal-världen. Genom att dispatcha events och låta reducers hantera state-förändringar skapas ett tydligt, enhetligt flöde som kan göra komplexa applikationer enklare att förstå och underhålla. Vi har sett hur man kan definiera events, strukturera en SignalStore med state, reducers och effects, samt hur detta mönster jämförs med den enklare metodbaserade hanteringen. I praktiken bör man använda event-mönstret där det ger tydliga fördelar – framför allt vid mer omfattande state-hantering – medan enklare scenarion kan fortsätta dra nytta av signals enkelhet utan extra lager.
För en Angular-utvecklare som redan är bekant med SignalStore erbjuder Events-lagret ett kraftfullt verktyg för att bygga skalbar och förutsägbar state-hantering med minimal boilerplate. Det förenar det bästa av två världar: Redux arkitekturens klarhet och Angular Signals reaktiva enkelhet. Med rätt avvägning mellan metodbaserat och eventbaserat tillvägagångssätt kan man optimera både utvecklarproduktivitet och applikationens arkitektur. Lycka till med att utforska SignalStore Events i dina Angular-projekt!