I’m not familiar with Elm, but that’s a weird limitation and will run into problems using practically all JSON data.
In general I’m not a fan of JSON decoders that insist on parsing into a specific type. It works okay if you’re developing the application that creates the JSON in the first place, because there’s probably already an object, but they’re a real pain to use when reusing JSON from somewhere, like calling a web API or something like that.
The blog post provides 3 solutions out of which 2 actually handle arbitrary sized JSON. The last one is the de-facto standard from what I gathered but I still found the post very informative as someone who just jumped in into Elm and hit that limitation very fast.
As someone who’s only been eyeing Elm in the periphery as something to try out, what is the technical reason for why Elm can only decode 8 fields in a JSON object?
(I did a cursory search for “why is elm limited to decoding 8 fields?” and related phrases, but nothing in the first few pages seemed to answer the question directly).
It’s not limited. The language just ships with 8 convenience functions for parsing objects like that. Since defining those for parsing objects seems a bit complicated. I just submitted a link to a second blog post that goes into a bit more detail on how the objectN constructs are built: https://lobste.rs/s/ma48ik/decoding_larger_json_objects_elm_0_15_2015
Regarding parsing more fields without going through things like above the decode pipeline is a very nice and easy things to use.
It’s worth noting that you do not need to decode anything into a type. Use of Json.Decode.value allow you to keep things as json until you need a particular field, e.g "name". That way your JSON is as flexible as you want it to be, and there is no structure forced upon you. You just have to handle the case when no name is found lower down in the tree.
It’s worth noting that it’s quite often useful to nest decoders, or even chain a decoder onto another one. The main problem with doing that is that your code can often produce lackluster error messages as a result.
Something else that’s missing from this post is a link to http://json2elm.com, which can help automate a lot of the converstion for you when you have a large JSON object and you’re not sure where to start. It’s not perfect and needs a lot of work but it can help.