Brian Hicks
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.
Read onRichard 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 time:
Read onThere 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.
Read onLast time we talked about using <| and |>.
<| and |> 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?
Read on