strict type for aria combobox #6167
Conversation
| @@ -86,7 +86,7 @@ export function useComboBox<T>(props: AriaComboBoxOptions<T>, state: ComboBoxSta | |||
| ); | |||
|
|
|||
| // Set listbox id so it can be used when calling getItemId later | |||
| listData.set(state, {id: menuProps.id}); | |||
| listData.set(state, {id: menuProps.id || ''}); | |||
There was a problem hiding this comment.
it seems a bit off but would love some idea on this one
There was a problem hiding this comment.
I think this is fine, you could also do menuProps.id! because we know that useMenuTrigger always returns an id on menuProps
now there's an obvious problem with this that I think you're alluding to, which is, useMenuTrigger could stop returning an id in that object. however, we have tests which catch this, so I'm not too concerned
| @@ -45,7 +45,7 @@ export interface MenuTriggerAria<T> { | |||
| * @param state - State for the menu trigger. | |||
| * @param ref - Ref to the HTML element trigger for the menu. | |||
| */ | |||
| export function useMenuTrigger<T>(props: AriaMenuTriggerProps, state: MenuTriggerState, ref: RefObject<Element>): MenuTriggerAria<T> { | |||
| export function useMenuTrigger<T>(props: AriaMenuTriggerProps, state: MenuTriggerState, ref?: RefObject<Element>): MenuTriggerAria<T> { | |||
There was a problem hiding this comment.
I don't think useMenuTrigger should have its ref as optional, it would interfere with longpress handling and arrow keys.
@devongovett how would you feel if combobox used useOverlayTrigger directly? it doesn't need longpress behavior
There was a problem hiding this comment.
At a glance moving to using useOverlayTrigger seems feasible, pretty similar to what we do for MobileCombobox. Like you said, we don't need the long press stuff so we'd only need to copy over the id/pressProps stuff from useMenuTrigger into useComboBox.
There was a problem hiding this comment.
hi do you want me to contribute useOverlayTrigger change.
There was a problem hiding this comment.
Definitely feel free to give it a shot if you'd like! It would be good to know if something I'm overlooking would breaks with that change, just haven't had time to try it myself
There was a problem hiding this comment.
oh okay so there is these 2 props -
- aria-labelledby which would break with using only overlay trigger and doesnt make sense to have arial labeled by in overlay trigger
- onKeyDown - this im assuming is invoked whenever you press any key and it shows the combobox with relevant list item
Both of these props dont fit in useOverlayTrigger.
We can do either of these -
- make non null assertion for the useMenuTrigger invocation in useCombobox
- Keep the ref optional.
I don't think useMenuTrigger should have its ref as optional, it would interfere with longpress handling and arrow keys.
On this point by @snowystinger would that not be true for arrow keys for combobox? Ignoring the longpress handling which doesnt make sense for combobox
- create a sepeate trigger hook that takes in relevant combobox hook
solves all problem but with code duplication as the new hook would essentially by useMenuTrigger without the required prop
There was a problem hiding this comment.
apologies about the delay, mind clarifying these two:
aria-labelledby which would break with using only overlay trigger and doesnt make sense to have arial labeled by in overlay trigger
Could we set up a useId call in useComboBox and use that for the trigger id and the menu's aria-labelledby and override the ones that will be provided by useOverlayTrigger?
onKeyDown - this im assuming is invoked whenever you press any key and it shows the combobox with relevant list item
similar to above, perhaps we could copy over the menutrigger's onKeyDown over to useComboBox as well?
There was a problem hiding this comment.
hi sorry, been busy with work. will try your suggestions soon thanks for guidance.
| @@ -86,7 +86,7 @@ export function useComboBox<T>(props: AriaComboBoxOptions<T>, state: ComboBoxSta | |||
| ); | |||
|
|
|||
| // Set listbox id so it can be used when calling getItemId later | |||
| listData.set(state, {id: menuProps.id}); | |||
| listData.set(state, {id: menuProps.id || ''}); | |||
There was a problem hiding this comment.
I think this is fine, you could also do menuProps.id! because we know that useMenuTrigger always returns an id on menuProps
now there's an obvious problem with this that I think you're alluding to, which is, useMenuTrigger could stop returning an id in that object. however, we have tests which catch this, so I'm not too concerned
related to #3183
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: