preventing the default key handler

[martindemello]

I need some way to prevent the default key handler from firing if I handle onkeydown. In js_of_ocaml Dom_html.handler takes a function of type event -> bool Js.t so I could use the javascript idiom of returning Js.false to stop the default handler from firing. ocaml-vdom does not expose the return value, and I could not find another way to accomplish this.

(I did see prevent_default bound in js_browser.ml but I could not figure out how to use that either)

[alainfrisch]

Sorry for the late answer. I'm wondering if always calling prevent_default when some handler captures the event would make sense. Does the following diff works for you:

diff --git a/lib/vdom_blit.ml b/lib/vdom_blit.ml
index 08367ff..b263b19 100644
--- a/lib/vdom_blit.ml
+++ b/lib/vdom_blit.ml
@@ -523,7 +523,7 @@ let run (type msg) (type model) ?(env = empty)
           in
           begin match loop attributes with
           | None -> ()
-          | Some msg -> process (mapper msg)
+          | Some msg -> Event.prevent_default evt; process (mapper msg)
           end
       | _ ->
           ()

Or would a stopPropagation be required in your use case?

[martindemello]

in this particular case it would have come to the same thing, since i had no other handlers registered, but stopPropagation sounds more generally useful, and would let the handler itself decide whether it wanted to stop the event from propagating.

the diff you posted does sound like a good default behaviour; at least i can't think of any case where i would want both my handler and the default handler to both be triggered.

[alainfrisch]

but stopPropagation sounds more generally useful, and would let the handler itself decide whether it wanted to stop the event from propagating.

Do you mean, letting each handler return a Boolean to indicate whether to call stopPropagation? I'm concerned with the API, since handler already return a "message". Having all handlers return a pair would be too heavy, and maintaining two pairs of handlers for each kinds (with/without the extra Boolean) does not seem super nice either.

I think I'll merge the suggested diff and wait for a concrete case where something more would be needed.

[alainfrisch]

Mmh, actually, this change breaks the DemoSelection example... Will need more time to investigate.

[alainfrisch]

I guess this is the onkeydown handler. Preventing the default for the event has the unfortunate consequence that the oninput handler is not called.

[martindemello]

ooh, interesting, hadn't thought of adding to an input box being a key handler. (my original use case was to capture the tab key without shifting focus)

how about something along the lines of

| Some msg -> before evt; process (mapper msg); after evt

where before and after were supplied as optional keyword args?

[joprice]

How about the elm solution? https://package.elm-lang.org/packages/evancz/elm-html/4.0.0/Html-Events#onWithOptions