I had to grab the value from an input element on blur event (which I have to do a lot…I wish Elm provided it out of the box as it does for input event). Anyhow, I figured out how to do it. The following works:
Html.Events.on takes a Decoder msg as its second argument and JD.map (UpdateRecVal recId currVal) JD.string is a valid Decoder msg. However it will fail to decode an event, as it is not a string, and therefore the message won’t go to update, as documented in Html.Events.on.
Also note that targetValue is just JD.at ["target", "value"] JD.string.
So everything is fine at compile time, the decoder failure only occurs at runtime.
What compilation error would you have expected?
You won’t get a compile time error because both JD.string and targetValue have the same type (Decoder String) so the compiler will let you use them interchangeably.
You might at least expect to get a runtime error when the decoder fails but as you noticed, that doesn’t happen either. Instead, non-decodable events are silently ignored. There are several valid approaches the Html.Events library could have taken to handle decode failures and I’m not sure why this particular one was chosen.
This behavior does have its uses though. Some authors will purposely fail their decoders for events they want to ignore. A common example is creating an onEnter that listens to input events but ignores non-Enter keys. This article walks through building an onEnter using this technique.
Silent failures like this can be really annoying to debug when you aren’t triggering them purposely. It’s possible to write a wrapper decoder that will log any silent failures to the console: Here’s an Ellie example of such a decoder and here is an article that walks through how to build that:
Also, if you’re looking for an intro to writing custom DOM event handlers in Elm, you may find this article helpful . It was written for Elm 0.18 but is still accurate for Elm 0.19.
@joelq Thanks for your responses and for links. Yes, I agree that issuing a runtime error would be desirable. While unrelated to this, I want to say that your article on how to write JSON decoders was very helpful for something I was doing. Will look at the links you have posted.
@dmy I get what you and @joelq are saying about both being Decoder String…but it still seems a little weird that one Decoder String can decode an event and the other cannot. Couldn’t a different type be used for something that know how to decode an event.
Thanks for the replies. As @joel said, it would be useful to have a runtime error shown rather than this failing silently.
. It was written for Elm 0.18 but is still accurate for Elm 0.19.