-
04655f0: The WebSocket Dart, JavaScript, and Python templates now emit a spec-aware runnable example next to the generated client, rendered from shared components instead of being shipped as a hardcoded file.
New components in
@asyncapi/generator-components(all undersrc/components/example/, each throwingunsupportedLanguagefor languages outsidedart | javascript | python):- Imports — the example's import block, derived from the
clientFileNameparameter - Handlers — placeholder message/error handlers; Python renders one
handle_<snake_op_id>per receive operation plus acustom_error_handler, JavaScript and Dart render a fixedmyMessageHandler/myErrorHandlerpair - OpenConnection — the
connect()invocation - Close — the
close()invocation, for use in the example'sfinallyblock - SendInvocations — a bounded iteration loop invoking each send operation in turn, with payloads resolved from
message.examples() - OutgoingProcessor — the outgoing message processor definition, rendered only when the spec has send operations
Template changes shipped through
@asyncapi/generator:- Each client now generates a runnable example file based on your AsyncAPI document, instead of shipping a fixed one.
- A new
exampleFileNameparameter (defaultexample.dart/example.js/example.py) overrides the generated example's filename.
- Imports — the example's import block, derived from the
- 989b027: Release the existing hooks package and pin AsyncAPI workspace dependencies instead of publishing wildcard ranges.
- 5fe91b0: Generated Python and JavaScript WebSocket clients no longer swallow send errors. Failures are now forwarded to the registered error handlers and raised by default, so callers learn when a message fails to send. Pass
raise_send_errors=False(Python) orthrowSendErrors=false(JavaScript) to the constructor to keep a high-throughput producer loop running and rely on the error handlers instead.
- 51bcc7b: Add unified error handling for
@asyncapi/generator-components. A set of error codes was introduced to help template component development, so you can consistently introduce input validation errors.
-
11a1b8d: - Updated Component:
OnMessage(Python) - Added discriminator-based routing logic that automatically dispatches messages to operation-specific handlers before falling back to generic handlers- New Helpers:
getMessageDiscriminatorData- Extracts discriminator key and value from individual messagesgetMessageDiscriminatorsFromOperations- Collects all discriminator metadata from receive operations
- Enhanced Python webSocket client generation with automatic operation-based message routing:
- Generated WebSocket clients now automatically route incoming messages to operation-specific handlers based on message discriminators. Users can register handlers for specific message types without manually parsing or filtering messages.
- When a message arrives, the client checks it against registered discriminators (e.g.,
type: "hello",type: "events_api") - If a match is found, the message is routed to the specific operation handler (e.g.,
onHelloMessage,onEvent) - If no match is found, the message falls back to generic message handlers
- This enables clean separation of message handling logic based on message types
discriminatoris astringfield that you can add to any AsyncAPI Schema. This also means that it is limited to AsyncAPI Schema only, and it won't work with other schema formats, like for example, Avro.The implementation automatically derives discriminator information from your AsyncAPI document:
- Discriminator
keyis extracted from thediscriminatorfield in your AsyncAPI spec - Discriminator
valueis extracted from theconstproperty defined in message schemas
Example AsyncAPI Schema with
discriminatorandconst:schemas: hello: type: object discriminator: type # you specify name of property properties: type: type: string const: hello # you specify the value of the discriminator property that is used for routing description: A hello string confirming WebSocket connection
When defaults aren't available in the AsyncAPI document, users must provide both
discriminator_keyanddiscriminator_valuewhen registering handlers. Providing only one parameter is not supported - you must provide either both or neither.Why this limitation exists: When a receive operation has multiple messages sharing the same discriminator key (e.g., all use
"type"field), we need the specific value (e.g.,"hello","disconnect") to distinguish between them. Without both pieces of information, the routing becomes ambiguous.Example:
# Default case - discriminator info auto-derived from AsyncAPI doc client.register_on_hello_message_handler(my_handler) # Custom case - must provide both key AND value client.register_on_hello_message_handler( my_handler, discriminator_key="message_type", discriminator_value="custom_hello" )
- New Helpers:
- Updated dependencies [11a1b8d]
- @asyncapi/generator-helpers@1.1.0
- c5be81a: Enforce new helpers and components release to use latest versions in generator. Required because of the recent misconfiguration of releases and Trusted Publishing.
- Updated dependencies [c5be81a]
- @asyncapi/generator-helpers@1.0.1
- 715c1d2: Centralize reusable README components for consistent template rendering across languages
-
91735c3: Fix invalid Java method name generation and properly handle multiple WebSocket handlers
- Generate valid Java method names for WebSocket operation handlers with strange identifiers.
- Produce distinct @OnTextMessage handler methods for each send operation and add safe default routing for unrecognized messages.
- Update onClose/onOpen formatting.
-
62d1eda: Introduced new WebSocket client template components in
@asyncapi/generator-components:
- 32c321b: Initial release of
@asyncapi/generator-componentsand@asyncapi/generator-helpersto make them available for@asyncapi/generator