The State of Elm 2017 results are here!
I first presented these as two talks, one to Elm Europe and one to the Oslo Elm Day.
I’ve embedded the Elm Europe talk below (it’s shorter) but the longer version is on also YouTube.
So you’re sending dates through ports in your Elm application, and things are getting pretty confusing.
You send in a date, and you get…
Err "Expecting a String a _.date but instead got \"2017-05-01T12:45:00.000Z\""
Isn’t that a string already?
What’s going wrong here?
How do you keep your JSON encoders, decoders, and model in sync?
You can skip fields in your encoder, right?
But should you?
And what about when you add new fields?
Decoders are a little easier, but you have to sync them up with your encoders or you’ll lose data.
And the worst part is that we can’t rely on the compiler to catch these classes of errors… argh!
This is a perfect situation for property tests (fuzz tests in
The test system will keep us honest by giving us random values to test with.
You can assert that encoders and decoders mirror each other, and add a bit more safety to your app.
Working with ports can be awkward.
You’re really limited as to what values you can send through, so how do you get objects?
Easy: write a JSON Decoder!
After the sets series finished, I got really curious…
How fast were these sets, exactly?
I had to shave a lot of yaks to answer that question, but to sum up: Elm now has a benchmarking library!
Let’s take a look at how to use it!