Skip to main content
Event patterns are shared across both APIs:
  • bus.on(pattern, handler) for subscriptions
  • bus.find(pattern, ...) for history/future lookup
Both accept the same pattern forms:
  • event class
  • string event type name
  • '*' wildcard (match everything)
Go and Rust use string event type names for low-level registration/lookup, plus typed payload/event APIs (bus.On(...) in Go, EventSpec/BaseEvent in Rust) when you want payload/result validation.

Supported pattern forms

.on(...) and .find(...) use the same pattern model

Use whichever operation you need, with the same pattern key:
  • subscribe: bus.on(UserActionEvent, handler)
  • find by class: await bus.find(UserActionEvent)
  • find by string: await bus.find('UserActionEvent')
  • wildcard subscribe/find: bus.on('*', ...), await bus.find('*', ...)

Examples

Why event classes are preferred for typing

Event classes preserve the most useful static typing:
  • handler input shape is specific (payload fields are known)
  • event result typing stays aligned with event_result_type / generic result type
  • .find(EventClass) returns the specific event type
String keys and '*' are intentionally looser:
  • Python: treat as BaseEvent[Any]
  • TypeScript: typed as base BaseEvent/unknown-oriented handler return checks
  • Rust: typed handlers use bus.on(MyEvent, ...); raw string/wildcard registration is reserved for low-level forwarding internals.
  • Go: typed handlers use bus.On(...); string/wildcard handlers use bus.OnEventName(...) and receive *BaseEvent
Use string/wildcard patterns when you need dynamic behavior. Use classes whenever you want strict payload/result type hints through handlers and lookups.