Material-ui: [Autocomplete] Standard for Select options with different values

[rhuanbarreto]

• [x] 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.

[oliviertassinari]

@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:

interface option {
  label: string;
};

[rhuanbarreto]

Great! I think this change will be a big selling point for moving from react select to material UI!

Just one point: The interface object is missing the value key.

[oliviertassinari]

Why is it missing a second property?

[rhuanbarreto]

It should be

interface option {
  value: string,
  label: string
}

You need to have something to separate the value from the label, like in react-select:

import React, { Component } from 'react'
import Select from 'react-select'

const options = [
  { value: 'chocolate', label: 'Chocolate' },
  { value: 'strawberry', label: 'Strawberry' },
  { value: 'vanilla', label: 'Vanilla' }
]

const MyComponent = () => (
  <Select options={options} />
)

[oliviertassinari]

We have no use case for the value key, we only leverage label in the component (yet?).

[rhuanbarreto]

Yes. That's why I'm proposing this! The majority of the selects won't have the value exactly the same as the label.

[rhuanbarreto]

In addition, selects with labels as values are good for NoSQL implementations. But for relational databases, almost always the value is different from the label.

[rhuanbarreto]

It seems that the most common use case is to provide an object for the options, e.g. <option value="1">Blue</option>.

In the case you showed, you need to have another key in the object in order to have a separate value from the label.

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.

The structure I proposed is the same as react-select's

[oliviertassinari]

Ok, we can stick to

interface option {
  label: string;
};

in this case. There is no need for another opinionated key, until we change the native form validation implementation.

[DanailH]

If this one is still valid I can take it.

[rhuanbarreto]

in this case. There is no need for another opinionated key, until we change the native form validation implementation.

But what in the validation is preventing from implementing a separate key? I didn't get the point.

[DanailH]

After starting the implementation I feel we may need to discuss this further because having a strict type of the options being passed will limit the flexibility of the component. What I mean by this is that currently, you can feed the component any type of array data structure and then use the getOptionLabel property to manually set the label for each option. The first problem I can see appearing by setting a strict data type for the options array will be that the developers would need to transform the data before they pass it to the Autocomplete component, which is fine but if they do that then the getOptionLabel method would be as useful as it is now.

Ultimately if we are to implement that change that would mean that we would trade flexibility for component simplicity, which is fine as long as we are aware of this.