Untangling Select: dropdowns vs autosuggest fields

[joshhunt]

Problems with Select:

Many interfaces in Grafana make heavy use of our Select component for letting the user select a value from a list, with the ability to filter the list down by a search value. As Grafana (and it's users) have grown, we've spotted a few shortcommings of the current Select component:

• We use it often in place of a 'simple' text field with auto-suggest - users are not expected to scroll through the list of items and pick one, but are instead expected to type to at least filter the list of items
• It has poor performance for 'lots' of items. We often use this component when there is a dynamic amount of items, depending on the user's setup (such as picking from Prometheus labels), and the backing react-select component has poor performance for thousands of items.
• 'Creating a new value' with Select (that is, entering and selecting a value that does not appear in the list of options we pass in) is clucky and not immediately obvious
• Does not use native controls on mobile. Mobile browsers often have a greatly improved interface for selecting options, but our Select component will always render it's custom UI.
• It displays groups of options poorly. Groups are collapsed by default, and when expanded there's very little visual heirachy between group titles vs options, and between group themselves

  Default collapsed group	Expanded group

Technically, we're actively working on improving the performance of Select, but this would not address the UX shortcomings of the component. It's clear that Select needs usability improvements, and possibly a new component for where a select/dropdown isn't best suited.

What others do

Consider the Dropdown component vs Autosuggest in Braid Design System. Dropdown is described as being for 'smaller lists', with Autosuggest as an alternative for 'larger lists':

The Dropdown component described as being for "smaller lists", and is used for selecting from a small list of predetermined items (does not allow for freeform input to select a value not in the list, yet supports jumping to an item by typing, like native controls) where it's plausible that the user will manually select a value by scrolling + clicking.

Autosuggest instead is presented as an enhanced text field, that provides suggestions as you type to complete, but does not require the select of a predetermined value. The user is never presented with a complete list of options, and it's theoretically 'infinite'.

Although it lacks an autosuggest/complete field, Radix's Select also keeps to a similar pattern of a small, fixed list with no text field search.

Notable examples

Datasource picker

Datasource picker presents a dynamic list of items that admin users have entered. The list is usually small enough to scroll through and pick a value, though you might not know exactly what it's called, so searching is also useful. It's never valid to enter a value that's not in the list, as you cannot query a data source that doesn't exist!

Prometheus metric picker

Presents all metric labels from a prometheus instance. Hundreds or thousands of options. Although admins would set up a prometheus server, many other users may push metrics into the instance, so they might not have control over how many options are presented. Users are probably at least starting to search for something, then scroll through options and pick one. While we can accurately predict what valid options are, it's not completely invalid to enter a value that's not in the list - it would just create a query that doesn't return any results.

Considerations

• Should "auto-complete" be a separate component from "Dropdown"? Should "select your UI language from these 8 options" be a different control from "select a prometheus label from thousands"?
• Should "auto-complete" support that a valid option is selected, or should it always free-form input from the user? Should this validation be left to consumers (with potential for divergence)?
• When a user initially clicks a Prometheus label input (currently Select), do they get value from the (initial) list of metrics being shown? Do they use this to browse, or immediately start entering a value?
  

[joshhunt]

My gut feel is that:

• Select is for a fixed number of known options where only a valid value can be selected, like for picking a UI language, a country, or a dashboard. It may have the ability to create a new option, but that's a rare 'creation' use case (such as creating a new folder to put a dashboard in). It is a rich <select /> component.
• Autosuggest is for freeform user input, where we suggest options that are often dynamic (or driven from user input elsewhere in the system), such as Prometheus labels. Entering a value that is not in the list is perfectly fine (even if it produces an empty result, such as returning no metrics).

[leeoniya]

i'll try to distill what i've written in the previous discussion about this:

• it would be great to have the filtering/highlighting mechanics decoupled from the UI. there are many different ways to match and sort a list of items with very different performance profiles. having this functionality live outside of the UI component(s) will allow for much easier composition of filtering options as well as performance tuning. we can filter 200k items down to 1k and pass only those to the UI component for virtualized rendering.
• there's no reason that a virtualized list of 20 visible items cannot handle 10k+ scrollable items in memory (assuming each item has a pre-defined height and does not need to be DOM-measured). IMO choosing an additional dependency to handle large lists is a crutch that's best avoided.
• the "discovery" case should be considered. it's easily possible to have 1000 different labels containing k8s, but the first 900 have the same prefixes and differ only slightly. i want the ability to scroll through that list quickly to reach the last 100 that may be different/interesting without knowing exactly what they might be. we cannot always order the results in a way that puts the most 'distinctive' items at the top, and it's impossible to know where that list can be chopped off. "no one will scroll through 1000 items" is not always true; people scroll through much bigger Excel tables than this to find what they're looking for.
• i think these use cases have 80% overlap and it may prove difficult to make guidance for two components with only 20% differentiation in features (assuming we solve the perf problem). there is a real risk of each component eventually scope-creeping to support features of the other one.

[torkelo]

I agree 100% that we have been missing an auto complete component (to be used with regular inputs), and hence overuse the Select component.

[joshhunt]

Talked about this with @JoaoSilvaGrafana and @staton-hyse11 and identified three common uses cases where we use Select currently:

• Prometheus metric select: very large list of items, user is expected to search to filter down results. Valid to enter a value which isn't in the list of options. Rich <input type="text" />
• Folder picker to save a dashboard into: medium amount of items, user could pick from the list, or search to filter to select a value from the list. Rich <select />
  • You should not be able to create new options from this type of Select, instead we should have a common pattern outside this select for creation. Or, use the above component.
• Start of week: must select from a small list of options, search isn't necessary. Basic <select />

Any additional components we develop should have sufficient visual differentiation between them so the user expectations match functionality (e.g. no search + cursor if not searchable).

No immediate plans for any changes here, but something to keep in mind for future work.

[gelicia]

Hello, as you may have heard, we are transitioning away from using discussions to discuss feature requests. Due to the age and number of responses to this discussion, we are deciding to close it. If this is something you would like to see in Grafana, feel free to open an issue so the discussion can continue. Thank you!