TypedJSON.parse without type can be confusing about typedjson

[JohnWeisz]

The overload of TypedJSON.parse without a type argument will be deprecated starting from v0.2.0. To parse JSON without types, use the JSON.parse instead.

Also, supplying an object that is not an instance of a class decorated with @JsonObject to TypedJSON.stringify is also deprecated starting from v0.2.0.

[lgleim]

Why do you even need to supply a type at all? Wouldn't it be much nicer to just encode it in a metadata property and to detect it automatically? This also allows to correctly parse nested Objects with their respective correct type. Are you familiar with the approach taken here? http://cloudmark.github.io/Json-Mapping/

[JohnWeisz]

@lgleim
First, because TypedJSON aims to provide a deserialization experience through expected types, not what is present in the JSON string. Once TypedJSON is fleshed out (it's a WIP, and significant progress has been made since its last releases), this is a tool to protect against arbitrary JSON.

Second, because without the constructor of the root data type it is unknown what the type of the deserialized object should be. This is how the return type of TypedJSON.parse is determined:

interface TypedJSON {
    parse<T>(json: string, constructor: new () => T): T;
}

Leaving this out would require a type-assertion, or a generic type, but that would have to be specified at all times, which is almost the same as having to supply the constructor itself. Additionally, this ensures the root class has a parameterless constructor signature, which is needed.

The new version will provide an optionally instantiable API, through which the root data type only has to be specified once.

[JohnWeisz]

May I ask what possible use-case would require deserialization without knowing the root type?

[lgleim]

In various document-based databases the type of the document is stored as a json property and validated using json-schema (if at all). E.g. for CouchDB (and alike, such as Couchbase, BarrelDB,...) there is (by default but mostly configurable) a property type at the root of each json document stored in the DB.

[lgleim]

I fully understand if TypedJSON is solving a different issue. Nevertheless, how does TypedJSON handle nested classes of the kind

MapUtils.deserialize(Person, {
     "name": "Mark",
     "surname": "Galea",
     "age": 30,
     "address": [{
         "first-line": "Some where",
         "second-line": "Over Here",
         "city": "In This City"
     }]
})

which would be parsed to something like

<Person>{
  name: 'Mark',
  surname: 'Galea',
  age: 30,
  address: 
   [ <Address>{
       firstLine: 'Some where',
       secondLine: 'Over Here',
       city: 'In This City' 
     } 
   ] 
}

[JohnWeisz]

a property type at the root of each json document sored in the DB

Although this is yet to be tested (in the new version at least, which I'm currently working on), but this should be possible by specifying Object as the root data type, since TypedJSON supports polymorphism. It uses the __type property by default to look up type-names through the specified known-types.

Edit

Not with object, but with a common base class from which all other documents extend.

[lgleim]

Good to hear! I will be looking forward for the release. Will nested Objects with different types also be handled with the upcoming release?

[JohnWeisz]

@lgleim
Hold on for a sec, TypedJSON supports nested objects right now as well. The constructor you need to specify is only for the root type, from which child objects are traversed automatically. It can handle complex object trees, such as what is defined in https://github.com/JohnWeisz/TypedJSON/blob/master/src/tests/polymorphism.ts

[lgleim]

Thanks for pointing this out! Looking forward to the release.

[Neos3452]

Hey, if you would be interested again, this was released some time ago now.