[BUG] Scoped hotkeys still trigger when scope is not active

[ckpearson]

Describe the bug
When creating a hotkey and setting the scopes option to restrict the hotkey to a specific scope, the hotkey triggers regardless of what the active scope is.

In fact, I'm not even sure the scope is being set against the hotkey as when the context's hotkeys collection is dumped there isn't any scopes value against it.

To Reproduce
Repro codesandbox here: https://codesandbox.io/s/react-hotkeys-hook-scopes-not-working-yny6kl?file=/src/App.tsx

Expected behavior
I would expect the scoped hotkey to only trigger when one of the scopes it is set to use is active

Screenshots
N/A

Desktop (please complete the following information):
N/A - happens across windows & osx in chrome & safari

[ckpearson]

After a little bit of experimentation I think this might be a case of scope behaviour being a little unintuitive.

When setting the initiallyActiveScopes to {["none"]} I can see that the a hotkey (unscoped) still triggers, but the m hotkey (scoped to "tens") no longer does.

I think what's happening is that even though the wildcard scope * is no longer in the active scopes collection, any hotkey that is in the wildcard scope still runs, this kind of makes sense but is a little unintuitive.

From this perspective I can sort of see why my scoped hotkey was running when the wildcard scope was active (no initiallyActiveScopes set), because the wildcard scope matches all hotkeys.

I guess I was under the impression that the wildcard scope behaved just like every other scope, and therefore when it wasn't active, hotkeys that were unscoped would also be disabled.

I suppose then, the way to achieve the behaviour I'm after would be to ensure that none of my hotkeys are in the wildcard scope (unless I truly want them available at all times), and to ensure that I set the initiallyActiveScopes to be the ones I consider to be "global".

tl;dr:

• The wildcard scope is always technically active, even if it doesn't appear in the active scopes collection
• Hotkeys that aren't explicitly scoped belong to the wildcard scope, and therefore are always available
• Scoped hotkeys are also in the wildcard scope, but only in the specific circumstance where the wildcard scope is in the active scopes collection
  • This is where the unintuitive behaviour comes from

[JohannesKlauss]

Yes this behavior will change in version 5.

[isaachinman]

@JohannesKlauss I have just run into this behaviour myself.

My use case is probably a pretty common one:

1. Global hotkeys for arrow navigation
2. When a user focuses an input, override the global arrow hotkeys and perform a different action

Thus far I have been unable to get this working in an easy way. I think the easiest "API" for users is to simply rely on nesting for specificity. That is, the highest-level HotkeysProvider has the lowest priority, and any nested HotkeysProvider within it will override.

Alternatively, you could literally just expose a priority: number property.

Any estimate for v5 landing, and what are the proposed changes?

[JohannesKlauss]

A prerelease is already published under 5.0.0-1 I don't know if and when I'll be able to finish it, since I just don't have time for this project anymore.

[isaachinman]

Thanks, I see that release here:

https://github.com/JohannesKlauss/react-hotkeys-hook/releases/tag/v5.0.0-1

I see the change to activeScopes, but not sure I understand it. Would you be able to give an extremely brief example of how to achieve the use case I outlined above?

How could we easily "override" global scope hotkeys when some condition is met? It seems to me users will have to maintain global state outside of react-hotkeys-hook and then manually update all the HotkeysProvider instances when conditions change.

Edit: In other words, from what I can tell, there is no declarative way to enable or disable scopes. It only works through imperative function calls like disableScope. I do think a cleaner implementation could be a priority: number property.

In regards to maintenance – this package is used by 23k projects at least. I myself am a very happy (albeit very recent) user. I am sure we could make a successful call for sponsorship, or else find other potential maintainers willing to step up. You have a great thing here!