On Thursday, October 20, 2016 at 7:19:05 PM UTC+1, John Kelly wrote: > > I'm sorry to link drop, but I've been doing a bit of work on a library to > remove some of the boilerplate when writing client code for a REST API. The > library is currently locked in / specific to what is called PostgREST, but > I imagine that the patterns could be applied to any REST backend. Check it > out: https://github.com/john-kelly/elm-postgrest/ > > The core idea is to remove the boilerplate of always having to define > encoder, decoder and schema. Would love to chat. >
What do you do with fields in the json that are missing or null? I can see for example that for an 'int' you just use Decode.int as the decoder, so I guess you will get a Result.Err and fail when the value is missing? This is another awkward corner that needs to be dealt with. Until recently I ignored it, or used a default value like "". But of course "" just defeats the point, so I recently updated all my code to use Maybe fields, and Nothing for missing or null values. Of course, not all values can be missing or null, but for the ones that can be optional in input/output of the API it makes sense. After I went through all the code and updated it to deal gracefully with missing values it felt like the Elm compiler had forced me to much more thorough in accounting for all the possible interactions with the API. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
