Really enjoying using miniBill/elm-codec, but I’m curious if there’s an equivalent way of doing this:
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:
|> Codec.field "data" identity (Codec.list codec)
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
I suppose you could just make a helper function for it? Something like:
fieldCodec : String -> Codec a -> Codec a
fieldCodec name codec =
|> Codec.field name identity codec
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!
miniBill/elm-codec expose a way of building one directly from a
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!
Naming the function
codec would have been a pain for the implementation.
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.