I have a python application which could benefit from tighter control over plots that it is currently launching in the browser. I.e. transition my application from launching plots in browser tabs as one-offs now and then, to managing the plots being visible at any time, and more importantly swapping the data in some of those plots in response to application states ― meaning that the updates swapping data or changing plot properties like the zoom or visible traces are initiated by my python application code.
Entailing or meaning that control is from my application code, not from callbacks invoked within Dash. Maybe it sounds like driving Dash from the outside, if Dash is exclusively meant to own all user interaction.
From a python application, can I seamlessly use Dash to:
show and hide any plot supported by python plotly at any arbitrary time? or must I have one Dash component per application exclusively show/run one plot at a time?
make the chart receive different data at different points in time as my application is running, i.e. that the plot will receive new data from the application and update itself to visualize for the new data rather than the previous data it had. You could call it seamlessly swapping the data by demand as per the overall context of my application.
change plot properties of the launched chart from the python application ― series’ colors, layout, or other properties, rather than or in addition to swapping the data?
As stretch, have Dash communicate back to my application’s event loop by either calling callback functions of my application, or by being pollable by my applicatoin ― for communicating about state changes in Dash which occur due to user interaction with dash or just for knowing when Dash finished rendering the latest data or layout request?
As I understand, Dash is intended mainly as a data visualization application that’s dispatched as the only thread/process of a python main, owning all user interaction for that python main, but maybe my above scenario is also enabled by it without hacking, so I’m happy to hear back!
Thanks, that opens up some scenarios controlling dash from the outside, but probably there’s a lot of coding involved in doing things like switching between different charts not just streaming in data.
Again with the warning that I’ve not tried it - it looks like the websocket component integrates with the Dash callback system, so you can trigger a callback by sending a message via a websocket, and that message can contain whatever JSON contents you want. I’d expect then that the code to, say, display a new chart in response to a websocket message will be pretty much the same as the code required to display a new chart in response to a user clicking a button.
Yes it seems (ahead of starting any implementation) that one can replace an entire plot triggered by user interaction, by having regular dash callbacks use websockets in order to fetch new data for the new chart, through WebSockets, from an external WebSockets peer.
Dash wouldn’t care whether the input for a callback is coming through an external server through WebSockets, and a dash callback can send messages to the same external server from regular Dash callbacks as well, as in the official example.
So essentially anything that can be initiated from or done in response to a message inside a Dash callback, can be done, up to performance considerations, with WebSockets intervening.
It would just make it a typical WebSockets application, just on top of and within Dash.
WebSockets send and receive seem to be seamlessly weavable in the callback system of Dash.
I might assume that sending a lot of data to Dash this way may have similar performance characteristics as say, launching a plotly chart in the browser, from python, with data being given as python data objects. Plus WebSocket protocol overheads.