After reading Evan’s post on the matter, 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 and the underlying Dom.LowLevel module.
Our motivations were the following:
- Globally subscribe to keyboard events in a way that we can set
StopPropagation and PreventDefaults similarly to the Html.Events implementation
- The Keyboard package currently uses the
keyCode property instead of the code property. 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?
