Type errors when using typescript in v6.0.0

Version

6.0.0

Description

When I updated my typescript project to use v6.0.0, there are errors appearing because the generic type of the Option that the AsyncTypeahead and Typeahead components use has been removed. When I remove the generic argument in my code, I get errors in my code because the types of Typeahead’s Option type don’t match my object.

I think the use of the generic type on AsyncTypeahead and Typeahead that was in the DefinitelyTyped types for the v5 version was exactly the right way to do this and it would be great if that was reinstated. This would also ease the upgrade path for typescript projects.

I have put together a codesandbox example that shows the error:

https://codesandbox.io/s/pensive-antonelli-o84wbj?file=/src/index.tsx

In my project, I’m getting errors on the labelKey prop as well. I’m not sure why that’s not showing in my example.

Expected Behavior

It shouldn’t be necessary to bypass the typing system on the onChange prop to get the code to build cleanly.

Actual Behavior

I get this error:

Type 'Dispatch<SetStateAction<StateStat[]>>' is not assignable to type '(selected: Option[]) => void'.
  Types of parameters 'value' and 'selected' are incompatible.
    Type 'Option[]' is not assignable to type 'SetStateAction<StateStat[]>'.
      Type 'Option[]' is not assignable to type 'StateStat[]'.
        Type 'Option' is not assignable to type 'StateStat'.
          Type 'string' is not assignable to type 'StateStat'.ts(2322)

[bggolding]

This doesn’t really feel like a very typescript-y solution: you shouldn’t need to re-type the argument. It will make it more painful for typescript users to upgrade to v6.

[ericgio]

Is it worth contacting the people who did the DefinitelyTyped definitions? They did a really great job there

I’ve taken a look at the DT types and while they did do a nice job, one of the key differences is that they’re only declaring types for the public API. To truly type this library in a comprehensive way, I’d also need to propagate types (specifically option generics) throughout the private API, which is significant.

I’m definitely open to ideas for how to provide type flexibility without significantly impacting the maintainability of the library.