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
Component: Combobox #61
Comments
Thanks for opening - working with Mike on finalizing designs for this. Dependent on #47. |
In ArcGIS Online, the current tags widget requires the user to type something first to get the autocompleted tags. There is feedback that users want to see a list of existing tags, and then decide whether to create a new tag. This will help reduce unnecessary/repeated tags. The tags widget in in Notion seems to be a good reference: |
Chips will be a requirement for this #47 |
We have a need for this component as well with a few modifications: Modifications
NotesOur use case doesn't need multiple but it wouldn't hurt to have it. It would also be good to just have the cc @asangma |
I think we could have the Maybe Or it could just be an option like proposed. Maybe like |
Added API to top. |
Should we leave the "summary" portion out for now? I see it in both the examples that @janett-baresel included in Esri/calcite-app-components#383. |
Thanks for updating the api @driskull. re: chips |
Yes, agreed! in fact they already have an open issue :) - #47. Lots of use cases for chips to exist on their own - in tandem with tree nav selected items, marketplace type filtering experiences, "user tags with avatars", etc. Should support icon, image, "click to close", etc., This component would just leverage those I think. |
@asangma if we get some text and thumbnail, it would already be good. We can see how we can extend the summary part inside SV if its out of scope for you right now. |
Edit: saw summary in attached screenshots. I think we already provide "title" and "subtitle" slots in accordion title etc, we could provide it here but with less strict style overrides to allow the font used in examples attached. Sounds like we need a "selected-appearance-type" attribute to allow selection between dot, check, border, or outline (probably something useful for other components too like dropdown and tree nav that have a selected state, down the road), in a standardized way across components. |
I think a slot would be better so we can handle the color ramp use case. |
Would that be handled by slot for thumbnail? Or does the selected outline ring change based on color ramp? I just meant being able to choose the manner in which a selected item is highlighted. Could be a "none" option for those that want greater customization but I think we want to give folks matching styles to the other "selected items" in components if they don't need that. |
Couple more gotchas: Looks like we'll need options to, "remove from list when selected" - once an item becomes an appended chip, remove it from the filterable list of choices (and reciprocally, return to list when chip is dismissed), and, "create chip from string" - and then emit that in an event for an app to use. Based on our wonderfully consistent tags and category options currently on the Content page in Online: |
Requirements from the Developers site tags component
There are lots of detailed interactions in the WCAG document above which we implemented for the developers site. For example hitting |
"Lookup" terminology here seems useful, this differentiation and nomenclature makes sense to me if we want something better than "super select" |
We spoke briefly at the end of the meeting about the name of this component. Super select may not be the best descriptor. What about |
I think so. Its a requirement of the listbox role which is what we're pretty much going for. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/listbox_role
|
Can we call this component |
It seems like we have two components that we're discussing here:
Should we close this issue and split them up into separate issues? |
I agree with @driskull and think we should separate this out into two issues and close this one. I think it's causing some cunfuzedness. |
I think that's fine, so long as "1" also supports nested items and their selection. I'd suggest also having a "native select" option with a custom styled input and natively rendered |
That might be a 3rd component then. Because it wouldn't be able to do the nesting or custom HTML if the native select is used as the menu. |
Maybe I'm being dense here... What's the difference between the "1" and "2" options above? One has option items that are limited to plain text, and the other allows custom html in option items? And both can have nested children, where a parent item can either select itself and all children or be selected independently? |
Is this correct? |
I think its more like this:
Autocomple/combobox Selects I think 2 & 3 could be the same component if we can decide on the single UI to allow selection. https://esri.github.io/calcite-app-components/?path=/story/components-calcite-pick-list--basic Combobox
Custom select
@julio8a can we setup another meeting for these? There are two different sets requirements here. |
@asangma could something like this: replace this: Both do multiple select in two different UIs and I'm not sure if that is justified. https://jedwatson.github.io/react-select/ It would be nice if we had it all ironed out about when a dev would use...
|
|
Along with multiple selection, it would be nice to have aggregate selections, such as:
This would help support the Dashboards category filtering feature, which could use this component. |
@bpatterson88 do you have any UI examples of that? Use case makes sense and can imagine what it might look like but could be helpful to add here. Thanks |
use case to consider as this is being worked on: |
Installed |
chore: merge main into manuela's branch
Merge pull request #61 from Esri/chore/merge-conflicts
In a recent meeting we discussed some of the behavior around "select" and "dropdown" type elements discussed in:
In the end we settled on implementing something like the multiple select/filter dropdown @macandcheese proposed in #2 (comment)
The purpose of this component would be to allow a use to pick an item or set of items from a list
In order to accommodate various use cases we should incorporate the following options.
Similar to other components that implement form controls I would REALLY like this to look like:
I also think this could be called something more reasonable like
<calcite-combo-select>
Proposed API
Aria role: Listbox. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/listbox_role
Example
The text was updated successfully, but these errors were encountered: