[FEATURE] Add consolidated RangeUpdate event

[bryevdv]

ref: https://stackoverflow.com/questions/66744548/how-do-i-use-add-next-tick-callback-for-a-panel-wrapped-bokeh-figure

For a long time many users have had a problem where they want one event for "total range change" (e.g. due to a pan or zoom) but as of now, can only set up on_change handlers on all the range start/end properties individually. This leads to triggering more callbacks than desired, and understandable attempts to implement fragile and ad-hoc debouncing schemes.

In the past there was not a good technical path to fixing this because we only had read/write properties available to trigger callbacks. Now that there are FnF events, I think a better solution is possible. Things that normally set multiple range values "all at once" (e.g. pan or zoom tools) could also emit a new RangesUpdate event after all the range values are updated. Then user code can register for a single RangesUpdate event, and look up all the updated values at once (alternatively, the event itself could transmit default range values).

Another option at this point could be a readonly property but I think an event is preferable.

cc @philippjfr @AjayThorve I think this is of interest to Panel and cuxfilter.

[allefeld]

Thanks for the quick response to my SO question and creating this issue!

A RangesUpdate event would be very useful. Alternatively, there could be a Zoom event, so that any change of ranges would be covered by Zoom + Pan + Reset.

This kind of event is available in HoloViews though the RangeXY stream (there are also RangeX and RangeY), though the underlying figure is by Bokeh. The Mandelbrot demo spells it out. @philippjfr I'm guessing HoloViews filters Bokeh events? I can therefore implement what I want using Holoviews, but I prefer Bokeh's API to build figures.

[philippjfr]

+1 on a RangeEvent. It would eliminate some hacky server-side debouncing we are currently doing in HoloViews to make sure we're not triggering too many events. I guess a zoom event which contains the ranges for all axes would indeed be even better.

[bryevdv]

A RangesUpdate event would be very useful. Alternatively, there could be a Zoom event, so that any change of ranges would be covered by Zoom + Pan + Reset.

Thanks for reminding me about Reset, that will need this as well. I do think we need specifically RangesUpdate because, in particular, "pan" events simply mean that a pan gesture has occurred. It does not necessarily mean that the plot itself has been "panned". There may be no pan tool installed on the plot, or it may be turned off, the event still happens. This is so that users can implement their own behaviours based on pan gestures (that may have nothing to do with changing ranges).

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.