| 109 | * ``` |
| 110 | */ |
| 111 | export interface HandlerArgs<TCtx, TStateNames extends string = string> { |
| 112 | /** The context (Fsm) or client object (BehavioralFsm) */ |
| 113 | ctx: TCtx; |
| 114 | |
| 115 | /** |
| 116 | * The name of the input currently being handled. |
| 117 | * |
| 118 | * Typed as `string` rather than the inferred input union because: |
| 119 | * 1. Inside a named handler you already know the input name |
| 120 | * 2. In a catch-all (*) handler it could be anything |
| 121 | * 3. Narrowing to the literal per-handler would require complex |
| 122 | * mapped types for zero practical benefit |
| 123 | */ |
| 124 | inputName: string; |
| 125 | |
| 126 | /** |
| 127 | * Defer the current input for replay after a future transition. |
| 128 | * Erlang's selective receive, in JS form. |
| 129 | * |
| 130 | * @example |
| 131 | * ```ts |
| 132 | * // Replay on the next transition to any state |
| 133 | * defer(); |
| 134 | * |
| 135 | * // Replay only when entering "yellow" |
| 136 | * defer({ until: "yellow" }); |
| 137 | * ``` |
| 138 | */ |
| 139 | defer(opts?: { until: TStateNames }): void; |
| 140 | |
| 141 | /** |
| 142 | * Emit a custom event through the FSM's emitter. |
| 143 | * Built-in events (transitioning, transitioned, etc.) are emitted |
| 144 | * automatically by the FSM engine — this is for user-defined events. |
| 145 | */ |
| 146 | emit(eventName: string, data?: unknown): void; |
| 147 | } |
| 148 | |
| 149 | // ----------------------------------------------------------------------------- |
| 150 | // Handler function type |
no outgoing calls
no test coverage detected