User does not get feedback when a value is matched asynchronously on the server

[jouni]

If a combo box uses a lazy loading data provider, any value the user enters into the field needs to be matched to the entire set of options in the data set.

As demonstrated in vaadin/vaadin-combo-box#919, it is possible that the value the user types into the field gets discarded after they have already moved onto filling other fields. It is possible that the user does not notice this, and a value they entered ends up getting ignored.

Currently, if a the typed value does not match any items in the data set, the field value is cleared.

A better option, possibly, would be to mark the field as invalid and retain the value the user typed. The underlying value would be the previous valid value, but the displayed value would be what the user typed. This is how date picker currently works.

Changing this behavior would be considered a breaking change, and requires a new major version. To alleviate the issue before a new major version, we should consider using some other feedback mechanism to let the user know what is happening.

One option is to show a loading spinner in the field while the component checks from the data provider if there is a matching item to set as the value. The user would notice the spinner, and hopefully also then notice if the field gets cleared after the server request finishes (either confirming a matching value or clearing the field).

If we choose to add a spinner in the field (while hiding the toggle button), we could deprecate and hide the spinner in the overlay. This assumes that it would be okay to show the spinner also when the popup is already opened and the user scrolls the list to load more items.

Updated loading state behavior

Preferred behavior (breaking change)

(Figma source)

This would be considered as a fix to vaadin/vaadin-combo-box#919

Open questions:

• What happens if the user focuses the field again when the server request is still pending?
• Should the user be able to open the popup when a server request is still pending? I assume that would mean that the user wants to cancel any existing server requests and see the first page of items in the popup. Should the spinner turn into a “cancel” button when hovered, and should the Esc key cancel the request?

[jouni]

Actually, I’m not sure if the invalid state can be considered as a breaking change? The underlying, programmatic value would still be the same (previous valid value, null/empty in the example above). Only the presentation would change.

That said, I don’t know how that would work with all sorts of validation logic.

[rolfsmeds]

What happens if the user focuses the field again when the server request is still pending?

Off the top of my head, I don't think anything shoud happen -- maybe the user just noticed that it's still loading, and wants to refocus the field to be able to pick an item from the list once it's done loading?

Should the user be able to open the popup when a server request is still pending? I assume that would mean that the user wants to cancel any existing server requests and see the first page of items in the popup. Should the spinner turn into a “cancel” button when hovered, and should the Esc key cancel the request?

If the loading really takes that much time, which I certainly hope it very rarely would do, then maybe clearing the filter value would suffice as a way to cancel it?

As for the question of whether the invalid state is a breaking change, from the users point of view, I'd say no -- the current behavior could even be described as buggy or at least unexpected. From a validation logic POV, I can't say, hoping others can give their opinion.

[jouni]

What happens if the user focuses the field again when the server request is still pending?

Imagine a scenario:

• The pending value is still in the field
• User focuses the field
• The server returns, no matching value is found

Do we still clear the field, or do we keep the input, as the user might want to continue writing from what was in the input previous?

[jouni]

From a validation logic POV, I can't say, hoping others can give their opinion.

Even if validation logic would get caught up on this, I would still think it would be an okay change. The user would just be made more aware that what they were trying to select wasn’t actually a thing, and they should go back and check it (instead of letting them believe all is fine, we just dismissed what you wrote). The change would not affect “happy paths”, where the selection goes through correctly. I would not think the change would break any user’s workflow.

[rolfsmeds]

Do we still clear the field, or do we keep the input, as the user might want to continue writing from what was in the input previous?

Definitely keep the input if you ask me. The way I see it, the state (filter text, validity) of the field should not be affected by whether or not it's focused or not.