[dependabot]

Bumps @tanstack/solid-hotkeys from 0.10.0 to 0.17.0.

Release notes

Sourced from @​tanstack/solid-hotkeys's releases.

@​tanstack/solid-hotkeys@​0.17.0

Minor Changes

• #199 431094a - Hotkey hints now show only for hotkeys that can fire. useHotkeyHint and the other adapters' hint helpers return false unless a registration of the hotkey can fire: it's enabled, in an active scope, and, for a hotkey on an element, focus is inside that element. Hotkeys registered with enabled: false, hotkeys suspended by an exclusive scope, hotkeys on an element that doesn't have focus, and hotkeys that nothing registered no longer show hints. App hotkeys match their registrations by id, so custom hotkeys still work. To keep the old behavior, call matchesHeldModifiers, which still checks only held keys. The new HotkeyManager.hasActiveRegistration(hotkey) reports whether a hotkey or app hotkey has a registration that can fire.

  Add preventDefault: 'always'. A chord with this option still prevents the browser's action while it can't fire, because it's disabled or its scope is inactive or suspended. For example, a disabled Mod+S no longer opens the browser's Save dialog. It doesn't stop propagation, and it still skips typing in text fields. When another hotkey handles the key, that hotkey's options apply instead. Sequences treat 'always' as true. Set it in default options to apply it to every hotkey. We recommend it for most hotkeys; the sensible defaults guide explains when to leave it off, such as for Mod+C or Tab hotkeys you turn off to hand the key back to the browser. Devtools show always for these hotkeys.

  Registration views now have a status: 'active' when the hotkey is enabled and its scope is active, 'suspended' when its scope is inactive or suspended by an exclusive scope, and 'disabled' when it has enabled: false. To list only the hotkeys that are on, filter by status === 'active' instead of checking enabled and isScopeActive yourself.

  Each adapter has a new API that reads the hotkey manager's scope state and updates when scopes activate or release: useHotkeyScopesState in React, Preact, Vue, Ember, and Octane, createHotkeyScopesState in Solid and on Alpine's createHotkeysScope owner, injectHotkeyScopesState in Angular, getHotkeyScopesState in Svelte, and HotkeyScopesStateController in Lit.

Patch Changes

• Updated dependencies [431094a]:
  • @​tanstack/hotkeys@​0.18.0

@​tanstack/solid-hotkeys@​0.16.0

Minor Changes

• #194 db47b22 - Ship TanStack Intent skills with each package, so coding agents use the library's own APIs instead of hand-written keydown listeners and wrappers. @tanstack/hotkeys includes hotkeys-core and app-hotkeys, and each framework package includes a skill for its bindings. List them with npx @tanstack/intent@latest list.

Patch Changes

• Updated dependencies [db47b22]:
  • @​tanstack/hotkeys@​0.17.0

@​tanstack/solid-hotkeys@​0.15.1

Patch Changes

• Updated dependencies [daecd95]:
  • @​tanstack/hotkeys@​0.16.1

@​tanstack/solid-hotkeys@​0.15.0

Minor Changes

• #189 dd1f39d - Types and functions now follow one naming rule: a hotkey is a chord or a sequence, a chord is keys pressed together, and a sequence is chords pressed one after another. A name with Hotkey alone accepts both kinds. Names for one kind say Chord or Sequence.

  Hotkey callbacks receive a context with the same chord and sequence shapes as registration views. A chord's callback gets { kind: 'chord', hotkey, parsedChord }. A sequence's callback gets { kind: 'sequence', hotkey, parsedSequence } with every step parsed. Before, a sequence's parsedHotkey held only its last step. The recorder's validate context is split the same way: { kind: 'chord', event, parsedChord } or { kind: 'sequence', events, parsedSequence }.

  useHotkey, HotkeyManager.register, the Lit @hotkey decorator, and the other APIs that take one hotkey type the context from the hotkey you pass, so a chord's callback can read parsedChord without a check. Callbacks in useHotkeys arrays, and callbacks typed HotkeyCallback, receive either shape. Check context.kind before reading parsedChord or parsedSequence. A one-step array such as ['Escape'] now gets chord options and chord context, which matches how it registers.

  Sequence steps can be chord objects as well as strings, such as [{ key: 'K', mod: true }, 'C']. The new RegisterableHotkeySequence type describes them. Registered sequences store each step as a string.

  Every step that advances a sequence now calls preventDefault, not only the last one. In ['Mod+K', 'Mod+C'], the browser no longer runs its own Ctrl+K on the first step. stopPropagation still applies only on the last step, so earlier steps reach other listeners. To let the browser act on every step, set preventDefault: false.

  A sequence's progress now clears when its timeout passes, and registration subscribers are notified. Before, progress cleared only on the next key press, so matchedStepCount could stay above 0 after the timeout.

  Renamed:

  • RawHotkey to RawHotkeyChord

... (truncated)

Changelog

Sourced from @​tanstack/solid-hotkeys's changelog.

0.17.0

Minor Changes

• #199 431094a - Hotkey hints now show only for hotkeys that can fire. useHotkeyHint and the other adapters' hint helpers return false unless a registration of the hotkey can fire: it's enabled, in an active scope, and, for a hotkey on an element, focus is inside that element. Hotkeys registered with enabled: false, hotkeys suspended by an exclusive scope, hotkeys on an element that doesn't have focus, and hotkeys that nothing registered no longer show hints. App hotkeys match their registrations by id, so custom hotkeys still work. To keep the old behavior, call matchesHeldModifiers, which still checks only held keys. The new HotkeyManager.hasActiveRegistration(hotkey) reports whether a hotkey or app hotkey has a registration that can fire.

  Add preventDefault: 'always'. A chord with this option still prevents the browser's action while it can't fire, because it's disabled or its scope is inactive or suspended. For example, a disabled Mod+S no longer opens the browser's Save dialog. It doesn't stop propagation, and it still skips typing in text fields. When another hotkey handles the key, that hotkey's options apply instead. Sequences treat 'always' as true. Set it in default options to apply it to every hotkey. We recommend it for most hotkeys; the sensible defaults guide explains when to leave it off, such as for Mod+C or Tab hotkeys you turn off to hand the key back to the browser. Devtools show always for these hotkeys.

  Registration views now have a status: 'active' when the hotkey is enabled and its scope is active, 'suspended' when its scope is inactive or suspended by an exclusive scope, and 'disabled' when it has enabled: false. To list only the hotkeys that are on, filter by status === 'active' instead of checking enabled and isScopeActive yourself.

  Each adapter has a new API that reads the hotkey manager's scope state and updates when scopes activate or release: useHotkeyScopesState in React, Preact, Vue, Ember, and Octane, createHotkeyScopesState in Solid and on Alpine's createHotkeysScope owner, injectHotkeyScopesState in Angular, getHotkeyScopesState in Svelte, and HotkeyScopesStateController in Lit.

Patch Changes

• Updated dependencies [431094a]:
  • @​tanstack/hotkeys@​0.18.0

0.16.0

Minor Changes

• #194 db47b22 - Ship TanStack Intent skills with each package, so coding agents use the library's own APIs instead of hand-written keydown listeners and wrappers. @tanstack/hotkeys includes hotkeys-core and app-hotkeys, and each framework package includes a skill for its bindings. List them with npx @tanstack/intent@latest list.

Patch Changes

• Updated dependencies [db47b22]:
  • @​tanstack/hotkeys@​0.17.0

0.15.1

Patch Changes

• Updated dependencies [daecd95]:
  • @​tanstack/hotkeys@​0.16.1

0.15.0

Minor Changes

• #189 dd1f39d - Types and functions now follow one naming rule: a hotkey is a chord or a sequence, a chord is keys pressed together, and a sequence is chords pressed one after another. A name with Hotkey alone accepts both kinds. Names for one kind say Chord or Sequence.

  Hotkey callbacks receive a context with the same chord and sequence shapes as registration views. A chord's callback gets { kind: 'chord', hotkey, parsedChord }. A sequence's callback gets { kind: 'sequence', hotkey, parsedSequence } with every step parsed. Before, a sequence's parsedHotkey held only its last step. The recorder's validate context is split the same way: { kind: 'chord', event, parsedChord } or { kind: 'sequence', events, parsedSequence }.

  useHotkey, HotkeyManager.register, the Lit @hotkey decorator, and the other APIs that take one hotkey type the context from the hotkey you pass, so a chord's callback can read parsedChord without a check. Callbacks in useHotkeys arrays, and callbacks typed HotkeyCallback, receive either shape. Check context.kind before reading parsedChord or parsedSequence. A one-step array such as ['Escape'] now gets chord options and chord context, which matches how it registers.

  Sequence steps can be chord objects as well as strings, such as [{ key: 'K', mod: true }, 'C']. The new RegisterableHotkeySequence type describes them. Registered sequences store each step as a string.

  Every step that advances a sequence now calls preventDefault, not only the last one. In ['Mod+K', 'Mod+C'], the browser no longer runs its own Ctrl+K on the first step. stopPropagation still applies only on the last step, so earlier steps reach other listeners. To let the browser act on every step, set preventDefault: false.

  A sequence's progress now clears when its timeout passes, and registration subscribers are notified. Before, progress cleared only on the next key press, so matchedStepCount could stay above 0 after the timeout.

... (truncated)

Commits

• 41f06c5 ci: Version Packages (#201)
• 431094a feat(hotkeys): Show hints only for hotkeys that can fire (#199)
• 2172bfc ci: Version Packages (#196)
• db47b22 feat(hotkeys): Ship TanStack Intent skills with each package (#194)
• d30328c ci: Version Packages (#195)
• ad56a4b ci: Version Packages (#190)
• dd1f39d feat(hotkeys): Add hotkey scopes, chord and sequence naming, and new guides (...
• 2a5a38a ci: Version Packages (#188)
• 9263ac7 ci: Version Packages (#186)
• 5ce675b ci: Version Packages (#181)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

This PR is stale. Please trigger a re-run of the PR check action.