Efficiently handling WebSockets
- Dominant language
- No language data
- Stars
- 226
- Forks
- 42
- PR merge metrics
- No merged PRs in 30d
Description
In Dojo 1.x, WebSockets are mostly an afterthought in how we approach APIs, with most examples using traditional XHR calls, and all provide store implementations using XHR.
For Dojo 2, I think it would nice if it was clear how WebSockets are used. The native APIs for WebSocket events are rather basic, which over the years led to [dojox/socket](https://github.com/dojo/dojox/blob/master/socket.js) and [tube](https://github.com/bryanforbes/tube).
As such I think we should consider:
- Do we provide an API for WebSockets similar to our handling of dojo/request? The challenge in the past was that it doesn't follow a traditional request/response paradigm, and is more akin to our other event-driven paradigms. If so, do we bother with falling back to long-polling and introducing reconnection logic (needed for some networks and firewalls))
- Do we provide an out of the box module for stores to be backed by a WebSocket for data updates?
- Are there other considerations we need to make for real-time data updates (with Dojo 1.x, dgrid handles this pretty well out of the box, charting was always quite a bit of work). I imagine this fits nicely into our architecture and vdom approach and is easier to make work with Dojo 2.
Contributor guide
Assessment
This issue has not been assessed yet.