Re: [elm-discuss] Is a decoder the right level of abstraction for parsing JSON?

[Kasey Speakman]

Yes, but it requires me to keep decoder/encoder files, and fiddle with them
every time my types change. What a waste of time.

Using this method, I don't have to do anything extra when types change. Nor
keep extra files.

On Sat, Mar 18, 2017 at 11:43 AM Noah Hall  wrote:

> Http://json2elm.com. auto generating json "codecs" (decoders and
> encoders) has existed for more than a year already.
>
> On Friday, March 17, 2017, Kasey Speakman  wrote:
>
> Another update. I figured out how to get the encoders and decoders out of
> the ports using a native module. So I no longer have to actually send
> things across ports (still have to declare them). I can also now use Elm's
> Http module.
>
> Here's a gist of what it takes:
>
> https://gist.github.com/kspeakman/3f9521b0921b352c7d656261ec0a8fa6
>
> On Saturday, February 18, 2017 at 2:22:32 AM UTC-6, Kasey Speakman wrote:
>
> An update. I'm using the ports approach to deal with JSON (and also
> sending the HTTP request). For several months, I've had a small but
> critical app in production using that. Another project in development is
> too. In the process, I have run across two additional caveats with this
> approach.
>
>1. *Ports don't convert undefined properties to Maybe.Nothing.* It's
>an open issue from Jan 2016.
>
>For a Maybe property, the JSON must have the property present and set
>to null. Otherwise error. This is particularly annoying when you store the
>data as JSON and pass it back to the client as-is. To work around this
>issue, I either have to waste space storing nulls in the database or waste
>(CPU/response) time server-side to inject nulls in the response.
>
>2. *Cmd.map can't be used with this method.*
>Using Http module, you can use Cmd.map to take some data from the
>request and give it to the response Msg. Using ports, you can't do that.
>I've noticed this when the data is easy to provide for a request, but after
>the response comes back it is less convenient to dig out of the model (e.g.
>behind a case statement).
>
> Neither of these are blockers for me, just nuisance issues. It still beats
> maintaining codecs.
>
> I've seen rumblings about tools for code-gen'ing JSON codecs for us (maybe
> elm-format?  There also
> exists elm-swagger, but I don't use swagger.). I dunno though. Where
> possible, I tend to avoid code-gen because it's for handling a really
> tedious problem. And if the code-gen fails, then I have to handle a really
> tedious problem. (XSD/WSDL flashbacks.)
>
> All it would really take for a profound QoL improvement are a couple of
> "special" functions on Http that handle data exactly like ports do now...
> just saying.
>
> --
>
> 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 elm-discuss+unsubscr...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/XW-SRfbzQ94/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Is a decoder the right level of abstraction for parsing JSON?

[Noah Hall]

Http://json2elm.com. auto generating json "codecs" (decoders and encoders)
has existed for more than a year already.

On Friday, March 17, 2017, Kasey Speakman  wrote:

> Another update. I figured out how to get the encoders and decoders out of
> the ports using a native module. So I no longer have to actually send
> things across ports (still have to declare them). I can also now use Elm's
> Http module.
>
> Here's a gist of what it takes:
>
> https://gist.github.com/kspeakman/3f9521b0921b352c7d656261ec0a8fa6
>
> On Saturday, February 18, 2017 at 2:22:32 AM UTC-6, Kasey Speakman wrote:
>>
>> An update. I'm using the ports approach to deal with JSON (and also
>> sending the HTTP request). For several months, I've had a small but
>> critical app in production using that. Another project in development is
>> too. In the process, I have run across two additional caveats with this
>> approach.
>>
>>1. *Ports don't convert undefined properties to Maybe.Nothing.* It's
>>an open issue from Jan 2016.
>>
>>For a Maybe property, the JSON must have the property present and set
>>to null. Otherwise error. This is particularly annoying when you store the
>>data as JSON and pass it back to the client as-is. To work around this
>>issue, I either have to waste space storing nulls in the database or waste
>>(CPU/response) time server-side to inject nulls in the response.
>>
>>2. *Cmd.map can't be used with this method.*
>>Using Http module, you can use Cmd.map to take some data from the
>>request and give it to the response Msg. Using ports, you can't do that.
>>I've noticed this when the data is easy to provide for a request, but 
>> after
>>the response comes back it is less convenient to dig out of the model 
>> (e.g.
>>behind a case statement).
>>
>> Neither of these are blockers for me, just nuisance issues. It still
>> beats maintaining codecs.
>>
>> I've seen rumblings about tools for code-gen'ing JSON codecs for us (maybe
>> elm-format?  There also
>> exists elm-swagger, but I don't use swagger.). I dunno though. Where
>> possible, I tend to avoid code-gen because it's for handling a really
>> tedious problem. And if the code-gen fails, then I have to handle a really
>> tedious problem. (XSD/WSDL flashbacks.)
>>
>> All it would really take for a profound QoL improvement are a couple of
>> "special" functions on Http that handle data exactly like ports do now...
>> just saying.
>>
> --
> 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 elm-discuss+unsubscr...@googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Is a decoder the right level of abstraction for parsing JSON?

[James Wilson]

users : Maybe (List User)
users = decode userJson

one could just make use of type inference to know what to decode into. 
Might mean another special pseudo-typeclass (like comparable, appendable) 
called decodable. Then decode (might need renaming) would have a signature 
like:

decode : Value -> Maybe decodable


I have thought about this as well, also contemplating the port option and 
also finding the amount of boilerplate you have to write to decode into 
records a little annoying. I would be tempted to also provide something like

decodeWithOptions : DecoderOptions -> Value -> decodable

where options could include a function to transform keys into record keys.


On Thursday, 29 September 2016 01:02:29 UTC+1, Duane Johnson wrote:
>
>
> On Wed, Sep 28, 2016 at 5:34 PM, Kasey Speakman  > wrote:
>
>> In the longer term, the solution that jumps out at me is the compiler 
>> could generate decoders for marked type aliases automatically. (I assume 
>> ports work this way already.) And decoding is still there for fuzzy 
>> scenarios.
>>
>
> That sounds like a neat idea. I'm trying to imagine how it would be 
> implemented. Would you pass a type in to a decode function? e.g.
>
> ``elm
> type alias User =
> { name : String
> , email : String
> , birthday : Date
> , id : Int
> }
>
> user1Json = """[
> {"name": "Duane", "email": "duane@gmail.com ", 
> "birthday": "19800101T00Z", id: 42},
> {"name": "Kasey Speakman", "email": "ka...@idontknow.com ", 
> "birthday": "19810202T00Z", id: 43}
> ]"""
> ```
>
> -- the following is currently invalid Elm
> user1 = decode(List User, user1Json)
> ```
>
>
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Is a decoder the right level of abstraction for parsing JSON?

[Duane Johnson]

On Wed, Sep 28, 2016 at 5:34 PM, Kasey Speakman 
wrote:

> In the longer term, the solution that jumps out at me is the compiler
> could generate decoders for marked type aliases automatically. (I assume
> ports work this way already.) And decoding is still there for fuzzy
> scenarios.
>

That sounds like a neat idea. I'm trying to imagine how it would be
implemented. Would you pass a type in to a decode function? e.g.

``elm
type alias User =
{ name : String
, email : String
, birthday : Date
, id : Int
}

user1Json = """[
{"name": "Duane", "email": "duane.john...@gmail.com", "birthday":
"19800101T00Z", id: 42},
{"name": "Kasey Speakman", "email": "ka...@idontknow.com", "birthday":
"19810202T00Z", id: 43}
]"""
```

-- the following is currently invalid Elm
user1 = decode(List User, user1Json)
```

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Is a decoder the right level of abstraction for parsing JSON?

[Kasey Speakman]

Today I found my team struggling over decoding some fixed-structure JSON. 
Search this list for "decode" to see further examples.

Even though I understand decoders well enough to use them, I still don't 
want to use them. For one thing, I don't deal with fuzzy JSON. I have type 
aliases that match the JSON structures. Decoder code is entirely redundant 
with the information in the type alias. Secondly, writing a decoder is 
demonstrably beginner unfriendly. (Read the search results or watch a 
beginner struggle with it to see for yourself.) So writing a decoder is 
painful both conceptually and because it's redundant work.

In the shorter term, my prevailing alternative to decoding in 0.17 is just 
to use ports to launder the JSON into clean Elm types, since ports are 
automatically decoded. But notably Date will not pass through ports. Not a 
frequent need for me but if I did need a Date type, another type alias with 
date as string or int would be required. Then that would have to be 
converted to the real record. It's even more redundant work (albeit 
simpler), so I'll avoid if possible.

In the longer term, the solution that jumps out at me is the compiler could 
generate decoders for marked type aliases automatically. (I assume ports 
work this way already.) And decoding is still there for fuzzy scenarios.

Anyway, I saw in one of the Elm-conf videos Evan say that if I have issues, 
I should say something. So there it is. The other main issue we have looks 
to get fixed next version (changes to files not being recompiled).

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.