[Autocomplete] Non-freesolo autocomplete acts like freesolo: passes string to getOptionLabel instead of option

[HansBrende]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Steps:

1. Make a normal auto-complete (not free solo)
2. Implement getOptionLabel as (opt) => opt.property.subProperty (for some "property" field)
3. Play around with the autocomplete for a while (selecting an option, clearing the option, and clicking to expand the options)... eventually you will get a

TypeError: Cannot read properties of undefined (reading 'subProperty')

CodeSandbox: https://codesandbox.io/s/angry-tree-2jcp3o?file=/src/App.tsx

I'm assuming that's because I'm being passed a string instead of an object of the expected type. However I was trying to debug this in prod with an upset user so I did not have time to check for sure.

This bug ONLY occurs on v5.11.7. When I pinned @mui/material to v5.11.6, the behavior went away, and user reported no further issues. I'm assuming this is the result of your recent changes to freesoloing autocompletes in the release from 3 days ago.

Current behavior 😯

No response

Expected behavior 🤔

No response

Context 🔦

No response

Your environment 🌎

No response

[ZeeshanTamboli]

It doesn't look like this bug report has enough info for one of us to reproduce it.

Please provide a CodeSandbox (https://mui.com/r/issue-template), a link to a repository on GitHub, or provide a proper minimal code example that reproduces the problem.

[HansBrende]

@ZeeshanTamboli I literally did provide enough info. That is no joke. But if you want me to spell it out, here's a minimal example (as you will see, no more information than what was already provided). This tells me you did not bother to try testing what I said would break (assuming I am incorrect that it would break with such a simple example?).

export default function App() {
  return (
    <Autocomplete
      options={[{ property: {} }, { property: {} }]}
      getOptionLabel={(opt) => opt.property.subProperty} // <-- this is the only line that matters; literally exactly the same as what I already said.
      renderInput={(params) => <TextField {...params} />}
    />
  );
}

[ZeeshanTamboli]

@HansBrende Only explaining it in full sentences is not enough information for us. You could be explaining something else, while the reproduction code could yield different results. Anyway, here's a CodeSandbox reproduction: https://codesandbox.io/s/angry-tree-2jcp3o?file=/src/App.tsx. Thanks for your code example.

[HansBrende]

@ZeeshanTamboli I provided, not only "full sentences", but the exact code for getOptionLabel in my original issue comment, which is the only thing required to reproduce. All other values can be set to their defaults/whatever.

[ZeeshanTamboli]

@HansBrende What is your use case for having multiple (in your case, two-level) nested options? Do you somehow use it in the getOptionLabel callback? If not, that means it's passing unnecessary nested options and you can map it to one level. Your code in your application most likely has room for improvement since the last release. See the CodeSandbox: https://codesandbox.io/s/crimson-shape-9rgvow?file=/src/App.tsx

[HansBrende]

@ZeeshanTamboli

const options = [{isEmpty: true}, {isEmpty: false, data: {}}];
const getOptionLabel = opt => opt.isEmpty ? 'NO DATA' : opt.data.subProperty;

No, my code does not have room for improvement, and I'm certainly not going to rewrite my code to accommodate your regression; I'm going to pin mui/material to the previous patch version until this is fixed.

[rangoo94]

Looking at the code, the useAutoComplete hook is falling back to '', when there is no value selected (Autocomplete.js:L474).

This shouldn't be the case. The getOptionLabel is defined as (option: T) => string (ignoring free-solo types), where T is any and is provided by an MUI's user.

Because of that, the getOptionLabel shouldn't be called when there is no value - otherwise, the definition would need to be i.e. (option: T | string) => string, which could make the integration much harder.

[rangoo94]

I created #36088 PR - it will maintain the getOptionLabel contract and not call it with lacking values, while it will keep the same behavior internally (falling back to '' for comparison).

Thanks to that, it will neither break the contract nor the internals.