With compact indexes. Use in combination with Value.Morph.eachTag just before chaining to Value.Morph.json

• part tag = part MorphValue index index in the builder
• variant tag = variant MorphValue index in the builder
• →
  • unreadable to humans
  • only readable by other tools if they know the variant and field order
  • not easily debuggable
  • shuffling Value.Morph.part order → breaking change
  • renaming Value.Morph.parts → no change

See also Value.Morph.descriptive

Morph.OneToOne from a generic representation of an elm value

Inverse of Value.Morph.json

Morph from a String

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

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.

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

Morph to valid Json value format from 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