Repository navigation
fix(hotkeys): Let sequences own the keys after their first step - #184
Conversation
A key that continues or completes a sequence in progress no longer runs chords for the same key, including its repeats and keyup. Closes #116
🦋 Changeset detectedLatest commit: 86e28ce The changes in this PR will be included in the next version bump. This PR includes changesets to release 18 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
🚀 Changeset Version Preview1 package(s) bumped directly, 17 bumped as dependents. 🟥 Major bumps
🟨 Minor bumps
🟩 Patch bumps
|
@tanstack/alpine-hotkeys
@tanstack/angular-hotkeys
@tanstack/angular-hotkeys-devtools
@tanstack/ember-hotkeys
@tanstack/hotkeys
@tanstack/hotkeys-devtools
@tanstack/lit-hotkeys
@tanstack/octane-hotkeys
@tanstack/preact-hotkeys
@tanstack/preact-hotkeys-devtools
@tanstack/react-hotkeys
@tanstack/react-hotkeys-devtools
@tanstack/solid-hotkeys
@tanstack/solid-hotkeys-devtools
@tanstack/svelte-hotkeys
@tanstack/svelte-hotkeys-devtools
@tanstack/vue-hotkeys
@tanstack/vue-hotkeys-devtools
commit: |
Closes #116
Cchord and aGthenCsequence registered, pressingGand thenCruns only the sequence.Con its own still runs the chord.TargetListenersnow tells the manager which listener runs first.keyupalso skip chords. A missedkeyupdoesn't block the key's next press.sequence-ownership.test.tscovers these cases, and a ReactuseHotkeytest reproduces the issue. Theunified-hotkeys.test.tscase that expected both to fire now expects the chord only on the firstG.minorchangeset.Notes
This matches Mousetrap,
@github/hotkey, and VS Code, where a pending sequence takes the next key. Those libraries drop a chord on a sequence's first key, or let registration order decide; this PR keeps it firing.Summary by CodeRabbit