Consider changing the JSON serialization for custom types

[AttilaMihaly]

No description provided.

[AttilaMihaly]

We discussed an concluded to change the current approach of:

{
  "$type": "typeTag",
  "field1": "value1",
  "field2": "value2"
}

To this:

["typeTag", "value1", "value2"]

[DamianReeves]

I think it might be valuable for us to specify what this mapping looks like when we are coming from Frontend's that provide names for the fields such as in F# and Scala

type Shape 
    = Rectangle Float Float
    | Circle Float
    | Prism Float Float

type Shape =
    | Rectangle of width : float * length : float
    | Circle of radius : float
    | Prism of width : float * float * height : float

sealed abstract class Shape
object Shape {
   case class Rectangle(width:Float, length:Float) extends Shape
   case class Circle(radius:Float) extends Shape
   case class Prism(width:Float, anonymous1:Float, height:Float) extends Shape
}

[AttilaMihaly]

It would be the same, right? This represents the constructor invocation not the declaration.

[DamianReeves]

That's what I wanted to get into actually. So in this case the declaration would have the field names, right?
In the case where there are field names do we allow a call invocation with named arguments, or do we always translate to positional?

[AttilaMihaly]

I think we should always translate to positional. The field names are just to make it more readable. That makes sense to capture in the type but probably not the value. It's debatable though.