PersistentFsmTransition

Defined in: src/fsm/PersistentFSM.ts:93

One entry in the transition table.

Type Parameters

SName

SName extends string

Cmd

Cmd

Event

Event

Data

Data

Properties

event

readonly event: Event | Event[] | ((cmd, data) => Event | Event[])

Defined in: src/fsm/PersistentFSM.ts:115

Event(s) to persist when this transition fires. Three shapes:

• Literal — { kind: 'paid' }: a single event persisted atomically as one journal entry.
• Array — [evtA, evtB]: multiple events persisted in one persistAll call (#66) so they share a logical transaction; applyEvent runs once per event and the post-apply final state is checked against next. An empty array is treated as a no-op transition (no events persisted, no state change) — use a guard instead if “skip on this condition” is the actual intent.
• Function — (cmd, data) => Event | Event[]: lazily evaluated when the transition fires; otherwise behaves exactly like the literal / array forms above.

---

guard?

readonly optional guard?: (cmd, data) => boolean

Defined in: src/fsm/PersistentFSM.ts:133

Optional pre-check — if it returns false, the transition is skipped (no event persisted, no state change). Use for conditional dispatch like “pay only if amount > 0”. Logged at debug.

Parameters

cmd

Cmd

data

Data

Returns

boolean

---

next

readonly next: SName

Defined in: src/fsm/PersistentFSM.ts:126

State name the FSM moves to after every event applies. When event is an array, only the final post-replay state is compared against next — intermediate transitions inside the array don’t have to match. Mainly informational; applyEvent is what actually drives the transition.