partial update of dcc.Graph.figure with LiveGraph composite object
See original GitHub issue(probably this feature would not be implemented in dcc directly, but I’m posting this feature request here because this is the closest repo)
At the moment, when users want to update a small part of a plotly figure in a dcc.Graph in their app, they have two choices:
- either have the whole
dcc.Graph.figureas Output, which can result in passing large objects over the network and poor performance for traces with a lot of data - update only a
dcc.Store, and update thedcc.Graphin a clientside callback. This is fast, but this means that users have to write Javascript, which is a shame for a coding pattern which is quite common.
We could instead provide an object which would have:
- two component members: a Store (corresponding to a patch) and a Graph
- an app member
- and a clientside callback updating the Graph with the Store which would be attached to the app when creating the object
The user-facing API could look like
import dash_core_components as dcc
import dash_html_components as html
import dash
from dash.dependencies import Input, Output, State
import plotly.express as px
from dash_partial_update import LiveGraph
import numpy as np
app = dash.Dash(__name__)
fig = px.imshow(np.random.randint(255, size=(1000, 1000, 3)).astype(np.uint8))
# define app to attach clientside callbacks to it
graph, upstream_graph = LiveGraph(app=app)
graph.figure = fig
app.layout = html.Div([
graph,
upstream_graph,
dcc.Dropdown(id='dropdown', values=['red', 'blue', 'yellow'])
])
@app.callback(
Output(upstream_graph.id, 'patch'),
[Input('dropdown', 'values')]
)
def update_dropdown(value):
patch = dict(layout=dict(newshape=dict(color=value)))
return patch
It would not be possible to target the dcc.Graph.figure as Output since it would already be used in an internal callback, but figure or selectedData could still be used as Input or State. Documentation should be written to illustrate these different cases.
Probably this component should be implemented as a standalone package as a first step, but I’m hoping that the dcc devs can chime in here and make suggestions 😃.
This development will probably be part of the CZI project on image processing.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (6 by maintainers)

Top Related StackOverflow Question
Here’s a working version of the approach outlined above:
Yes exactly - only of course the combiner component would have the merge logic built in, so instead of the
deep_mergecallback you’d just have a clientside identity / pipe callback connecting the combiner’s output prop (result?) tograph.figureOne consequence of this approach, which may or may not be desirable (and is NOT the case with the
deep_mergecallback approach @emmanuelle used above): none of these callbacks would be part of the same callback chain since the connection would be made internally by the component. This might mean that we’d fire the finalresult->graph.figurecallback once per patch, if several patches were provided simultaneously by different callbacks, rather than waiting for them all to arrive, but I think we could avoid that by having the combiner look at its loading state and only do the combining when it’s done loading. But also it would be possible to use this component to hide a circular callback dependency - leading to a potential infinite loop that would be hard for the renderer to detect. I’m sure some users would be happy to use this as a generic workaround when they need a circular dependency, but it would be dangerous in general.