Implement Automatic Routing in JS, Dart websocket clients

[batchu5]

Automatic message routing is currently implemented only in the Python WebSocket template. When messages arrive, Python automatically routes them to the correct operation-specific handler based on message type.

JavaScript and Dart templates do NOT have this feature. Users must manually parse and filter every incoming message.
How about we implement this in Dart and JS?

[batchu5]

@dosu wdyt?

[dosubot]

Automatic Routing in the Python websocket client works by extracting discriminator keys and values from the AsyncAPI document, registering handlers for each receive operation, and dispatching incoming messages to the correct handler based on their type—so users never need to manually parse or filter messages source.

JS and Dart websocket clients currently lack this feature: they just call all registered handlers with the raw message, leaving parsing and routing up to the user source. To implement Automatic Routing, you’d want to extend the generated client classes to store receive-operation metadata (discriminators and handler registry), generate per-operation handler registration methods, and update the message handling logic to parse incoming messages and dispatch them based on discriminator matches—basically mirroring the Python approach source.

The main challenges are adapting the routing logic to JS and Dart’s async/event-driven patterns and making sure the discriminator extraction and handler registration are idiomatic for each language. If you prototype this, the Python template is a solid reference for both design and user-facing API.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[batchu5]

@dosu is it good idea to implement in the js and dart client?

[dosubot]

Yes, it's a good idea to implement automatic routing in the JS and Dart websocket clients. This would bring them in line with the Python client, making the developer experience much better by eliminating the need for users to manually parse and dispatch messages. It would also create consistency across client libraries, which is especially valuable for teams working in multiple languages.

Technically, this would require significant changes: the templates would need to expose receive-operation metadata, store discriminators and handler registries, and replace the current "call every handler with the raw message" logic with a dispatcher that parses messages and routes them to the correct handler based on discriminator matches—just like the Python client does. While this adds complexity to the templates, the benefits in usability and maintainability outweigh the costs, especially for real-world projects with multiple message types and handlers. There are no major blockers, just the need for careful design to fit JS and Dart idioms source.

A good next step would be to draft a design proposal or prototype for one of the clients, get feedback, and iterate from there.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[batchu5]

@Adi-204, please take a look at this!

[shivansh-source]

i think this will need a proposal