Support for polymorphism, subclassing, interfaces, union types

[evertheylen]

Hello!

I am working on a project that, similar to deepkit, stresses isomorphic typescript. In particular, I am also working on (de)serialization, RPC, and ORM features. I must say that this looks like a fantastic library.

I've been browsing the documentation for deepkit and one thing stood out to me: the lack of support for polymorphism in its various forms. Consider the following class hierarchy:

class Animal {
  makeSound() { console.log("...") }
}

class Lion extends Animal {
  makeSound() { console.log("ROAR") }
}

class Human extends Animal {
  constructor(public name: string) { super(); }
  makeSound() {
    console.log(`Hello, I am ${this.name}`)
  }
}

If I serialize a Lion as an Animal, it loses the special behaviour. If I serialize a Human as an Animal, it even loses data. For example:

serialize<Animal>(new Human("Linus"))  // --> {}

The above example is contrived as it is trivial to just call serialize<Human>(...). But if we store Animal objects in an array or some other container, you can have a mix of Lion and Human and are no longer able to specify the exact type as it could be both.

Now I do know many people are against subclassing, and would suggest just not doing it. Two points:

First, the problem is a bit wider than just subclassing, it also applies to interfaces or any time a union type (A | B) comes into play. Consider that the following will give two strings instead of a Date and a string:

type T = (string | Date)[];
deserialize<T>(serialize<T>([new Date(), "some string"]))

Second, polymorphism is part of Javascript and therefore Typescript, you can't just drop a part of it. I think there is an (implicit?) claim that deepkit "Just Works" for any correctly typed code. However, the above examples fail to provide "real" isomorphism of objects as information is lost when passing data between frontend/backend.

I am very curious to hear about how deepkit plans to face these challenges. I think not supporting them could be a valid option if you warn the user about it, but actual implementations certainly have my interest 😃

[marcj]

Your example with (string | Date)[] works fine, and returns [Date, string]. With the example of Animal it's not that trivial as it would be a performance hit if we would have to check each subclass first. Also it would be a memory leak if we need to track all subclasses prematurely (as you could generate unlimited subclasses dynamically).

serialize<Animal>(new Human("Linus"))  // --> {}

It's expected behaviour to not get any other properties than the ones in Animal. This behaviour has concrete use cases. If you want to get it to work like you want, use serialize<Lion|Human>(...) or read the actual type of the class instance via reflect and pass it to serialize.

    const o = new Human();
    serialize<Animal>(o, undefined, undefined, undefined, reflect(getClassTypeFromInstance(o)));