Articles from Brian Hicks
Last week Murphy Randle had me on Elm Town as a guest to talk about JSON.
We walked through the Elm
JSON.Decode documentation, and talked about hairy things we’d run into.
If you want a good overview of the landscape for the
JSON.Decode API, give it a listen.
First-time Elm users have a hard time learning how to compose decoders.
People tend to get stuck on what they all mean, but it’s not too hard: just think of them like LEGO.
A recurring theme in the Elm community (and this blog) is that JSON is kind of
difficult to get started with. This makes sense, since it’s all about dealing
with data that other people provide for us. It’s hard to debug what’s happening
with JSON decoders since they’re often used in HTTP response decoders. So today
we’re going to talk about some general advice: how do you even debug JSON?
Sometimes JSON just doesn’t play nice with our nice type systems. Consuming JSON
from a wide variety of sources can be challenging. Even when working with an
internal team you can be dealing with strange encodings. One common pattern is a
JSON object with dynamic keys. How we deal with this depends on the semantics of
the data, but it breaks down into two distinct patterns.
Richard Feldman spoke two weeks ago at the first elm-conf. (it went quite well,
thank you for asking!) He pointed out something as a code smell that’s been
bothering me for a while. I want to emphasize it, so go ahead and watch the
recording and then we’ll talk about it. It’s only 25 minutes and well worth your
There have been several recent questions on the elm-discuss mailing list about decoding large JSON objects.
The problem: Elm’s decoders provide for decoding objects with up to 8 fields, but what happens when you need more?
The solution here is, unfortunately, not super obvious.
Last time we talked about using
|> allow you to create pipelines through with data can flow (like water.)
That’s all well and good, but what if you need pipes without the water?
Well, that’s easy enough to do with function composition!
Say you’ve got a bunch of functions, and you want to use them together.
This is a common situation, but it can get a little… messy.
Let’s take an example from the Elm docs:
scale 2 (move (10,10) (filled blue (ngon 5 30)))
This is, well, just OK.
A little parentheses go a long way, but this is just unclear.
You have to follow them very closely to figure out the evaluation order.
Editor highlighting can help, but wouldn’t it be better to get rid of the problem?
But how do we do that?
Elm is usually pretty clear, but there are certain things that are a little hard to search for.
One of those is the
! operator, introduced in 0.17.
What does it do?
Where does it come from?
And even more important, when should you use it?