[joy-ui][Autocomplete] Typescript & React runtime error using Autocomplete

[Onurfesci]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Trying to use Joy UI's Autocomplete in a controlled state as per the docs, I get a TypeScript error:

I also get a runtime error on the browser from React.

I've tried passing objects with value and label as options, passing a value prop, but I also get the same typescript error. It expects it to be an array of string or the inferred type from option. I also get errors if I pass it an array.

Am I using this component wrong, or is there an issue with these types?

Reproduction:
(MUI Joy's own example has type errors)
https://codesandbox.io/s/cp2zmj?file=/Demo.tsx

Current behavior 😯

No response

Expected behavior 🤔

No response

Context 🔦

No response

Your environment 🌎

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

[mj12albert]

@Onurfesci Thanks for reporting this ~ I can reproduce it in our docs example

[auvansang]

I have the same issue as above

[siriwatknp]

I will take a look tomorrow.

[siriwatknp]

Based on the CodeSandbox you provided, I guess there is something wrong with CodeSandbox because I copied the code and put it in my local react-vite (from scratch) + Joy UI without any type errors.

Could you provide the code that you use in your local project?

[auvansang]

@siriwatknp you can check on this codesandbox, press f12, click on the dropdown icon and the error will occur

https://codesandbox.io/p/sandbox/spring-browser-mypv5f

[siriwatknp]

@siriwatknp you can check on this codesandbox, press f12, click on the dropdown icon and the error will occur

https://codesandbox.io/p/sandbox/spring-browser-mypv5f

I tried but what's the error that I should see? Is it related to this issue?

[auvansang]

You can see the issue like bellow, for the issue on the issue "Property id ...", I cannot duplicate it on my codesandbox

[mj12albert]

Looks like a similar issue to #39474

Though I can't reproduce the issue with Joy anymore (even with Next.js like in @sang-au's sandbox) https://codesandbox.io/p/sandbox/sleepy-liskov-fvjhmf?file=%2Fsrc%2Fapp%2Fpage.tsx%3A1%2C1-21%2C1

[Onurfesci]

I copied my implementation as-is to codesandbox, but I'm not seeing the same issues that I'm seeing on my VSCode. Really strange...

Sandbox repro (No TS Errors): https://codesandbox.io/s/billowing-smoke-vpcn32?file=/src/Demo.tsx

Local VSCode (Getting type errors on 3 props: value, getOptionLabel, onChange). The inference seems to be completely different. For some reason, on my VSCode, it is inferring value as an array of string or the inferred option type, rather than the option type itself. If I @ts-ignore, it works perfectly so I'm not implementing it wrong. See the images below.

Type error on value:

Type error on getOptionLabel (Thinks option is the option or a string?):

Type error on onChange:

Notes:

• @mui/joy and typescript are both the latest versions on my repo, same as the codesandbox
• Have tried restarting VSCode, TypeScript server multiple times

Does anybody have an idea why this is happening? Could it be a tsconfig issue with Next.js projects, clashing with Joy's type inferences?

[Onurfesci]

I got the codesandbox above to show some TS errors now. Basically, if the value a string and the options are an array of objects, the Autocomplete isn't happy. So what I want to ask to the Joy team is...

• Is this intentional? Does value HAVE to be the same type as one of the options?
• If this is the case, the isOptionEqualToValue field doesn't have much use
• I think value should be able to be a string, for example an id of one of the options, while the options can be objects of any type
• Perhaps the generic type of AutocompleteProps should allow for another parameter, TValue? This way the default type casting could be overridden if needed? Better yet, I think the default casting of value type should be from the value prop itself

[siriwatknp]

Perhaps the generic type of AutocompleteProps should allow for another parameter, TValue? This way the default type casting could be overridden if needed? Better yet, I think the default casting of value type should be from the value prop itself

I think so, this would let developers gain more control over the types they want. Since this is related to Base UI useAutocomplete, I am tagging @michaldudak and @mj12albert for further discussion.

[michaldudak]

This is already being tracked in #23708.