Ignore evetns from an input element

[janwirth]

How can I ignore events from an input element? Right now I can't figure a way to tag an event with this information.

[ohanhi]

I'm not entirely sure but I think you could use stopPropagationOn on the input to avoid the events from bubbling up.

[adamnfish]

Hi there, I'm trying to achieve the same thing. I'd like to add keyboard shortcuts to my app, but disable them when the user is typing into an input (or theoretically, textarea).

I think the best way to achieve this is to check the tagName of the target in the event's JSON. If it is an input (or another element I'd like to exclude) then I can ignore the message.

This sounds straightforward to add, but unfortunately because so many details of ohanhi / keyboard are private, it doesn't seem to be possible to achieve at the moment. Because the details of parsing (the RawKey constructor) and subscribing (the Up and Down Keyboard.Msg constructors) are both private, there's no way to insert logic in the middle of these two steps.

The RawKey constructor is private and there are no exposed functions that will construct a RawKey, apart from the JSON decoder itself. This isn't a huge deal, but slightly constrains us in our approach. With this in mind I have tried the following approach.

type alias RawKeyboardEvent =
    { rawKey : RawKey
    , tagName : String
    }

rawKeyboardEventParser : Json.Decode.Decoder RawKeyboardEvent
rawKeyboardEventParser =
    Json.Decode.map2
        RawKeyboardEvent
        eventKeyDecoder
    <|
        Json.Decode.at [ "target", "tagName" ] (Json.Decode.string |> Json.Decode.map String.toUpper)

We introduce a new type RawKeyboardEvent that we can parse out of the browser event data. We have our RawEvent and the tag name, so that the application can reject events targeting input elements. So far so good!

Unfortunately, now there's no way for us to hook this up to a working subscription, because the Keyboard.Msg constructors (Down and Up) are not exposed. The only way to create a subscription is to use the exposed subscriptions function, but this in turn uses ups and downs which are themselves hard-coded to use the library's own event JSON decoder.

We can either parse the data and then not subscribe to it, or subscribe to events correctly without being able to parse extra data.

Solutions

1. Exposing Up and Down is the easiest fix here, because then I can create custom Subscriptions that use the RawKeyboardEvent type I have described above and wire it all together myself.

2. A better solution might be to alter this library's API to accommodate this (and related) use cases. This might mean the ability to filter events based on other event properties, or the ability to use a custom decoder that exposes more information to the program's keyboard subscriptions. It'd be worth discussing the goals of the change before diving into an implementation here, but I'm happy to help out with the discussion, design and or implementation if you're interested in this approach.

3. I just copy / paste the entire library into my own codebase and tweak it to expose what I need (which seems to be allowed by the licence). I gather this isn't a super uncommon approach in Elm's ecosystem, but I'd rather avoid it if I can.

Thank you!

[janwirth]

Another thing you can do is

myEvtDecoder = onlyDecodeIfNotFromInputElements eventKeyDecoder
onlyDecodeIfNotFromInputElements =
    Decode.at ['target', 'tagName'] |> Decode.andThen (\tagName -> case tagName of
        'TEXTAREA' -> Decode.fail ""
        'INPUT' ->  Decode.fail ""
        _ -> Decode.succeed ""
    )

You can also accomodate for contentEditable like this: https://github.com/funk-team/funkLang/blob/82b8295bd381fe6235182b5d2f5ecf988e71a42b/src/domMonkeyPatches.js#L34

[ohanhi]

@adamnfish Did you try the stopPropagationOn approach I had mentioned?

[adamnfish]

I'm nervous about knock-on impacts to functionality and accessibility with that approach. Perhaps there are browser extensions or other pieces of important behaviour that depend on those events behaving "normally". I don't have any concrete concerns here, just a general sense of unease about meddling with these important input events. If you have given some thought to this and are confident that there wouldn't be any problems, then perhaps this would be an acceptable solution.

That said, I can't help feeling like "disable keyboard shortcuts when the user is legitimately typing something" is a totally legitimate use-case that's currently impossible to achieve with this library. As above, I'll be delighted to help out with making any required changes to add support. In the spirit of "Elm" I'd rather converse up front to work out the goals and direction of a change instead of diving straight in with a Pull Request, but I'm happy to explore the code and try the latter if you'd prefer!

Thank you for your help and attention!

[janwirth]

@adamnfish my approach won't work for you?