-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add value type generic to ComboboxOptionsProp #3394
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Hey! Thanks for the PR, I think we should use The additional type is definitely a breaking change because the default value will only work if you don't pass anything. So if you currently have What do you think about this (breaking) change, @thecrypticace? I don't hate this change honestly, but the only thing that might not be as ideal is that the type exists but it is only used when in virtual mode, which is why I like typing it inside of the render prop function directly. But I can be convinced of this change though! |
Sounds good RE: The additional generic type should be fine for backwards compatibility, it'll pick up the default "any" in the situation where a consumer has interesting, I see what you're saying. I think long term unifying the usage pattern between virtual and non virtual could be good. Or maybe allow non-virtual combobox'es to pass options + template function instead of rendering option nodes. But I'm totally content with how it works now. |
Adding a generic here lets consuming code specify a type for an option. This is useful when operating in virtual mode and passing a callback as a child. To get it to be well typed consumers would do something like: ```jsx type Person = { name: string }; <ComboboxOptions<'div', Person>> {({ option }) => <div>{option.name}</div>} </ComboboxOptions> ``` Getting nice strong typing on option. Slightly nicer to specify a generic type then force a cast in the callback imo. Also in situations where somebody is combining multiple combobox components in some generic component they can very logically apply TValue here and in other places too.
Hey @RobinMalfait I was wondering if you had a chance to review my updates? I swapped it to default to any so it should be completely backwards compatible (as I kind of showed in the typescript playground linked above). |
Already closed but I'm linking this issue, because it's what I found first and almost forgot to check the PRs. |
Hi I'm back 👋, another small typescript tweak, no functionality change.
Summary
Adding a generic here lets consuming code specify a type for an option. This is useful when operating in virtual mode and passing a callback as a child. To get it to be well typed consumers would do something like:
Getting nice strong typing on option. Slightly nicer to specify a generic type then force a cast in the callback imo. Also in situations where somebody is combining multiple combobox components in some generic component they can very logically apply TValue here and in other places too.
Notes
I defaulted this new generic type to
unknown
which is definitely a type "breaking" change. someone upgrading will possibly experience a compiler error. As the old type foroption
wasany
. imounknown
is definitely the correct choice here to force the consumer to make a decision on what their thing is.. but I can also appreciate not wanting to break backwards compatibility. So feel free to update it to default toany
(in both places) or I can, if that is what you want.We have this in our codebase right now:
And it would be pretty nice to support this in headlessui-react! thank you!