Support widgets in link_selections

Motivation

This is an idea for extending the link_selections framework to support performing selections using widgets. For example

• A range slider could be used to create a selection similarly to how a selection can be performed on a histogram element.
• A dropdown or multi-select could be used to create a selection on a categorical dimension.

The top section of the Dash Oil and Gas demo shows an example of the basic idea:

API

Here’s an idea for the API. We could add a new method to the link_selections function object called something like add_widget/add_selection_widget. This method would expect a dimension name and a Parameterized object that contains a param named value (with an option to override this name).

from holoviews.selection import link_selections
from ??? import Slider

lnk_sel = link_selections.instance()
hvobj_linked = lnk_sel(hvobj)

slider = Slider(start=0, end=10, value=6)
lnk_sel.add_widget("x0", slider)

If slider.value is a scalar, then the widget is used to select this exact value. If an interval, then widget is used to select a range of values.

The add_widget method would wrap this input object in a Param stream, then build a Derived stream that would convert this value and the dimension into a selection expression, and this selection expression would then be treated just like a selection expression coming from a figure element.

Usage

The main initial usage would be in the context of a Panel app, and in this case a Panel widget could be passed as the argument to add_widget. But for use in non-panel contexts (like Dash), it would be nice to have a set of parameterized objects in HoloViews that could be used instead.

These could live somewhere like a holoviews.widget_models module, and they could have identical names to corresponding Panel widgets, but only contains a subset of the properties. For example, holoviews.widget_models.Slider would only have value, start, end, and step params.

With this approach, a user constructing a Dash app would pass widget_models.Slider to add_widget and then the holoviews_to_dash function (see https://github.com/holoviz/holoviews/pull/4605) would transform the Slider model into the appropriate Dash widget.

We may want to hold off on introducing these widget models until we work on the 2.0 refactor because we may need to do something similar to remove the hard dependency on Panel from the HoloViews core.

cc @philippjfr @jlstevens @jbednar

[jbednar]

Sure, and ideally also accepting a widget directly for convenience:

link_selections.filter_by_value(dim1=3)
link_selections.filter_by_value(dim1=param_obj.param.value)
link_selections.filter_by_value(dim1=slider) # taking .param.value from the slider so slider users don't have to think about param
link_selections.filter_by_value(slider) # taking the dim name from the slider's name if not supplied?

link_selections.filter_by_range(dim1=(0, 10))
link_selections.filter_by_range(dim1=param_obj.param.value)
link_selections.filter_by_range(dim1=range_slider)
link_selections.filter_by_range(range_slider)

link_selections.filter_by_expr((dim("dim1") + dim("dim2")) > 0)
link_selections.filter_by_expr(param_obj.param.selection_expr)

I may be misremembering, but I think Philipp already had a use case where removing a term from the link_selections object was important. But yes, without such removing, eventually adding enough fixed filters would lead to an empty selection. Seems fine to me.

For the fixed case, I’m imagining someone always wanting to filter a large dataset for only the records applying to this user (e.g. to enforce permissions), and that would just be a fixed value like this. Obviously one can do such selections on the data itself before even launching the app, but it still seems convenient to have filtering like that available this way as well.

[jbednar]

Very cool! It would be great to bring widgets “into the fold” of things covered cleanly by link_selections.

I wouldn’t call this functionality add_widget, though; seems like it doesn’t have to specifically be a widget, does it? Couldn’t it just be any parameter? In practice it could typically be a widget, but it seems like something you could hook up to any source of parameter values, e.g. something listening to events entirely outside the dashboard; the value (as a filter) seems like the important thing, not the widget itself.