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

Learn
1

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:

2

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
3

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!

4

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

5

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.

6

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!

7

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

8

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.

2 Likes
9

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

10

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