My first days and weeks with Elm were painful. Embracing the unknown is hard, and moving from the cozy environment like Python and React to the rough waters of functional programming was like the first bungee or parachute jumps for me. Why do it if the demand for Python, Java, React engineers is so high and Elm is almost non-existent? Because Elm can either teach you something new and make a better developer, or, as Paul Graham said, it can even become your secret weapon.
It took me a while to understand how JSON encoding and decoding works in Elm. Who am I kidding, it took me a while to understand many concepts in Elm. This is a special issue about JSON. Every 5th issue I am covering one particular topic.
My learning journey into Elm started with the Elm Programming book which is an amazing and free resource that explains concepts extremely well. It has two chapters that introduce you to the concept of decoders, functions that translate JSON values into Elm types.
The first part explains how to use primitive decoders for converting an array of strings, integers, floats into a corresponding Elm data structure. The second part goes into more detail with complex structures using NoRedInk/elm-json-decode-pipeline package that simplifies the parsing of JSON objects by allowing you to use pipeline operator. Here's a little snippet from the book to give you an idea:
José Muñoz has written an introductory blog post with a simple real-life example on parsing JSON. When you're stuck with the topic, it's always good to get another perspective on the problem, or get it explained with different words or examples. The "Converting JSON with Elm" is just that.
My second go to resource for everything Elm was the blog of Alex Korban who has huge number of topics covered, including the JSON parsing.
As I was reading about JSON decoders and the
map series of functions to parse objects with up to 8 fields, I kept wondering how to parse objects with more fields? What if you have 10, 20, or even 30? Here Alex gives some tricks to do just that. And another take on the same problem from Michel Belleville in the article "One field too many". If you've got some nested record fields, especially with repetitive or even recursive structures, Alex has nice very good explanations here and here.
When you write a simple decoder, you expect it to succeed in parsing, or have a general failure. When you have nested decoders, you might want some flexibility in terms of knowing what failed and where, and maybe you want to handle that error in a different way? This is how optional fields work. In Juicing JSON, andThen some Michel explains how you can use
andThen while parsing your JSON data.
I've been talking only about decoding JSON, but what if you need to do it the other way around? Well, the same rules and similar practices apply. Here's how to encode your Elm structures back to JSON.
In this blog post I am going to walk through fetching data from a JSON API with Elm. When I started learning Elm this was a pain point for me. I have also been trying to introduce others to Elm and I haven't found enough complete examples to give to people.
The above is an intro to the Fetch data with Elm from JSON Placeholder article by Ryan Frazier. It is comforting to know that I'm not the only person to whom this topic is hard for understanding, there are people like me. Ryan is using a real project with API to explain how to decode the data into JSON.
You can generate your decoders from the JSON schema easily with JSON2Elm app. Just paste your JSON, select the decoder type, either original or pipeline, and voila! Neat, isn't it?
If you're still lost, here's a super-quick and simple intro from Zachary Kessin who has lots of tiny videos explaining other aspects of the language too
Dillon Kearns and Jeroen Engels also did a very details episode about JSON Decoders on Elm Radio podcast.
And finishing this issue off with the quote of the week:
A great poet belongs to no country; his works are public property, and his Memoirs the inheritance of the public
By Lord Byron