-
Notifications
You must be signed in to change notification settings - Fork 1.4k
feat: add onKeyDown prop to ListBoxItem for custom keyboard handling
#9181
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
Open
hasegawa-101
wants to merge
18
commits into
adobe:main
Choose a base branch
from
hasegawa-101:issue-8732
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+28
−5
Open
Changes from all commits
Commits
Show all changes
18 commits
Select commit
Hold shift + click to select a range
d2b7a2c
Add `onKeyDown` prop to ListBoxItem for custom keyboard handling
hasegawa-101 b404954
Update type annotation in ListBox example and fix style formatting in…
hasegawa-101 dfd80e1
fix: remove custom keyboard handling example from ListBox docs and story
hasegawa-101 49e754d
test: add unit tests for `onKeyDown` prop in ListBox component
hasegawa-101 330d9a3
Merge branch 'main' into issue-8732
hasegawa-101 00f7be5
test: remove redundant assertions for `onKeyDown` in ListBox tests
hasegawa-101 e7356f7
test: update `onKeyDown` tests in ListBox to use user-event for bette…
hasegawa-101 2fbcf50
Add `onKeyDown` prop to ListBoxItem for custom keyboard handling
hasegawa-101 139f601
Update type annotation in ListBox example and fix style formatting in…
hasegawa-101 f1d2493
fix: remove custom keyboard handling example from ListBox docs and story
hasegawa-101 299d78c
test: add unit tests for `onKeyDown` prop in ListBox component
hasegawa-101 0c8979b
test: remove redundant assertions for `onKeyDown` in ListBox tests
hasegawa-101 81ccc92
test: update `onKeyDown` tests in ListBox to use user-event for bette…
hasegawa-101 416ceee
Merge remote-tracking branch 'origin/issue-8732' into issue-8732
hasegawa-101 cded5a0
chore: remove unnecessary blank lines in ListBox story
hasegawa-101 175fc31
chore: remove trailing blank line in ListBox story
hasegawa-101 e9bd591
Merge branch 'main' into issue-8732
snowystinger d54a2d2
Add tests and move to useKeyboard
snowystinger File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question to team, do we want to use useKeyboard for this, it stops events by default so we MUST call continuePropagation here for the "Escape" key to clear the selection.
This is not ideal because it causes the event to continue by default instead through all other event handlers. See my thoughts on this in the description of #8775
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, maybe I’m remembering something wrong but isn't that only an issue because the handlers further up do not consistently
useKeyboardthemselves?If that were the case propagation wouldnt flow upwards uncontrollably, since it would be stopped at every level if not explicitly continued.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point, I might've been thinking about it wrong. Looking at https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/interactions/src/createEventHandler.ts which would be called each time useKeyboard is used it looks like the previous
continuewould be overwritten and stop would be called.I still do not like that users would need to know all the keys they should continue for the ListBox to work though. So I'm still not sure about using useKeyboard here.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why a user wouldn't just call
continuefor any key, besides the ones with explicit purpose in his custom event handler. The same should be done in our parent handler, akacontinueon everything we don't explicitly want tostopfor. It basically translates to the exact thing you proposed in #8775, where there is an explicit intent ofI do not want collisions to this keyattached to anystopand yet we do not continue uncontrollably because we still need to think about callingcontinueexplicitly every time we add a new handler.I guess you could still argue that the user would have to know there is some keyboard interactivity that he may break if he doesn't
continuein his handler, but I figure that would be discovered rather quickly.