[autocomplete] groupBy suddenly seems required instead of optional when using as generic component

[maapteh]

Steps to reproduce

In PR #44657 it seems that the optional prop suddenly is typed as required. Since we wrap our own components with MUI inside now we have this issue. Its in the useAutocomplete.

Current behavior

i get this error:

Type '(((option: T) => string) & ((arg: T) => string)) | undefined' is not assignable to type '(option: T) => string'.

Expected behavior

In for example 6.1.9 it resulted in the correct optional prop:

Context

No response

Your environment

npx @mui/envinfo

  System:
    OS: macOS 15.1.1
  Binaries:
    Node: 22.11.0 - ~/.nvm/versions/node/v22.11.0/bin/node
    npm: 10.9.0 - ~/.nvm/versions/node/v22.11.0/bin/npm
    pnpm: 8.14.3 - ~/Library/pnpm/pnpm
  Browsers:
    Chrome: 131.0.6778.265
    Edge: Not Found
    Safari: 18.1.1
  npmPackages:
    @emotion/react: 11.11.4 => 11.11.4
    @emotion/styled: 11.11.5 => 11.11.5
    @mui/lab: 6.0.0-beta.23 => 6.0.0-beta.23
    @mui/material: 6.4.0 => 6.4.0
    @mui/system: 6.4.0 => 6.4.0
    @mui/utils: 6.4.0 => 6.4.0
    @types/react: 18.3.12 => 18.3.12
    react: 18.3.1 => 18.3.1
    react-dom: 18.3.1 => 18.3.1
    typescript: 5.6.3 => 5.6.3

Search keywords: groupBy, autocomplete

[maapteh]

Is the type addition:

export type PartiallyRequired<T, K extends keyof T> = DistributiveOmit<T, K> & {
  [P in K]-?: T[P];
};

intentional, and shouldn't it be, or removed at all.

because

[P in K]?: T[P] would make all properties optional
[P in K]-?: T[P] removes optionality, making all properties required

i have zero clues why this whole complexity is added in the first place, since it was correctly typed...

[ZeeshanTamboli]

@maapteh Please share a live reproduction via CodeSandbox or StackBlitz. Screenshots or code snippets alone are insufficient to diagnose the issue.

Regarding PR #44657:
The change improved the type of groupedOptions in the return of useAutocomplete.

• When the groupBy prop is provided, options are grouped as AutocompleteGroupedOption<Value>[].
• Without groupBy, options remain a flat array of Value[].

This behavior is documented in the groupedOptions JSDoc. Also, refer to the test in PR #44657 for more details.

Could you clarify the exact issue you're facing? A minimal live reproduction will help us assist you better.

Is the type addition:

export type PartiallyRequired<T, K extends keyof T> = DistributiveOmit<T, K> & {
  [P in K]-?: T[P];
};

intentional, and shouldn't it be, or removed at all.

because

[P in K]?: T[P] would make all properties optional
[P in K]-?: T[P] removes optionality, making all properties required

i have zero clues why this whole complexity is added in the first place, since it was correctly typed...

The PartiallyRequired type is intentional and doesn't make all properties required—only the ones specified in K.

For example:

• groupBy is part of K, so when provided, groupedOptions becomes AutocompleteGroupedOption.
• This ensures that groupedOptions aligns with the presence or absence of groupBy.

It’s designed to enforce correct typing dynamically based on groupBy. Let us know if further clarification is needed!

[maapteh]

Now I understand at least why the change is made.
My code is available at typescriptlang.org at #ln266

and based if groupBy was provided we cast it indeed, which is so so as well. But now i see not how i can have an optional prop suddenly required still when using a generic wrapper component for it.

I will change it into: ...(groupBy ? { groupBy } : {}),

So basically when you created a generic wrapper for this component with T, you do not get the benefits of the improved typings, only when you use one single component. Clear.

[ZeeshanTamboli]

@maapteh Yes correct. Should we close this issue then? I don't think there's any improvement that can be done on your custom component, unfortunately.

[maapteh]

No its just an unhappy side effect of making a generic re-usable auto-complete. Thanks for your clarification Zeeshan!

[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

@maapteh 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.