HandlerArgs
Defined in: types.ts:111
The single combined object passed to every handler.
Handlers return a state name to transition, or void to stay put.
This replaces imperative transition() calls — closer to gen_fsm’s
return-based model and symmetrical with string shorthand handlers.
Example
Section titled “Example”Type Parameters
Section titled “Type Parameters”TCtx
The context type. For Fsm this is the config-defined context object. For BehavioralFsm this is the client object itself.
TStateNames
Section titled “TStateNames”TStateNames extends string = string
String literal union of valid state names.
Defaults to string for loose usage; the factory functions narrow this
to the actual state names inferred from the config.
Properties
Section titled “Properties”ctx:
TCtx
Defined in: types.ts:113
The context (Fsm) or client object (BehavioralFsm)
inputName
Section titled “inputName”inputName:
string
Defined in: types.ts:124
The name of the input currently being handled.
Typed as string rather than the inferred input union because:
- Inside a named handler you already know the input name
- In a catch-all (*) handler it could be anything
- Narrowing to the literal per-handler would require complex mapped types for zero practical benefit
Methods
Section titled “Methods”defer()
Section titled “defer()”defer(
opts?):void
Defined in: types.ts:139
Defer the current input for replay after a future transition. Erlang’s selective receive, in JS form.
Parameters
Section titled “Parameters”TStateNames
Returns
Section titled “Returns”void
Example
Section titled “Example”emit()
Section titled “emit()”emit(
eventName,data?):void
Defined in: types.ts:146
Emit a custom event through the FSM’s emitter. Built-in events (transitioning, transitioned, etc.) are emitted automatically by the FSM engine — this is for user-defined events.
Parameters
Section titled “Parameters”eventName
Section titled “eventName”string
unknown
Returns
Section titled “Returns”void