[EuiComboBox] Single-select combobox should not allow deletion using delete key unless isClearable=true

[wylieconlon]

We have occasionally run into Lens bugs like this one where we are not expecting the ComboBox to be clearable. Users can select the current option and then press the delete key, which causes the last token to be deleted. Can we prevent that interaction?

Steps to reproduce:

<EuiComboBox
  isClearable={false}
  singleSelection={{ asPlainText: true }}
  selectedOptions={[{ label: 'Only option', value: 'only' }]}
  options={[{ label: 'Only option', value: 'only' }]}
  onChoose={(chosen) => {
    console.log(chosen);
  }}
/>

[thompsongl]

I see a couple options for this:

1. As mentioned, the combination of isClearable=false and singleSelection prevents delete key behavior.
2. Add a new configuration option to singleSelection (preventEmptySelection) which overrides isClearable and prevents delete key behavior.
3. Add a new prop (preventEmptySelection) which overrides isClearable and prevents delete key behavior, and also works with multiselect comboboxes.

Thoughts @cchaos @chandlerprall ?

[cchaos]

Honestly, when looking at this exact example from Lens, I think the fault lies in that Lens doesn't have a good error state for when a field is not selected. The empty combobox should come up as invalid when empty and the configuration node should show as invalid the invalid state like:

The problem with a preventEmptySelection in this instance is that the starting point of the field select is always empty until the user chooses one.

---

Now, if I think about EuiComboBox's selection states (specifically singleSelection) outside of specific contexts, I worry that without any way to delete the current selection it is confusing as to how to search for a new one.

Take this specific state where it's a single-selection, no clear button, and I want to replace the option I have selected, but I need to find it first.

It is not clear that if I just start typing that the current selection will be replaced with what I type mainly because the cursor is at the end of the text, indicating that's where typing will occur. So if a user tries to backspace but nothing happens, they may think it is broken. So then question becomes, should the cursor's position be moved or should we allow the normal use of backspace which will delete letters one by one and continue the filtering?

---

Basically I think this is actually a harder UX problem than it seems on the surface and may require more thought and design. But for the specific Lens issue, there are ways to fix it on that side by using better invalid states.

[wylieconlon]

@cchaos we already implemented the error states you're discussing for the new functions in Lens, but not for older functions. We can update those too. elastic/kibana#89032

[daveyholler]

Closing as not planned