Closed xhluca closed 2 years ago
Some more thoughts and trying to gauge interest on that (please use 👍 or 👎 )
Would pydata
compatibility benefit the dash user experience? i.e.
DataTable.from_dataframe(df, id="my-id")
Slider.from_array(np.array(...))
Download.from_pillow(Image.open(...))
Based on Slack conversations in #dash-labs, here are the optional "shorthands" that we're going to offer for Dash Core components (dcc) and the DataTable (dt) component, illustrated through a series of "hello world" basic Dash apps. Please compare the current syntax with the optional, new shorthand syntax:
Current dcc syntax: https://gist.github.com/jackparmer/864545d0c7f7596ed6b4c9b18a3b252c
Proposed shothand dcc syntax: https://gist.github.com/jackparmer/e777629e0d2ad6b7eae0c07ccc984f75
All of these "hello world" Dash examples can be found by searching here: https://dash.gallery/python-docs-dash-snippets/ (for example, enter "Legend" to get the radio button example, etc).
Closed by https://github.com/plotly/dash/pull/1763
Would it be possible to allow components like
dcc.Dropdown
anddcc.Checklist
to acceptoptions
other than a list of dictionaries with a format like{'label': label, 'value': value}
? For example:{'label': value, 'value': value}
key -> val
would be processed into a list of{'label': key, 'value': value}
.In a similar fashion, for
dcc.Slider
we could accept alternatives for themarks
:{i: str(i) for i in list}
marks=True
when there's a min, max, step value specified would display a mark on every stepmarks: int = n
would display a mark at everyn
steps (so{i: str(i) for i in range(min, max, n*steps)}
)Furthermore, the default for
value
could be improved: when set toNone
/null
, it would be inferred:options
In the case of
dcc.Slider
, when the min and max are left asNone
/null
, they could also be assigned to the small and largest values inmarks
, or 0 and 100 (and step to 1) ifmarks
is not specified.Overall this is just an idea but it would make the UX much nicer on the python side. Right now to define a slider we need:
With inferred default and polyvalent marks:
Similarly for a dropdown:
which could simply be
And in the case where we want to access a dataframe column's unique values (super frequent use case for me):
Obviously sometimes a mapping would work better, but in that case a key-value pair would be more concise than writing "label" and "value" many times: