[Autocomplete] Inconsistent option Format Between Single and Multiple Fields

[aress31]

Steps to reproduce

1. Add two autocomplete fields that share the same set of options.

2. Configure one field with multiple: true and the other with multiple: false.

3. Use the following getOptionLabel implementation:

   getOptionLabel={(option) => {
     console.log("option", option);
     return option;
   }}

Current behavior

When the multiple property is set to true, the option passed to getOptionLabel has the following format:

{
  id: '12345',
  name: 'Sample Issue',
  status: null,
  creator: 'John Doe',
  description: 'This is a sample issue',
  // Other properties...
}

However, when multiple is set to false, the option passed to getOptionLabel has the following format:

[
  {
    id: '12345',
    name: 'Sample Issue',
    status: null,
    creator: 'John Doe',
    description: 'This is a sample issue',
    // Other properties...
  }
]

[!IMPORTANT] > Note that this an array data structure.

This difference in format requires additional checks and transformations in the code, which seems unintended and may be a bug. Consistent formatting for the option object, regardless of the multiple property, would simplify the handling and reduce unnecessary transformations.

Expected behavior

option within getOptionLabel should have the following, consistent, data structure:

{
  id: '12345',
  name: 'Sample Issue',
  status: null,
  creator: 'John Doe',
  description: 'This is a sample issue',
  // Other properties...
}

Context

No response

Your environment

npx @mui/envinfo

  System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 23.3.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.9.2 - C:\Program Files\nodejs\npm.CMD  
    pnpm: 9.13.2 - ~\AppData\Local\pnpm\pnpm.EXE   
  Browsers:
    Chrome: Not Found
    Edge: Chromium (129.0.2792.65)
  npmPackages:
    @emotion/react: ^11.14.0 => 11.14.0
    @emotion/styled: ^11.14.0 => 11.14.0
    @mui/base:  5.0.0-beta.68
    @mui/core-downloads-tracker:  6.4.0
    @mui/icons-material: ^6.4.0 => 6.4.0
    @mui/lab:  6.0.0-beta.23
    @mui/material: ^6.4.0 => 6.4.0
    @mui/private-theming:  6.4.0
    @mui/styled-engine:  6.4.0
    @mui/system:  6.4.0
    @mui/types:  7.2.21
    @mui/utils:  6.4.0
    @mui/x-charts: ^7.23.6 => 7.23.6
    @mui/x-charts-vendor:  7.20.0
    @mui/x-data-grid: ^7.23.6 => 7.23.6
    @mui/x-date-pickers: ^7.23.6 => 7.23.6
    @mui/x-internals:  7.23.6
    @toolpad/core: ^0.11.0 => 0.11.0
    @toolpad/utils:  0.11.0
    @types/react: ^18.3.1 => 18.3.18
    react: ^18.3.1 => 18.3.1
    react-dom: ^18.3.1 => 18.3.1
    typescript:  5.7.3

Search keywords: autcomplete

[mnajdova]

Can you share a reproduction. I can't reproduce, the value I get is the same for example in this demo: https://stackblitz.com/edit/react-fujuhrhe?file=Demo.tsx

[aress31]

@mnajdova, thank you for taking the time to look into the issue.

I managed to resolve it by adjusting the structure of my value.

The confusion stemmed from the name getOptionLabel, which is somewhat misleading—it would be more accurate to call it getValueLabel, as it operates based on the value. To work correctly, the value must be in the appropriate structure: either an array for multiple selections or an object for a single selection.

[DiegoAndai]

I'm glad you figured it out @aress31. Closing as such.

[github-actions]

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.

Note

@aress31 How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.

[aress31]

@DiegoAndai that doesn't change that the function name doesn't reflect the use and that one would expect it to take the options as arg as opposed to the value.

Is anything planned to either rename the func or have it do what the name would suggest it does?

[DiegoAndai]

Is anything planned to either rename the func or have it do what the name would suggest it does?

This is tracked in #31192. Please upvote the issue, as we use the upvotes to prioritize work. I can't give an ETA for the change though.