feat(material/autocomplete): add input to require selection from the panel

[crisbeto]

Adds the requireSelection input to the autocomplete, which when enabled will clear the input value if the user doesn't select an option from the list.

Fixes #3334.

[alixroyere]

Thanks for this desired feature 😸

I've got some interrogations.
With this parameter set, does formcontrol valuechanges only emit valid (available in the selection, like a selector) values or every (invalid/partial string) value typed by the user?
If not, is the formControl validity set to false for these values?
It seems to only clean the value at the end of the panel usage. That may create some issues when using the parameter, because some not-selected values would be pushed in the control, which may be unexpected.

[crisbeto]

It'll still receive the values typed by the user, but the value will be cleared if the panel is closed without selecting an option. I was considering not pushing values to the model at all, but that would introduce issues in the case where the input value is also used for filtering the options.

[alixroyere]

I understand but aren't these values available on the html input anyway, as with the (input) event?

[crisbeto]

They are, but usually the expectation when using reactive forms is that you wouldn't have to interact with the DOM directly. In retrospect, we should've had two form controls: one for the input and one for the autocomplete panel, instead of combining them into one, but making the change at this point would be a massive breaking change.

[alixroyere]

You're right 😿 That would have been easier to use as a consumer.
Then I don't know how to use this new feature as is, because form with required value would be valid when user is typing and panel is open. That would lead to weird behaviors. The only option I see, is to set a custom validator (checking if current value is inside the possible values), which is heavier than some propositions available in the initial issue here #3334 even if these propositions have their own issues too.
I wish something easy to use could be found

[crisbeto]

There's still some time until the feature makes it into a release so we have time to iterate on it, but it's unclear to me what the alternative would be. We could add a custom validator in the autocomplete that only becomes invalid once the panel is closed?

[alixroyere]

You mean that becomes invalid once the panel is open, and valid once closed? That could help.

[crisbeto]

Yeah basically it would be invalid only if the panel is closed and none of the option values is selected.

[alixroyere]

Or add a new input that would set what to put in the control (the user typing + the selected/empty values = default) or (only the selected/empty values). Is it still a massive breaking change?

[alixroyere]

Or add a new input that would set what to put in the control (the user typing + the selected/empty values = default) or (only the selected/empty values). Is it still a massive breaking change?

Well in fact this is more an "AND" than an "OR". Because the validity issue would still be here for the combination of "requiredSelection=true" + default value for the other new parameter

[alixroyere]

Yeah basically it would be invalid only if the panel is closed and none of the option values is selected.

Are you're talking about the validity calculated by the validator (if control is valid for this validator), or about the validity of the validator (if validator is removed or something)?

[crisbeto]

I'm not sure I follow the last comment. The autocomplete trigger would provide itself as a validator that sets an error like matAutocompleteRequireSelection if the user didn't make a selection.

[alixroyere]

Then, would this error be there only when selection panel is open or after panel close too?
In fact the current requireSelection behavior is cleaning the input after panel close, and the invalid control issue would be there only when panel is open.

If this is also applied when panel is closed:

• Would the error be there for null/no selected value? We could need to require the setted value to be among options, but not require a value to be set.
• What would happen to this error when value is set programmatically formControl.patchValue(value)?

[crisbeto]

The error would be there if the panel is closed and the value is null. Since it's cleared when the user closes without selecting anything, that should guarantee that it's among the options. That won't catch invalid values set through patchValue, but at that point the application author has control over what value is being set so they can ensure that invalid values aren't being set.

[alixroyere]

I was more thinking about setting a static invalid state as long as panel is open, and remove it once panel is closed. That would lead to more consistent behaviours, with requireSelection auto cleanings

[alixroyere]

Well in fact what you propose may be better to match the input name "requireSelection". But some real life usages need to only "forceSelection" on existing values, not to require one to be set. Could there be something to cover this case?
If the new parameter was more as a forceSelection, it could still be used as a requireSelection when adding the classic required control parameter

[crisbeto]

Capturing what we talked about in our team meeting: we should make it so the model value is null while typing and requireSelection is enabled.

[alixroyere]

nice !

[crisbeto]

I've sent out #27572 based on the discussion here. It's worth noting that I decided to keep the model value while the user is typing, instead of resetting it to null, because resetting it would emit an additional change event.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}