You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HoloViews supports Plot hooks as a way to provide plotting backend customizations that aren't supported by plot/style opts. These works with the Plotly backend, but the syntax is a little awkward. For example, the plotly backend doesn't yet support changing the default plot drag mode from zoom to pan. This can currently be done in a plot hook like this:
A plotly.py user who creates a figure with a figure factory or plotly express could perform this modification using the update_layout method like this:
fig.update_layout(dragmode="pan")
Proposal
It would be really nice to be able to use the concise update syntax of these methods as hooks on HoloViews elements / containers. I'd like to propose adding new style properties to Elements/Containers with the Plotly backend for each of the plotly update methods. The value would be a dict of the kwargs to be passed to the corresponding plotly method. These methods would then be applied to the figure right before the current hooks step.
So the example above could become
scatter.opts(update_layout=dict(dragmode="pan"))
Validation of the arguments would be handled at render time by the corresponding plotly methods, so there would be decent error messages when invalid property names or values are supplied.
Does this sound reasonable @jlstevens@philippjfr@jbednar ? My motivation here is to provide a fallback for people who are used to plotly.py/Dash and are making the jump to incorporating HoloViews.
Another alternative I've considered in the past was to write a special class that wraps a HoloViews object and provides these update_* methods directly and then dispatches them as hooks. But avoiding a wrapper class for as long as possible seems less complex.
The text was updated successfully, but these errors were encountered:
Sounds like a good idea. Is there a formulation that retains the concision and directness for plotly, but would also be useful for other backends? E.g. does plot.state["x"]["y"] have any meaning for figures from other backends?
Background
HoloViews supports Plot hooks as a way to provide plotting backend customizations that aren't supported by plot/style opts. These works with the Plotly backend, but the syntax is a little awkward. For example, the plotly backend doesn't yet support changing the default plot drag mode from zoom to pan. This can currently be done in a plot hook like this:
The native plotly.py
Figure
class supports a set offig.update_*
methods that support targetting various parts of the figure:fig.update_layout
fig.update_traces
fig.update_annotations
fig.update_shapes
fig.update
: Update any single figure propertyA plotly.py user who creates a figure with a figure factory or plotly express could perform this modification using the
update_layout
method like this:Proposal
It would be really nice to be able to use the concise update syntax of these methods as hooks on HoloViews elements / containers. I'd like to propose adding new
style
properties to Elements/Containers with the Plotly backend for each of the plotly update methods. The value would be adict
of the kwargs to be passed to the corresponding plotly method. These methods would then be applied to the figure right before the currenthooks
step.So the example above could become
Validation of the arguments would be handled at render time by the corresponding plotly methods, so there would be decent error messages when invalid property names or values are supplied.
Does this sound reasonable @jlstevens @philippjfr @jbednar ? My motivation here is to provide a fallback for people who are used to plotly.py/Dash and are making the jump to incorporating HoloViews.
Another alternative I've considered in the past was to write a special class that wraps a HoloViews object and provides these
update_*
methods directly and then dispatches them as hooks. But avoiding a wrapper class for as long as possible seems less complex.The text was updated successfully, but these errors were encountered: