material-ui: [Autocomplete] The value provided to Autocomplete is invalid. (with the installed isOptionEqualToValue)

Could we please get an option to turn off the warning completely? At this stage it’s causing a lot of noise in tests and, as reported, it’s not warning anything useful.

@michaldudak I added PR with disableOptionEqualToValueWarning prop which disables that warning. I would appreciate any suggestions if you guys have any ideas about naming. The freeSolo attribute modifies the standard behavior of Autocomplete component that’s why it was not a solution in my case

Apparently, at this point, the warning causes more confusion than assistance. If anyone is willing to investigate if this warning can be disabled for cases of async loading without much hassle, then feel free to grab this issue.

I’m also considering removing the warning altogether, but let’s try the less destructive option first.

I have multi select AutoComplete. This is the way I solve the problem:

• options: <[{ label, value, type }]>
• Turn on freeSolo, autoSelect to ignore warning
• Turn on clearOnBlur to ignore value that not [Enter] or throw selecting an option in dropdown
• Modify onChange to handle unwanted text

<Autocomplete
      freeSolo
      disabled={loading}
      multiple
      clearOnBlur
      options={options}
      getOptionLabel={(option) => option.label}
      groupBy={(option) => option.type}
      /** Help show no option dropdown, freeSolo does not show it **/
      getOptionDisabled={(option) => option.label && option.label.toLowerCase() === 'no option'}
      filterOptions={() => {
        if (!options.length) return [{ label: 'No option', value: 'No option' }];
        return options;
      }}
      value={selectedOptions}
      onChange={(event, selectedValues) => {
          // This only apply to multi select
          if (['removeOption', 'clear'].includes(reason)) {
              setSelectedOptions(selectedValues);
          }
          if (['selectOption'].includes(reason)) {
              const lastValue = [...multiValue].pop();
              const isAllow = options.some((item) => item.label === lastValue?.label);
              if (!isAllow) break;
              setSelectedOptions(multiValue);
          }
      }}
      onInputChange={(event, value) => setSearchTerm(value)}
      renderInput={(params) => (
          <TextField {...params} label="label" />
      )}
/>

Happy coding 😃

In case anyone stumbles upon this issue today still, the trick for async-populated options is to add the currently selected option so that it doesn’t trigger the false positive that can happen when setting a new value while an async request changes the array of options that is provided.

const [item, setItem] = useState<ItemModel>();
const [items, setItems] = useState<ItemModel[]>([]);
const [input, setInput] = useState('');
const query = useDebounce(input, 250);

useEffect(() => {
  fetchItems(query).then((items) => setItems(items));
}, [query]);

return (
  <Autocomplete
    autoComplete
    filterSelectedOptions
    getOptionLabel={(option) => option.name}
    onInputChange={(_event, value) => setInput(value)}
    onChange={(_event, value) => setItem(value)}
    options={item ? [item, ...items] : items}
    renderInput={(extra) => <TextField {...extra} label="Name" />}
  />
);

Hi all. Is there an update on this issue? I agree 200% with @derekcannon , as I am using multi-select autocomplete with queried options upon keyboard input. So the selected options may not be on the current options, as the options are queried upon input and dynamic. Everything works fine, but I would love to suppress the Warning… disableOptionEqualToValueWarning <-- looks sweet to me! Thanks! @grzegorz-jazurek

I have the same Issue … boring warning

I have this issue as well, and I think its the same case. It can happen when implementing an external async search. The Autocomplete component still has a value, but the options are now populated with the results from the search, which does not include the current value.

Here is a reproduction: https://codesandbox.io/s/asynchronous-material-demo-forked-q0yox?file=/demo.tsx

Steps to repro:

1. type “inter” in the Autocomplete, chose “Interstellar”
2. deselect the Autocomplete
3. select the Autocomplete, type “godfather”
4. observe console

It doesn’t repro 100% of the time, but its pretty easy to get it to happen.

I have got the same issue - getting the warning: “The value provided to Autocomplete is invalid. None of the options match with “”. You can use the isOptionEqualToValue prop to customize the equality test”.

Adding the final part || value === "" to isOptionEqualToValue={(option, value) => option.name === value.name || value === "" removes the warning, but then a new problem appears: all options turn colored as if all were chosen

Thanks for the reproduction, @markedwards. I’m reopening the issue.

I can’t say I like the idea of introducing yet another prop to the Autocomplete, especially just for suppressing a warning. @DiegoAndai, @mj12albert, @mnajdova, I propose to remove the warning altogether.

For anyone who may still be running into this warning. The issue I ran into was a mislabelling of “freeSolo”, with a capital “S”.

still an issue for me. not wanting to add more state as said in @angrybacon answer, because i use react hook form mainly to control the state.

 <Controller
  name={"district"}
  control={control}
  render={({ field: { onChange, value } }) => (
    <Autocomplete
      onChange={(e, data) => onChange(data)}
      options={districts.map(({ id, name }) => ({ id, name }))}
      value={value}
      getOptionLabel={(option) => option.name}
      isOptionEqualToValue={(option, newValue) => {
        return option.id === newValue.id;
      }}
      renderInput={(params) => (
        <TextField {...params} placeholder="test" label="test" />
      )}
      onInputChange={(_evt, newValue) => setSearch(newValue)}
      inputValue={search}
    />
  )}
/>

can i just return true for isOptionEqualToValue prop? is it affect anything., didn’t find the effect so far. even still don’t get it the purpose of that prop in the first place

@mnajdova given that this issue is getting activity consistently, I think we should remove the warning for v6. What do you think?

I had a bit different kind of a problem that is described in this thread, but as it lands on same field I decided to post here rather to post new thread (hope that’s fine).

TL;DR

A opinion that has very minor affect on… anything. May resolve some common issues found in internet with this component.

Decription

I have MUIv5 and I use MUI Autocomplete, with Formik (with Yup) and use typescript. I’ve come into an opinion where I feel like that useAutocomplete (@mui/base/AutocompleteUnstyled/useAutocomplete.js) applies bad practices.

By the snipped code below, it states that the Autocomplete initial value can not be undefined, but rather null? – henche, to my knowledge undefined is stated as “not set” or in validation schemes “not touched” and null is actually a defined value ("someone or something have changed or set it’s value to null).

In my case this caused the form to be initialized with “undefined”… string (what the …) and bunch of error/warning messages, saying:

• Material-UI: the value provided to Autocomplete is invalid. None of the options match with ´""´.
• The getOptionLabel method of Autocomplete returned undefined instead of a string for "".

  if (process.env.NODE_ENV !== 'production') {
    if (value !== null && !freeSolo && options.length > 0) { // <-----------
      const missingValue = (multiple ? value : [value]).filter(value2 => !options.some(option => isOptionEqualToValue(option, value2)));

      if (missingValue.length > 0) {
        console.warn([`MUI: The value provided to ${componentName} is invalid.`, `None of the options match with \`${missingValue.length > 1 ? JSON.stringify(missingValue) : JSON.stringify(missingValue[0])}\`.`, 'You can use the `isOptionEqualToValue` prop to customize the equality test.'].join('\n'));
      }
    }
  }

Curtain call

I resolved my problem by initializing form values with null and applying nullable into Yup validation schema for the fields.

Sample code:

<Field
    name="fieldName"
    component={Autocomplete}
    options={sortedfieldNameKeys}
//    getOptionLabel={(option: string) => sortedfieldNameKeys?.length > 0 ? fields[option] : "" }
    getOptionLabel={(option: string) => sortedfieldNameKeys?.length > 0 ? fields[option] : null }
    renderInput={(params: AutocompleteRenderInputParams) => (
        <MuiTextField
            {...params}
            name="fieldName"
            label={translator('fieldName')}
            variant="standard"
            helperText={touched?.fieldName && errors.fieldName && errors.fieldName}
            error={touched?.fieldName && Boolean(errors.fieldName)}
        />
    )}
    sx={{ width: '20ch', mr: 4 }}
/>
// ....
=> fields = await getFields(); // [ { "01aeed68-...", value: "Field 1" }, { "470401eb-...", value: "Field 2" },... ]
// ....
=> sortedFieldNameKeys = Object.entries(fields).map(({key, value}) => (key));
// ....
=> form = {
  ...,
  fieldName: null, // '' // undefined  ... oof
}

Any updates on this? Looks like this suggestion could allow fixing the issue.

I forked the controlled input example from the documentation and tweaked it slightly, working towards what I was actually building (albeit not for Harry Potter characters).

Although the warning does not show up, there is a lot of questionable UX going on. You will notice the behavior where you delete half the name and it reappears on blur because of the odd implementation choice of having the Autocomplete have two values.

I’ve “solved” that by setting value via the onInputChange handler, which removes the need for two pieces of state, and removes the weird ambiguity between the two competing/conflicting values. But the documentation explicitly advises against this.

Of course, creating this dummy value object does make it clear why the warning shows up.

Which would bring me back to: Either the Autocomplete component should be completely re-thought (probably the “right” solution) w.r.t. multiple values and setters, OR the warning should be ditched and you can set the value to whatever you want.

The latter also does feel like a “right” choice considering entering non-specific options is kind of the whole thing that sets <Autocomplete /> apart from <Select />. If you don’t want the user to be able to type in random other text, use a <Select />, no?