Json.Morph

morph

MorphIndependently

(Value narrowTag -> Result error_ (Json narrowTag))

(Json IndexAndName -> Value IndexAndName)

string : Morph (Json String) String

Morph from a String

Broadens to a compact String. To adjust format readability → stringBroadWith

stringBroadWith : { indentation : Int } -> Morph (Json String) String

Json.string Morph with adjustable indentation.

This is a bit clunky since stringBroadWith is using Json.Encode.encode. I bet we could make this cleaner with a custom MorphRow and a nice pretty-printable broad representation like the-sett/elm-pretty-printer.

MorphIndependently

(tagBeforeMap -> Result (ErrorWithDeadEnd Never) tagMapped)

(tagBeforeUnmap -> tagUnmapped)

-> MorphIndependently

( Json tagBeforeMap

-> Result (ErrorWithDeadEnd never_) (Json tagMapped)

)

(Json tagBeforeUnmap -> Json tagUnmapped)

Morph.OneToOne for Json where Json.tagMap is called in both directions

...
    |> Morph.over (Json.Morph.eachTag Value.Morph.compact)


-- or
...
    |> Morph.over (Json.Morph.eachTag Value.Morph.descriptive)

type alias JsValueMagic =

Value

A value from the javascript side: from a port, on init, from elm/http, ...

Compiler magic. Not caseable. Elm crashes on ==. Can include functions, proxies, getters, bigInts, anything

and.. of course this can be abused to break elm's promises 🙈, see for example randomness without Cmd ellie

jsValueMagic : Morph (Json String) JsValueMagic

About json numbers...

json numbers don't strictly adhere to a Float as defined in the IEEE 754 standard which is hardcoded into almost all CPUs. This standard allows Infinity and NaN which the json.org spec does not include.
elm/json silently encodes both as null. This behavior matches JSON.stringify behavior in plain JS
our json representation doesn't have this footgun since it uses Decimal
elm Decoders/Encoders can only handle Float range which dictates the range we can use for Decimals