[Autocomplete] Standard for Select options with different values
See original GitHub issue- I have searched the issues of this repository and believe that this is not a duplicate.
Many times, the values sent to the input are different from the label displayed on the option. Today, there are some props in the Autocomplete that brings the possibility to have a custom object like:
// For an object like {id: "test", text: "Test - ABC"} you can use:
getOptionLabel={(option) => option.text}
getOptionSelected={(option, value) => option.id === value.id}
But if Material UI can define a standard for receiving this values, much of the hard work done by the programmers can be fixed. A good proposal would be using an array of tuples:
<Autocomplete
options={[["test", "Test ABC"], ["test2", "Test 2 - CDE"]]}
/>
Other solution could be using an object with a specific shape (Like Select2 standardize on https://select2.org/data-sources/ajax). Pretty achievable using PropTypes or TypeScript:
<Autocomplete
options={[
{
"id": "1",
"text": "Option 1"
},
{
"id": "2",
"text": "Option 2"
}
]}
/>
Also, pagination of results could help the people that are still not used to search and scroll forever instead.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:12 (12 by maintainers)
Top Results From Across the Web
[Autocomplete] Standard for Select options with different values
I have searched the issues of this repository and believe that this is not a duplicate. Many times, the values sent to the...
Read more >Material-UI <Autocomplete /> different label than option value
This is a pretty standard use case, however I need the selected item in the form to be different than the label. Currently...
Read more >HTML attribute: autocomplete - MDN Web Docs
The HTML autocomplete attribute lets web developers specify what if any permission the user agent has to provide automated assistance in ...
Read more >Autocomplete attribute has valid value | ACT Rule | WAI - W3C
This rule checks that the HTML autocomplete attribute has a correct value. Applicability. This rule applies to any HTML input , select and...
Read more >Lightweight Autocomplete Controls with the HTML5 Datalist
Too many options in your HTML Select list? Try a Datalist! Learn how to work with this lightweight, accessible, cross-browser autocomplete ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
If this one is still valid I can take it.
@rhuanbarreto Thanks for opening this issue. Yeah, I think that I could get behind supporting this change. It seems that the most common use case is to provide an object for the options, e.g.
<option value="1">Blue</option>
. So why not start from the same structure react-select’s users are already familiar with? This will help people move between the two components.I propose: