[material-ui][Autocomplete] Fix behavior when there are duplicate labels

[islandryu]

Fixed a behavior that caused label refinement to go wrong when two labels were the same.

• I have followed (at least) the PR section of the contributing guide.

code

const fruits = [
  {name: "banana"},
  {name: "apple"},
  {name: "peach"},
  {name: "strawberry"},
  {name: "strawberry"},
]

export default function Playground() {
  return (
    <Autocomplete
      id="combo-box-demo"
      options={fruits}
      getOptionLabel={(fruit) => fruit.name}
      sx={{ width: 300 }}
      renderInput={(params) => <TextField {...params} label="Movie" />}
    />
  );
}

Before modification

localhost_3000_playground_.-.Google.Chrome.2023-03-05.07-27-43.mp4

After modification

localhost_3000_playground_.-.Google.Chrome.2023-03-05.07-29-04.mp4

---

Fixes #26492

[mj12albert]

Related to #26492

[ZeeshanTamboli]

Index should not be used for a key in React in case the options are reordered, added or deleted.

[imuble]

Let us provide the "key" parameter ourselves? 🙏 We use icons to distinguish between options with the same name

[ZeeshanTamboli]

Let us provide the "key" parameter ourselves?

Yes, this would make sense.

[mui-bot]

Netlify deploy preview

https://deploy-preview-36426--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against ed4405f

[islandryu]

I have added the getOptionKey API to allow for specifying a key.

[ZeeshanTamboli]

Apologies. After re-reading the discussion in #26492, I noticed that the getOptionKey prop was previously added (#32910), but later reverted in #33142. The reasoning behind this decision was explained in #26492 (comment).

However, I believe that including index with getOptionLabel is not the appropriate solution, as mentioned in #36426 (review). I'd go with having a getOptionKey prop.

cc @oliviertassinari @mui/core

[michaldudak]

I wasn't against getOptionKey either, but let's wait for @oliviertassinari's response to #32910 (comment) about his idea of solving it without introducing a new prop.

[ewerkema]

@michaldudak @oliviertassinari Any update regarding this PR? We implemented our own getOptionKey to resolve this issue. Another solution could be to always generate a unique key, but that would have a performance impact. This looks like a good solution to me.

[oliviertassinari]

Ok, it seems that we can't use #24198 (comment) because it would lead to extra DOM operations, and regressing on #24213 that requires to keep the same DOM element.

I can think of 3 different solutions:

1. We implement a variation of [Autocomplete] for Voiceover on Mac is reading incorrect labels on any browser #24198 (comment) automatically detecting duplicates and incrementing one index per duplicate. This sounds like it coud harm performance for a not frequent use case, I doubt developers using unique labels would want this.
2. We push toward the getOptionValue API as in [Autocomplete] Support values other than raw options #23708 and kill two birds with one stone. However, it's likely that the return value could be of any type but we need a string for the key.
3. We move toward allowing developers to control the id of the option displayed in the list.

So, it seems that option 3 wins. If we push with this new prop, I think that the main challenge will be for developers to figure out how to solve their issue. They would get a key conflict but no pointers on how to solve it. I guess that if this comes frequently enough (for now, we don't know), we could create a dedicated warning for it.

[ZeeshanTamboli]

@islandryu Thanks for your contribution.

I have made some changes after confirmation to go with this route in #36426 (comment). It seems fine to me.

I'd like @michaldudak to review this.

---

but we need a string for the key.

@oliviertassinari Why do we specifically need a string for the key? Why can't it be anything?

Resolved

[michaldudak]

It looks OK in general. I had one doc-related comment, but besides that, I think it's good to go.

[EvgenyArtemov]

I'm glad it's solved, it was really big problem for me! Many thanks to Mr Contributor 🫡