I thought about posting this as an issue for the elm/file package, but I am not sure if it is right there. So I’ll just write this here and hope you have some feedback for me and/or this issue.
We just debugged a silly mistake which was really hard to find, because the on “change” function fails silently when you mess up your Decoder. I made a small example (stolen from the docs):
The first tries to decode the files field as a list, the second one as a single file element. In the broken version the Msg is just not triggered. Our somewhat new elm dev was pretty frustrated with this behaviour. What do you think, is this something that could/should be fixed? Could we make elm not just silently swallow the error? Or write it in the docs? The mean thing is, the docs for on say:
When an event occurs, the decoder tries to turn the event object into an Elm value. If successful, the value is routed to your update function.
Thanks, that sounds like an awesome best practice for json decoders. I am probably spoiled because I’ve always controllen the API I was working with when writing elm frontend code, but out there in the wild you should probably always do that.
With that pratice in mind it seems less important for that error to get more vocal, but I still think that it is bad that this particular error is just silent. I would expect a huge warning sign in the docs at least. Is it me, or do others think so too?
Json decoder failures are always present when dealing with http calls. (It will produce a BadBody error) The silent failure is only when dealing with decoding events. That silent failure is actually a feature because it allows one to not generate messages on certain event conditions.
It is a very, very small “feature” since adding a no-op message is trivial. I think compiler-enforced error checking is worth this small inconvenience in the same way it is for http requests.