EuiComboBox looks like a regular text input when in noSuggestions mode

[cjcenizal]

When entering input into <EuiComboBox noSuggestions>, the combo box looks like a regular text input:

Without some prompt, a user could easily type something in, not hit Enter, and move on, assuming that their input has been recorded. I think we should still show the custom option prompt in this situation, so the user knows they need to hit Enter for their input to be recorded:

[cjcenizal]

Actually, there's a problem with the solution I suggested. Validation of the input can occur as the user types and when the user hits Enter. Errors are displayed as EuiFormErrorText below the combo box. These errors would be covered by the dropdown in my suggestion, making for a pretty bad UX.

Instead of this, I think the consumer should implement an onBlur handler, which checks for input and if input exists then it shows a "Your option hasn't been added yet. Please hit ENTER to add it." EuiFormWarningText below the form. This would be dependent upon changes suggested in #1200. We should document this pattern in the docs.

[cjcenizal]

CC @yaronp68 @sebelga

[cjcenizal]

Even simpler solution: onBlur acts as onEnter and automatically tries to submit the input as a new item to the combo box.

[snide]

@cjcenizal In no suggestion mode, why not just use a regular text input instead and do your validation / creation based upon that value on from submit? I don't necessarily see the usage for combobox when it's not using the abilities of combo box?

If you came back to the form, after creation, just use a read-only version with a "remove" button or something next to it if you needed to change it?

Would help to have some context here.

[cjcenizal]

Here's the context:

In no suggestion mode, why not just use a regular text input instead and do your validation / creation based upon that value on from submit?

That's a good solution, too. I'm not sure which solution would be more elegant; that or converting the input into an item on blur. I'm leaning towards the latter, since I think that will naturally trigger the validation rules that are used when the user hits enter to add an item. It might be a little more work for the consumer to trigger these rules for the input in addition to the items. I haven't dug into this though, so I'm not 100%.

I do think converting the input into an item on blur has the additional benefit of signaling to the user they can enter more items, because then the combo box really looks like a combo box.

[snide]

The only thing I don't like about the on blur is that it's not a user action, but something automatic, which is a little disingenuous considering it looks like a normal form. Normally you'd have some sort of save/create action on it. Though you likely aren't saving things entire until you finally submit the form, so that point might be moot.

I don't feel super strongly about it, but the way that form looks, it seems like it should just be a regular old text input with its own custom validation. I kind of can't think of a good usage of noSuggestion in any use case other than a read only mode. hmm.

Also, assume its just a typo, but given the plural nouns, that looks like something i can type multiple values into?

Unrelated, but I'm warming up to your bottom error handling pattern (in this usage).

[cjcenizal]

The only thing I don't like about the on blur is that it's not a user action, but something automatic, which is a little disingenuous considering it looks like a normal form.

That's a valid point.

I don't feel super strongly about it, but the way that form looks, it seems like it should just be a regular old text input with its own custom validation. I kind of can't think of a good usage of noSuggestion in any use case other than a read only mode. hmm.

In this case, the user can enter multiple IPs, each of which will be an item in the combo box. When you say custom validation, do you mean the user enters multiple IPs with spaces or commas between them?

The use of noSuggestions in conjunction with read-only mode had never occurred to me. Should we add this example to the docs site?

Unrelated, but I'm warming up to your bottom error handling pattern (in this usage).

I'm really happy to hear that... I feel like it makes for a nice UX since it shows up right where you're already looking. BTW I did borrow it from Cloud, so they could probably give more background on why they chose this placement.

[sebelga]

This is an interesting conversation. I had the exact same feeling when implementing another form and I tried to add to the Array of the combo box onBlur but that was not possible.

I think that we need to find a pattern and stick to it across all forms with a similar input. So here we are talking about a field that lets the user add a few entries (1 to 7 max).
Another solution that occurs to me is having a normal input text and below it, aligned on the right,
a + Add new entry link that would add a new input text right below the first one.

Unrelated but I think the combox could accept a prop with the character(s) that would trigger an entry creation. It is very common in those inputs to trigger with the , (coma).

[cjcenizal]

@sebelga I tried your multiple-input idea originally. 😄 Not sure how the design team feels, but Jen suggested using combo box instead and I agreed because this solution seemed like overkill (too many things going on and too much space taken up for what we were trying to do). On second thought it would solve our problem and might make more sense than a combo box if we only expect users to need a couple seed nodes.

Unrelated but I think the combox could accept a prop with the character(s) that would trigger an entry creation. It is very common in those inputs to trigger with the , (coma).

I think this is a great idea. I had a similar thought recently because I think we need to support copy/paste with combo boxes. The user should be able to select and copy the items into a comma-delimited string, and paste the comma-delimited string into a combo box to turn it into items.

[sebelga]

@cjcenizal I don't see what the problem is with your screenshot, I like it 😊 . The only thing to add is: don't let the user add another seed if the previous one is blank. Otherwise, this could work quite well.

[cjcenizal]

@sebelga Validation became a problem, because EuiFormGroup places the error text at the very bottom, below the last text input. So you couldn't easily tell which seed node was formatted incorrectly.