-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we simplify form/selector components? #318
Comments
Now to respond to @AnnMarieW here:
As far as this would be an issue, I believe it already exists because a |
I'll respond in detail tomorrow since I want to ponder more on this. But my initial impression: Generally, it makes sense to me for the I think we initially didn't merge these because of user experience and we've had this unsaid rule of returning only one "main" dash component per model. On user experience: Even though you could select a single value with a The Datepicker:
DateRangePicker:
For me, it makes sense to combine the components if the majority or even all of the arguments are the same. If there is a more significant deviation (as for UserInput and TextArea), I would keep them separate. The question I have is:
|
Interesting discussion, @huong-li-nguyen already said most of the relevant points, so I'll try to be short: On
|
Thanks for the comments both! Just to clarify, we should absolutely not replace the single-value
We don't necessarily need to use the same solution for both cases, e.g. we could use option 1 for At the moment the case for option 2 is stronger for Let's leave @AnnMarieW do you have any thoughts on this? Just for the date picker, do you think we should simplify to one
Not sure exactly, but if we had a single
Indeed, if this is yes then it leads to unpleasant complexity where some arguments are only relevant to some selectors, and I'd strongly prefer to avoid that. This was one of the original arguments against having a generic |
I know I don't have all the info, but it seems like separate models adds less complexity. |
Update: in #309 we went for a single These versions expose a new argument My current feeling is it would probably make sense to merge |
Background context
So far we have the following possible
SelectorType
, which can be used inParameter.selector
orFilter.selector
:Checklist
, based ondcc.Checklist
Dropdown
, based ondcc.Dropdown
RadioItems
, based ondcc.RadioItems
RangeSlider
, based ondcc.RangeSlider
Slider
, based ondcc.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 usingadd_new_type
, but eventually it should be native functionality.To this end, a
_FormComponentType
exists but is not yet public. This contains:SelectorType
UserInput
, based ondbc.Input
(private)Textarea
, based ondbc.Textarea
(private; actually doesn't exist in_FormComponentType
yet but should do)Button
, based ondbc.Button
(public, since it's also part ofComponentType
so that it can be used directly inPage.components
orContainer.components
, like aGraph
,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:
@AnnMarieW said:
Removing/renaming
Slider/RangeSlider
would be a breaking change, but we can definitely do it with suitable deprecation warnings etc.Why
UserInput
andTextarea
?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
andDateRangePicker
?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 useUserInput
).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 thanDatePicker
, althoughDatePicker
is definitely also common terminology and well understood.Should we go for more "declarative" names like
Select
orSelector
rather than imperative ones likeDropdown
? 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
RangeSlider
with a single value vsSlider
The text was updated successfully, but these errors were encountered: