Material-ui: Autocomplete multiple can't pass 'required' validation

Created on 3 Jul 2020  路  10Comments  路  Source: mui-org/material-ui

  • [x] The issue is present in the latest release.
  • [x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 馃槸


When submitting a form with an Autocomplete that allows multiple values and that has the 'required' prop on the text input, the validation error shows up whether values were selected or not.

Screenshot 2020-07-03 at 18 35 32

Expected Behavior 馃


The text field should have some value so that it passes validation on form submit.

Steps to Reproduce 馃暪

https://codesandbox.io/s/material-demo-grwoq

Steps:

  1. Create an Autocomplete with 'multiple' prop and pass 'required' to the rendered textfield.
  2. Wrap it in a form with a submit handler.
  3. Try to submit the form

Context 馃敠


This is really useful in forms without custom validation.

Your Environment 馃寧

| Tech | Version |
| ----------- | ------- |
| Material-UI | v4.10.2 |
| React | |
| Browser | |
| TypeScript | |
| etc. | |

Autocomplete

Most helpful comment

What do you think about this fix?

diff --git a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js b/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
index feea18c89..577df20a0 100644
--- a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
+++ b/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
@@ -962,6 +962,7 @@ export default function useAutocomplete(props) {
       ref: inputRef,
       autoCapitalize: 'none',
       spellCheck: 'false',
+      ...(multiple && value.length > 0) ? { required: null} : {},
     }),
     getClearProps: () => ({
       tabIndex: -1,

All 10 comments

What do you think about this fix?

diff --git a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js b/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
index feea18c89..577df20a0 100644
--- a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
+++ b/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
@@ -962,6 +962,7 @@ export default function useAutocomplete(props) {
       ref: inputRef,
       autoCapitalize: 'none',
       spellCheck: 'false',
+      ...(multiple && value.length > 0) ? { required: null} : {},
     }),
     getClearProps: () => ({
       tabIndex: -1,

I will work on it!

What do you think about this fix?

diff --git a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js b/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
index feea18c89..577df20a0 100644
--- a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
+++ b/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js
@@ -962,6 +962,7 @@ export default function useAutocomplete(props) {
       ref: inputRef,
       autoCapitalize: 'none',
       spellCheck: 'false',
+      ...(multiple && value.length > 0) ? { required: null} : {},
     }),
     getClearProps: () => ({
       tabIndex: -1,

In that case what if multiple is false, you can consider a situation when we are passing a Radio component instead of Checkbox in renderOption of AutoComplete. You are allowed to select only one out of all the values in list. In this situation I think the following check ...(multiple && value.length > 0) ? { required: null} : {} wouldn't work.

So we will still get validation error even tough we have already selected one from the list.
However I am not sure if having Radio in Autocomplete sounds practical or not as in that case one would use Select component instead of Autocomplete .

Reopening since #21670 did not address the underlying issue. A fix should be based on #21692 or a similar test.

The issue is that submitting a form is prevented. That should not be solved by removing attributes which affect styling, assistive technology etc.

Could we consider the styling and a11y downside as an acceptable limitation of the tradeoff?

The number of upvotes on 馃憤 https://github.com/JedWatson/react-select/issues/1453 can help understand the pain around validation.

Could we consider the styling and a11y downside as an acceptable limitation of the tradeoff?

There's no other way than a simple: no. There's too much that goes into this attribute. I don't even understand how you think that wrong styles are acceptable, nor missing a11y. Both on their own are unacceptable.

@eps1lon Fair enough, it sounds like this issue deserves more attention, I went ahead too quickly.

I have seen https://select2.org/ uses a native hidden multi-select element, maybe we could consider a similar approach.

Any update on this? I was facing the same problem.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  路  3Comments

sys13 picture sys13  路  3Comments

finaiized picture finaiized  路  3Comments

iamzhouyi picture iamzhouyi  路  3Comments

ryanflorence picture ryanflorence  路  3Comments