A more plotly-native syntax for plot hooks

[jonmmease]

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:

def hook(plot, element):
    fig = plot.state
    fig["layout"]["dragmode"] = "pan"
scatter.opts(hooks=[hook])

The native plotly.py Figure class supports a set of fig.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 property

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.

[jbednar]

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?

[philippjfr]

This overlaps a bit with #4463

[jonmmease]

This overlaps a bit with #4463

Oh, yeah it does, I hadn't seen that PR. I'll make some comments over there...