EPISODE · Apr 27, 2020 · 57 MIN
004: JSON Decoders
from Elm Radio · host Dillon Kearns
Basicselm/json package docsElm Guide section on JSON DecodersValidates that data has the expected shape. Similar to the pattern we discussed in episode 002 Intro to Opaque Types.Ports and FlagsHere's an Ellie example that shows the error when you have an implicit type that your flags decode to and it's incorrect.Sorry Dillon... Jeroen won the trivia challenge this time 😉 It turns out that ports will throw exceptions when they are given a bad value from JavaScript, but it doesn't bring down your Elm app. Elm continues to run with an unhandled exception. Here's an Ellie example.Flags and ports will never throw a runtime exception in your Elm app if you always use Json.Decode.Values and Json.Encode.Values for them and handle unexpected cases. Flags and ports are the one place that Elm lets you make unsafe assumptions about JSON data.Benefits of Elm's Approach to JSONBad data won't end up deep in your application logic where it's hard to debug (and discover in the first place)Decouples serialization format from your Elm data typesYou can do data transformations locally as you build up your decoder, rather than passing your giant data structure through a single transform functionDecoding Into Ideal TypesRichard Feldman's elm-iso8601 packageelm/time packageProgramming by intentionJson.Decode.succeed is helpful for stubbing out dataDillon's Incremental Type Driven Design talk at elm EuropeJson.Decode.fail lets you validate data and fail your whole decoder if there’s a problemParse, don’t validate blog post by Alexis KingDillon's elm-cli-options-parser packageJson.Decode.maybe docsNote about Decode.maybe. It can be unsafe to use this function because it can cover up failures. Json.Decode.maybe will cover up some cases that you may not have intended to. For example, if an API returns a float we would suddenly get Nothing back, but we probably want a decoding failure here:import Json.Decode as Decode """ {"temperatureInF": 86} """ |> Decode.decodeString (Decode.maybe (Decode.field "temperatureInF" Decode.int)) --> Ok (Just 86) """ {"temperatureInF": 86.14} """ |> Decode.decodeString (Decode.maybe (Decode.field "temperatureInF" Decode.int)) --> Ok Nothing Json.Decode.Extra.optionalNullableField might have more intuitive and desirable behavior for these cases.Thank you to lydell for the tip! See the discussion in this discourse thread.Learning resourceBrian Hicks' book The JSON Survival KitJoël Quenneville’s Blog Posts About JSON DecodersGetting Unstuck with Elm JSON Decoders5 Common JSON DecodersElm's Universal PatternGuaranteeing that json is valid before runtimeelm-graphql packageThe basics of GraphQLDillon's Types Without Borders Elm Conf talkElm Radio 001 Getting Started with elm-pageselm-pages StaticHttp API docsKris Jenkins' elm-export tool for Haskell types to Elm.Mario Rogic's Evergreen Elm elm Europe talkAutogenerating json decodersjson-to-elm tool - generates Elm decoders from raw JSON valuesintellij-elm JSON decoder generatorOrganizing your decodersEvan Czaplicki's elm Europe keynote The life of a fileEvan's experience report on implicit decoding in HaskellGetting StartedUnderstand Json.Decode.mapUnderstand record type aliases - the function that comes from defining type alias Album = { ... }Submit your question to Elm Radio!
What this episode covers
We discuss the basics of JSON Decoders, benefits compared to JSON in JavaScript, best practices, and how to get started learning.
NOW PLAYING
004: JSON Decoders
No transcript for this episode yet