Repository navigation
[autocomplete] Support values other than raw options #23708
Description
- I have searched the issues of this repository and believe that this is not a duplicate.
Summary 💡
Right now (at least if you use multiple) Autocomplete/useAutocomplete the value that comes back in onChange is always the raw option data. i.e. If you use options=[{value: 'a', label: 'A'}, {value: 'b', label: 'B'}] and select the "A" option then value will be [{value: 'a', label: 'A'}].
Ideally it would be possible to provide multiple=true options=[{value: 'a', label: 'A'}, {value: 'b', label: 'B'}] and get back values like ['a']. Autocomplete does feel like this is intended to be supported, because you can provide a getOptionSelected and it's used to identify selected options instead of doing any comparisons on the option itself. However when it comes to adding an item to a multiple array, all useAutocomplete does is newValue.push(option);. There is no way to control what part of option is actually used as the value.
I think a getOptionValue(option) function would fit the current options implementation the most.
Examples 🌈
<Autocomplete
multiple
getOptionSelected={(option, value) => option.value === value}
getOptionValue={(option) => option.value}
options={[{value: 'US', label: 'United States', {value: 'CA', label: 'Canada'}]}
/>Motivation 🔦
MUI's <Select> easily supports this. It uses children instead, so all it takes is options.map(item => <MenuItem key={item.value} value={item.value}>{item.value}</MenuItem>) to do this in Select and pretty much every project I've worked on uses Select this way. It would be strongly preferred if it were easy to use useAutocomplete the same way.
Activity
oliviertassinari commentedon Nov 25, 2020
[-][Autocomplete:multiple] Support values other than raw options[/-][+][Autocomplete] Support values other than raw options[/+]dantman commentedon Nov 25, 2020
Forcing the developer to manually manage the values list doesn't feel like a great alternative. Using Select, TextField, etc... isn't this complex even when using the
{value, label}pattern.You mean store
country: [{value: 'US', label: 'United States'}, {value: 'CA', label: 'Canada'}]in the form values when US+CA are selected andcountries.map(country => country.value)it when doing an api call?Honestly it feels wrong to have localized labels in form data just because of limitations in useAutocomplete's implementation. And MUI doesn't work this way with any other field. Select, Radio, and Checkbox can easily be connected to form handling code and all support using a separate value and label for options. It doesn't feel right that if you have a Select implemented that way (with the same simple submit handler code as the rest of your fields) and it becomes too long to be a normal select, you have to rewrite the submit handler code to work differently than every other field, just because the field type used changed from Select to Autocomplete.
oliviertassinari commentedon Nov 25, 2020
We have a similar pain in this direction on #21489. Ok, why not. we could:
getOptionValueto feed the default behavior ofgetOptionSelected.getOptionValueto later implement native integration with a<form>.Feel free to work on it. At least, we have spotted a small issue with the generated documentation.
ZovcIfzm commentedon Dec 12, 2020
Could I try and take a wack at this?
ZovcIfzm commentedon Dec 13, 2020
Hi! I'm completely new to open source contributions so I'm a bit confused, wouldn't this just be a one line change? Where we just add,
to Autocomplete.js
And then maybe a test?
I'm thinking since getOptionValue is a completely new function, nothing depends on it so all I would need to add is the function itself and a test.
Please correct me if I'm wrong, thank you so much!
oliviertassinari commentedon Dec 13, 2020
@ZovcIfzm If you are completely new, you might want to do one "good first issue" before moving to this "goo to take" issue.
Regarding your question. Yes, we would need a new test case, to make sure it has the correct impacts on the component, e.g. change the onChange returned value, change how value <-> option comparison is done, etc.
34 remaining items
Mohammad-Khayata-4441 commentedon Sep 3, 2024
aress31 commentedon Jan 8, 2025
[-][Autocomplete] Support values other than raw options[/-][+][autocomplete] Support values other than raw options[/+]exorex commentedon Apr 9, 2025
@oliviertassinari This feature would be a major improvement. Supporting custom values beyond the raw options would unlock much more flexibility for advanced use cases.
googamanga commentedon Apr 13, 2025
Will-at-FreedomDev commentedon Jun 5, 2025
I incorrectly assumed that this was how this already worked. Something like this is what makes me enjoy working with Angular Material.
brendonrapp commentedon Jun 18, 2025
Straight from the Select component documentation:
"react-select" has
getOptionValue. Lacking this makes Autocomplete fall short of being the "improved" version it's claimed to be.hakon-dale commentedon Aug 26, 2025
mj12albert commentedon Apr 21, 2026
Considering the upvotes, I'll look into adding this. In the meantime, if you have objects in the dataset and want to have string values, workarounds are possible:
react-hook-form: https://stackblitz.com/edit/bonrqx3j?file=src%2FDemo.tsxgetOptionLabelcallback is getting the value instead of option object #31192 as a duplicate of this issuegithub-actions commentedon Oct 5, 2026
This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
@dantman Thanks again for creating this issue! If you have a moment, we would love to hear your thoughts on how we handled it with this short feedback form.