Component: Combobox about calcite-design-system HOT 42 CLOSED

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.

from calcite-design-system.

I think its more like this:

<calcite-select> (populates input with a single selected plain text item - renders native option elements, no nesting)
<calcite-combobox/calcite-autocomplete> (uses chips to indicate selection of one or multiple plain text items - renders custom slots of plain text, can be nested)
<calcite-custom-select> - allows for custom HTML for each option - single item selectable

Autocomple/combobox
https://material-ui.com/components/autocomplete/#combo-box

Selects
https://material-ui.com/components/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

• Many potential items to select, may perform network query to find matches (think tags)
• In multiple mode: allows typing in an input box to filter/query for results
• Shows selected results in the input box area like tags

Custom select

• Limited number of items to select
• In multiple mode: Displays results as a list like a native select. Selected items are shown in place, not in the top box.
• In single mode, shows selected result like a native select

@julio8a can we setup another meeting for these? There are two different sets requirements here.

from calcite-design-system.

@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...

• A calcite-select
• A calcite-combobox
• A calcite-pick-list
• A calcite-value-list
• etc.

from calcite-design-system.

Thanks for opening - working with Mike on finalizing designs for this. Dependent on #47.

from calcite-design-system.

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:

from calcite-design-system.

Chips will be a requirement for this #47

from calcite-design-system.

We have a need for this component as well with a few modifications:

Modifications

• The select option should have a slot to take custom content on the leading and trailing side.
  • This will allow for a thumbnail or control on either side of the option.
• The select box on the dark theme should be dark as well as the dropdown
• The selected visual state could be defined by a background color and/or a border on the item instead of a dot.

Notes

Our use case doesn't need multiple but it wouldn't hurt to have it.

It would also be good to just have the dropdown part of the component available for use within the calcite-value-list and calcite-pick-list or these components could be deprecated.

cc @asangma

from calcite-design-system.

Permanently open (with user defined height) or open on select - for charting components

I think we could have the permanently open as its own component that this one uses internally.

Maybe calcite-select-menu uses calcite-select-list internally?

Or it could just be an option like proposed. Maybe like appearance: "list" | "menu"?

from calcite-design-system.

Added API to top.

from calcite-design-system.

dzine

from calcite-design-system.

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.

from calcite-design-system.

Thanks for updating the api @driskull.

re: chips
Per recent discussion in the sync meeting, we thought it would be good to separate out the chips requirement. It could be its own component that interacts with this select component or something else. @macandcheese cool cool?

from calcite-design-system.

@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.

from calcite-design-system.

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.

from calcite-design-system.

Sounds like we need a "selected-appearance-type" attribute to allow selection between dot, check, border, or outline

I think a slot would be better so we can handle the color ramp use case.

from calcite-design-system.

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.

from calcite-design-system.

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:

from calcite-design-system.

Requirements from the Developers site tags component

• Generally follow the WCAG guidelines for combobox
• Display of the component should be a text box with chips for the selected items.
• Chips display a "X" icon to deselect the item represented by that chip.
• A list of available options should appear when the input is focused.
• Keyboard navigation can be used in the list to select items (up down enter)
• If the input in empty and the user hits delete the last selected item is selected
• Chips can be navigated and deselected by keyboard (left right enter delete)
• When a chip is removed by keyboard the next chip is selected
• Add an options so users can hit "Enter" and add a new item to the available options. This is selected by default.

There are lots of detailed interactions in the WCAG document above which we implemented for the developers site. For example hitting Esc in the text box clears the selection, focus never leaves the text box, tons of ARIA attributes ect...

from calcite-design-system.

"Lookup" terminology here seems useful, this differentiation and nomenclature makes sense to me if we want something better than "super select"

https://uniform.hudl.com/components/selects/design

from calcite-design-system.

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 calcite-combobox or perhaps calcite-tag-manager? Any ideas?

from calcite-design-system.

Of the above, I prefer combobox or "lookup" from above linked example. Tag manager sounds perhaps too specific to a workflow.

from calcite-design-system.

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.

You're right. that sounds good.

from calcite-design-system.

What about calcite-combobox or perhaps calcite-tag-manager? Any ideas?

Why not just call it a calcite-select which is an enhanced selection component that does more than a native select element?

from calcite-design-system.

@patrickarlt @macandcheese @asangma I wanted to bring up a thought I had on the API in regards to implementing the list values. I think the assumption up until now has been that it would be done via slotted content. We could go that route, but I wanted to bring up the option of having the data supplied as rich data (an array of objects). The combobox could then render the list internally in its own render function.

My reasoning behind this is that the combobox needs the list data in a rich data format in order to effectively do the filtering. Using slotted content would mean we'd have to parse that HTML. It would also be easier to manage the display of which items and parents are selected or partially selected if the combobox had control over the rendering of the list.

If this is difficult to visualize, we could setup a meeting to share screens, or I could proceed in this fashion and we could review in the PR stage.

from calcite-design-system.

option of having the data supplied as rich data (an array of objects).

I think this would be inconsistent with the way other components work. If we can do it using child components that would be ideal.

from calcite-design-system.

One requirement we have for Calcite-Select is to show Field Type as in this example

from calcite-design-system.

@patrickarlt keyboard stepping works with tab and shift-tab at the moment. Is it necessary for the arrow keys to mimic that behavior as well?

from calcite-design-system.

Is it necessary for the arrow keys to mimic that behavior as well?

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

ARIA: listbox role
The listbox role is used for lists from which a user may select one or more items which are static and, unlike HTML elements, may contain images.

from calcite-design-system.

Can we call this component calcite-select or calcite-listbox?

from calcite-design-system.

It seems like we have two components that we're discussing here:

1. An autocomplete/combobox component which main use cases are for selecting tags or values from data by typing and showing an autocomplete menu below.
2. An enhanced Select component with the ability to display custom HTML in the menu and options. as well as nesting indentation. Would also handle multiple selection as well. Potentially the ability to filter items. (not sure if this is necessary)

Should we close this issue and split them up into separate issues?

from calcite-design-system.

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.

from calcite-design-system.

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 <options> (https://www.carbondesignsystem.com/components/select/code/)

from calcite-design-system.

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.

from calcite-design-system.

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?

from calcite-design-system.

Is this correct?
<calcite-select> - populates input with a single selected plain text item - renders native option elements, no nesting
<calcite-multi-select>/<calcite-lookup> - uses chips to indicate selection of one or multiple plain text items - renders plain text, styled options, can be nested supports filtering
<calcite-something> - allows for custom HTML for each option - single item selectable, supports filtering

from calcite-design-system.

• Phase 1 for this component: just a text list with multiple selection. Can have hierarchy with parent/children. Includes chips #47
• Phase 2: Allow a slot for leading or trailing graphics.

from calcite-design-system.

Along with multiple selection, it would be nice to have aggregate selections, such as:

• Select all
• Deselect all
• Select only this item

This would help support the Dashboards category filtering feature, which could use this component.

from calcite-design-system.

@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

from calcite-design-system.

This is a screenshot from the upcoming 8.1 release of Dashboards. You can see the UI to select All or Clear selection in the top right.

The screenshot from Google Data Studio shows the "select only this item" use case. A bit more niche than select all / clear.

from calcite-design-system.

Here is an in progress mockup for Dashboards. In most cases the dropdown input will be no wider than about 300px, so we need an additional filtering input outside of the chip area. Otherwise there won't be enough space for the user to filter the list.

from calcite-design-system.

use case to consider as this is being worked on:
https://devtopia.esri.com/WebGIS/arcgis-app-components/issues/54

from calcite-design-system.

Installed

from calcite-design-system.