Background context

So far we have the following possible SelectorType, which can be used in Parameter.selector or Filter.selector:

• Checklist, based on dcc.Checklist
• Dropdown, based on dcc.Dropdown
• RadioItems, based on dcc.RadioItems
• RangeSlider, based on dcc.RangeSlider
• Slider, based on dcc.Slider

Maybe, where suitable components are available, these will change to dbc components in the future when we are fully bootstrap compatible.

In due course we would like to enable a Form model that enables you to use these outside the context of a filter/parameter. I've already done this many times for custom apps by using add_new_type, but eventually it should be native functionality.

To this end, a _FormComponentType exists but is not yet public. This contains:

• all the above SelectorType
• UserInput, based on dbc.Input (private)
• Textarea, based on dbc.Textarea (private; actually doesn't exist in _FormComponentType yet but should do)
• Button, based on dbc.Button (public, since it's also part of ComponentType so that it can be used directly in Page.components or Container.components, like a Graph, Card, Table)

Remember also that we aim to keep things simple rather than supply every possible sort of component out of the box. We don't want to have too many models.

We are now considering adding a DatePicker in #309. This raises some questions that don't need to be resolved now but should be pondered over time...

Why two sliders?

From #309 (comment):

@antonymilne said:

I don't know why we have a separate RangeSlider and Slider at the moment 🤔 As far as I can tell RangeSlider with a single element value = [1] would function identically to a Slider. So we maybe should have simplified this to just a single vm.Slider model. Did we consider this before? I can't remember. @maxschulz-COL?

@AnnMarieW do you know if there's any difference in behaviour between RangeSlider with a single element value vs. Slider? Is there a reason there's two separate dcc components for these? Other than it's maybe easier for people to find the right component because people know to search for a slider vs. a range slider. From the vizro side, we generally try to aim for something as simple as possible rather than many possible options so maybe it would make sense for us to just provide a single Slider model that handles both. What do you think?

@AnnMarieW said:

Interesting question about using a single value in the Range Slider. It seems to work, but it would be possible to change it to a range slider when updating it with two values in a callback. So there would need to be some type of check to make sure that only a single value is returned. I'm not sure if there would be any other unintended issues.

Removing/renaming Slider/RangeSlider would be a breaking change, but we can definitely do it with suitable deprecation warnings etc.

Why UserInput and Textarea?

I didn't look into these properly yet, but at a glance they feel quite similar to me. Should they also be a single model? They're not public so we can merge/rename/whatever as we please.

How to handle DatePicker and DateRangePicker?

Will be resolved in #309.

Names

Our policy so far has been to name our models according to the underlying dash component, unless where that seems confusing (hence instead of Input we use UserInput).

• Dash components already have well-established/considered names, so no need for us to think about it again
• it's more familiar to Vizro users coming from Dash
• it makes it clear what Dash component our model is based on, so easier for a user to find relevant docs on that component

I don't want to bikeshed and spend a lot time thinking again about names, but maybe we should consider whether this the right approach though. It sort of couples us to a particular Dash component which we might want to change, and makes it tricky in the edge case that a model could return different Dash components like we might do for Date(Range)Picker.

e.g. I kind of like the simplicity of naming in https://observablehq.com/documentation/inputs/ where it's just Date rather than DatePicker, although DatePicker is definitely also common terminology and well understood.

Should we go for more "declarative" names like Select or Selector rather than imperative ones like Dropdown? We considered this before and decided it made the UX more rather than less confusing, e.g. people are more likely to say "I want radio buttons here and checkboxes there" rather than "I want a selector that enables me to select multiple items.

Next steps

• Understand what, if any, difference there is between RangeSlider with a single value vs Slider
• Do a more thorough review of how other tools handle form components, e.g.
  • https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
  • https://observablehq.com/documentation/inputs/overview
  • https://dash-bootstrap-components.opensource.faculty.ai/docs/components/form/
  • many others
• Do some actual user research on how people think about creating forms. e.g. if most people who use vizro aren't already dash users, there's less (but still some) value in mirroring Dash component names