miniBill/elm-codec - How to do `Json.Decode.field "data" decoder`?

Really enjoying using miniBill/elm-codec, but I’m curious if there’s an equivalent way of doing this:

decoder =
    Json.Decode.field "data" decoder

Basically, I have this one-off scenario of an http result that comes back on "data" that I need to decode my domain-specific value off of. So far, the best I’ve come up with is this:

decoder_ =
    Codec.object identity
        |> Codec.field "data" identity (Codec.list codec)
        |> Codec.buildObject
        |> Codec.decoder

Really, the only part that feels weird is the use of identity and the fact that it’s a good bit more verbose that the Json.Decode version. Anyone have a better way using elm-codec? @miniBill, your input would be much appreciated if you happen to see this. Happy to hear from anyone else too :slight_smile:

I suppose you could just make a helper function for it? Something like:

fieldCodec : String -> Codec a -> Codec a
fieldCodec name codec = 
    Codec.object identity
       |> Codec.field name identity codec
       |> Codec.buildObject
1 Like

I’d just use Json.Decode directly. elm-codec is useful to guarantee that encoders and decoders are symmetric and to have a nice-ish api for custom types.
In this case… it gets you no advantage.

Or you could do what @rupert suggested of course!

I see. Makes sense. Just wanted to make I wasn’t overlooking something. Thanks for taking a look!

Could miniBill/elm-codec expose a way of building one directly from a Decoder and Encoder. Something like

codec : Decoder a -> Encoder a -> Codec a

For situations where you want to do something a bit unusual, but still be able to create a Codec, in order to be able to combine it with other Codecs.

The downside is that it becomes possible to accidentally create a Codec that is not symmetrical; perhaps ok if it is explained clearly in the docs for this constructor - the caller takes on a small risk in order to do something more unusual.

Another advantage would be that it makes miniBill/elm-codec extensible. If I write my own symmetric encoder/decoder pair, I can hook it in.

I would want to do this when there are several choices in how to encode custom types into JSON, and I am forced to use a different scheme to what elm-codec uses because the JSON data model I have does it a different way.

I’ve resisted adding a codec function because in my original plan elm-codec would allow you to also build byte codecs (in the meantime I’ve helped @MartinS craft MartinSStewart/elm-codec-bytes, so that’s no longer applicable) or other things. After seeing how people use it, and how I use it myself, I think I can actually expose it. Look forward to a new release!

I guess I’ll add a codec function as well to keep the API’s relatively consistent?

miniBill/elm-codec 1.2.0 is out now!
It adds fail, andThen, lazy, value and build.
Naming the function codec would have been a pain for the implementation.


Sure, build is perfectly good name for it too. Thanks.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.