# Replacing native code: Keyboard package

**URL:** <https://discourse.elm-lang.org/t/replacing-native-code-keyboard-package/976>\
**Category:** Learn\
**Created:** [March 22, 2018, 3:21pm UTC](https://discourse.elm-lang.org/t/replacing-native-code-keyboard-package/976 "2018-03-22T15:21:56Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![gaborv](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/gaborv/32/340_2.png) [@gaborv](https://discourse.elm-lang.org/u/gaborv)\
**Post date:** [March 22, 2018, 3:21pm UTC](https://discourse.elm-lang.org/t/replacing-native-code-keyboard-package/976/1 "2018-03-22T15:21:56Z")

</div>

After reading [Evan’s post on the matter](https://discourse.elm-lang.org/t/native-code-in-0-19/826), I thought this was a good time to go through our code base and check where we use native code or effect managers, and why.

Our code base is approx. 17K lines of Elm code, it is a realtime remote-support tool, which provides remote desktop capabilities as its most important feature.

We use native code for 5 different things. There are two of those, which I find tricky to get rid of, so I decided to follow Evan’s advice: I would like to share the specifics here in two separate threads and get advice.

…

**This thread is about keyboard capabilities.**

Basically we created a fork of the [Keyboard package](https://github.com/elm-lang/keyboard/blob/1.0.1/src/Keyboard.elm) and the underlying Dom.LowLevel module.

Our motivations were the following:

1. Globally subscribe to keyboard events in a way that we can set `StopPropagation` and `PreventDefaults` similarly to the [Html.Events implementation](http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Events#onWithOptions)
2. The Keyboard package currently uses the [`keyCode` property](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode) instead of the [`code` property](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code). Although `keyCode` has wider support across browsers, it is deprecated, and `code` seemed to be more reliable across platforms in the supported browsers (Chrome / Firefox).

Moving this logic to JavaScript via ports feels weird considering that the package exists.

Perhaps this a good case where we could contribute to an enhanced version of the `Keyboard` package. However, I did not feel very confident about our current solutions for either #1 or #2. I find them too ad-hoc, and are not based on enough research/discussion/experimentation, so I did not find them worthy of sharing.

(Our solution for #1 is to pass down an `Options` record (similarly to `Html.Events`). But this does not feel like such a great design for general use, since if you have more than one subscription and one of them sets `StopPropagation` this would result in some indeterministic behavior.  
In terms of #2 we would need to do more cross browser/platform research.)

What would you suggest for this use-case?

---

<div class="post-metadata">

**Author:** ![luke](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/luke/32/709_2.png) [@luke](https://discourse.elm-lang.org/u/luke)\
**Post date:** [March 22, 2018, 4:02pm UTC](https://discourse.elm-lang.org/t/replacing-native-code-keyboard-package/976/2 "2018-03-22T16:02:28Z")

</div>

First, I want to thank you for the clarity and specificity of this thread! This is the most useful kind of conversation we can have on this topic right now.

I have a question, and also what is possibly a very straightforward solution depending on your answer:

Is the call to `stopPropagation` critical to the functionality if your event handler is at the level of the document or the window? I frequently just call both out of habit, but my understanding is that `stopPropagation` prevents events from bubbling upward. If that is true, then it doesn’t seem important when the handler is on the document or window.

If you can test and confirm that only being able to `preventDefault` would be sufficient for case #1, then the good news is you can just wait until the 0.19 alpha to switch over to trying some new functionality it will provide. You’ll be able to subscribe to any event on the window or document, decode the event however you would like (so you can use `code` instead of `keyCode`), and optionally prevent default behavior.

If `stopPropagation` is also important to you, the solution may end up being to use ports but we can keep talking to make sure all of your concerns are understood.

EDIT:  
The reason `stopPropagation` isn’t provided for these global event subscriptions is because of that understanding of what that method does. It would be useful to know if there is a use case or auxiliary behavior of `stopPropagation` that we don’t know about that would make it worthwhile to include. An SSCCE for that would be the most helpful thing.

---

<div class="post-metadata">

**Author:** ![gaborv](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/gaborv/32/340_2.png) [@gaborv](https://discourse.elm-lang.org/u/gaborv)\
**Post date:** [March 22, 2018, 4:21pm UTC](https://discourse.elm-lang.org/t/replacing-native-code-keyboard-package/976/3 "2018-03-22T16:21:23Z")

</div>

Thanks, for your quick reply! I think your suggestion will work for us. I believe there is no need to call `stopPropagation`, but I will run some tests on that tomorrow and share the results here.

---

<div class="post-metadata">

**Author:** ![luke](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/luke/32/709_2.png) [@luke](https://discourse.elm-lang.org/u/luke)\
**Post date:** [March 22, 2018, 4:22pm UTC](https://discourse.elm-lang.org/t/replacing-native-code-keyboard-package/976/4 "2018-03-22T16:22:39Z")

</div>

Cool! If it ends up working then don’t feel a need to use your valuable time to reply. We’ll assume that no news is good news.