Allow HotKeys component to autofocus

[ffigiel]

I'd like to be able to have HotKeys autofocus, so I can easily set up global hotkeys.
Proposal: when given an autoFocus prop, HotKeys would render FocusTrap with ref={n => n && setTimeout(() => n.focus())}.

[mendelk]

+1. See also #25, and in particular this comment

[chrisui]

Hey man cheers for the request!

I definitely want to make it easier for global hotkeys as it seems it's quite a popular request and not obvious how to do it. I'm wondering whether autofocus is the right name though since this usually implies it will receive focus initially but can lose it. Ie. if you "auto focus" an input you focus on mount but it's not always focused.

Theoretically this should be possible on Hotkeys using these two props

Just to check could you, on your global top level Hotkeys component, try the following usage:

<Hotkeys focused={true} attach={window} ... />

This is a work around if it works and I will look to make it easier (and document!!) for global hotkeys. My proposal would be for a prop global={true} which implies it catches all events anywhere on the page and doesn't worry about "focus".

[ffigiel]

Yup it works perfectly, thanks!

[ffigiel]

BTW, what if I have some local hotkeys within the global hotkeys scope? will it fire event for both hotkey maps?

edit: I do understand that the best way would be not to design ambiguous hotkeys, I'm just curious

[chrisui]

Theoretically if the local scope is focused and the exact same hotkey sequence is triggered the local one will take precedence.

Ive been toying with the idea of allowing you to say "I actually don't want to handle this so pass it on" inside the handler via some "continuePropagation" api but for now you can at least just call props upwards yourself.

[ffigiel]

That's not my case, actually I'm glad one action cancels out another.

Is focused attach={window} an experimental api, or something I can keep using?

[chrisui]

Yup I implemented that believing it's the most sensible default! :) it's
half of what makes this library useful out the box I reckon.

That api will definitely be supported for the foreseeable future as an
escape hatch with a more modern api on top at some point.

On 27 Aug 2016 17:08, "Filip" notifications@github.com wrote:

That's not my case, actually I'm glad one action cancels out another.

Is focused attach={window} an experimental api, or something I can keep
using?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#41 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA_oAKvS7Qfg3HqNIXuAMBSZt5qXh9D2ks5qkGD6gaJpZM4JgeLg
.

[rajnishcoder]

Hey man cheers for the request!

I definitely want to make it easier for global hotkeys as it seems it's quite a popular request and not obvious how to do it. I'm wondering whether autofocus is the right name though since this usually implies it will receive focus initially but can lose it. Ie. if you "auto focus" an input you focus on mount but it's not always focused.

Theoretically this should be possible on Hotkeys using these two props

Just to check could you, on your global top level Hotkeys component, try the following usage:

<Hotkeys focused={true} attach={window} ... />

This is a work around if it works and I will look to make it easier (and document!!) for global hotkeys. My proposal would be for a prop global={true} which implies it catches all events anywhere on the page and doesn't worry about "focus".

Hi, where I can find list of all attributes like keyMap, focused, attach ?

[greena13]

Hi rajnishcoder,

You can take a look at the TypeScript definitions for the <HotKeys> component, for the latest stable version.

Or for the new pre-release, take a look at the HotKeys API documentation - in this and all future versions, focused and attached are both replaced by the GlobalHotkeys API.