feat: Keyboard shortcut handler#9929
Conversation
# Conflicts: # packages/react-aria/src/selection/useSelectableCollection.ts
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
|
||
| const isSelected = selectedKey === key; | ||
|
|
||
| let onKeyDown = (event) => { |
There was a problem hiding this comment.
This seems just designed to skip arrow down and up, i think it'd be better to do this in the keyboard delegate or just allow it, i'm not sure why we wouldn't, there could be vertical steplists and it's a nice non-rtl dependent set of keys.
Just removing it for now as it'd make debugging difficult anyways
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
| state.setAnchorDate(null); | ||
| } | ||
| break; | ||
| return false; // TODO: is this really correct? or should it return true when we cancel and only propagate if there's nothing to do |
There was a problem hiding this comment.
Should we return true inside the if statement? Was there a test that broke?
There was a problem hiding this comment.
yeah, react-spectrum/test/datepicker/DateRangePicker.test.js:439:28
| 'shift', | ||
| 'alt', | ||
| 'ctrl', | ||
| 'control', |
There was a problem hiding this comment.
are control and ctrl different? should we standardize on one? I believe the standard e.key is Control
There was a problem hiding this comment.
nope, same thing, happy to standardize
There was a problem hiding this comment.
though, just food for thought, it's e.ctrlKey, not e.controlKey
|
|
||
| const isSelected = selectedKey === key; | ||
|
|
||
| let onKeyDown = event => { |
There was a problem hiding this comment.
Not sure why my comment is marked as changed/obsolete #9929 (comment)
|
Build successful! 🎉 |
| break; | ||
| case 'Escape': | ||
| // TODO: can remove this when we fix collection event leaks | ||
| // TODO is this one covered by a test? did my changes to have a default stop on portals break this? |
There was a problem hiding this comment.
basically, need to test this one, manually to double check. Since unit tests are potentially inaccurate on this due to events having explicit targets and properties set by us. Make sure to open submenus in RAC and S2 and close multi level's with Esc. I didn't find any differences, but I'll move this to the description instead as part of testing.
|
Nevermind, it's only being skipped if it's through a portal, is a repeat that's not allowed or is a composing event that isn't allowed at the moment. The rest of the time it's called. So we can debate this some more. |
# Conflicts: # packages/react-aria/src/combobox/useComboBox.ts # packages/react-aria/src/selection/useSelectableCollection.ts
|
Build successful! 🎉 |
|
Build successful! 🎉 |
## API Changes
@react-aria/interactions/@react-aria/interactions:KeyboardProps KeyboardProps {
+ allowComposing?: boolean
+ allowRepeats?: boolean
isDisabled?: boolean
onKeyDown?: (KeyboardEvent) => void
onKeyUp?: (KeyboardEvent) => void
+ shortcuts?: KeyboardShortcutBindings
} |
Closes
Aiming to help us solve the issue of event leaks, this will allow us more fine grained control of what useKeyboard blocks/prevents default on in a more declarative way.
New behaviour is opt in through
shortcutsinuseKeyboard. This will preventDefault and stopPropagation if the associated function in the map returns true. Or it will let the event pass without altering it if false is returned. In addition, an object can be returned to alter that behaviour in whatever way necessary. Given that all key combinations are exclusive matches, this should make it more obvious what events are continuing or not.✅ Pull Request Checklist:
📝 Test Instructions:
One chain of events that was hard to track was submenutrigger Esc handling. Make sure to manually test this.
🧢 Your Project: