I think this would be a reasonable change. The maybe decoder <http://package.elm-lang.org/packages/elm-lang/core/4.0.5/Json-Decode#maybe> in Json.Decode already works this way.
On Thu, Nov 10, 2016 at 2:35 PM, Kasey Speakman <[email protected]> wrote: > So something that I just tripped over... > > If you're bringing a JSON object in through a port, and the elm type def > has: > > * type alias aFoo =* > * { someFoo : Maybe String }* > > This JSON comes over properly: > > * { someFoo: null }* > > But this JSON throws an error: > > * { } // field omitted* > > If this data is from a JS library using an API, many default to omitting > null fields in their output. Reasoning being, why carry extra stuff extra > across the wire? > > Most serializers that I have used default to omitting null values from the > serialized output. > > Seems to me that both null and undefined should translate to > Maybe.Nothing when coming across a port. > > Anybody else run into this? > > -- > 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. > -- 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.
