[useAutocomplete] Setting the key as shown in the docs, triggers @typescript-eslint/no-unsafe-assignment

[Mario-Eis]

Search keywords

no-unsafe-assignment useAutocomplete

Latest version

• I have tested the latest version

Steps to reproduce

Steps:

1. Just open the live example with eslint activated: https://codesandbox.io/p/sandbox/fast-dew-mgthpm?from-embed

Current behavior

When doint the workaround for #39833, the eslint rule "@typescript-eslint/no-unsafe-assignment" is triggered because the key is of type "any". Using the "any" type is bad practice. Espacially, when there is a correct type for that usecase available: React.Key

...
const { key, ...optionProps } = getOptionProps({ option, index }); // Unsafe object destructuring of a property with an `any`
return (
    <li key={key} {...optionProps}> // Unsafe assignment of an `any` value.
...

useAutocomplete.d.ts:

  getOptionProps: (renderedOption: UseAutocompleteRenderedOption<Value>) => React.HTMLAttributes<HTMLLIElement> & {
    key: any;
  };

UPDATE: The same is true for the renderOption function Prop

  renderOption?: (props: React.HTMLAttributes<HTMLLIElement> & {
    key: any;
  }, option: Value, state: AutocompleteRenderOptionState, ownerState: AutocompleteOwnerState<Value, Multiple, DisableClearable, FreeSolo, ChipComponent>) => React.ReactNode;

Expected behavior

Keys shold be of type "React.Key" not "any".

[utsavk1993]

Hello,
I would like to work on this issue. Please assign this to me.
Thanks!

[mj12albert]

@utsavk1993 You are welcome to open a PR

[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.

---

@Mario-Eis Thanks again for creating this issue! If you have a moment, we would love to hear your thoughts on how we handled it with this short feedback form.