The persistent ws callbacks really are great! But I'm missing one feature, the ability to send data directly to clientside JS code.
Is your feature request related to a problem? Please describe.
I have persistent ws-callbacks that sends updates with ws.set_props. Some of the updates needs to run plain JS code (I'm modifies a SVG in realtime based on ws updates)
Describe the solution you'd like
It would be great if the websocket update also could write to an eventbus that js-code can hook on to and listen to.
Describe alternatives you've considered
I've been exploring sending updates via a dcc.Storage and have a clientside callback that act on changes on the dcc.Storage but, this have limitations in rates, if I send updates (with ws.set_props) too frequently some messages are lost, the clientside callback never gets fired. Now we have a asyncio.sleep(0.1) to allow some time for the clientside to pick up the changes. The best solution here would be a channel directly to the JS-code.
The persistent ws callbacks really are great! But I'm missing one feature, the ability to send data directly to clientside JS code.
Is your feature request related to a problem? Please describe.
I have persistent ws-callbacks that sends updates with
ws.set_props. Some of the updates needs to run plain JS code (I'm modifies a SVG in realtime based on ws updates)Describe the solution you'd like
It would be great if the websocket update also could write to an eventbus that js-code can hook on to and listen to.
Describe alternatives you've considered
I've been exploring sending updates via a
dcc.Storageand have a clientside callback that act on changes on thedcc.Storagebut, this have limitations in rates, if I send updates (withws.set_props) too frequently some messages are lost, the clientside callback never gets fired. Now we have aasyncio.sleep(0.1)to allow some time for the clientside to pick up the changes. The best solution here would be a channel directly to the JS-code.