V2 roadmap

[thomaswinckell]

V1 was a proof of concept. Since I did not see any other tools like this, I want to go further. Let's discuss here about what we want for a V2.

First, I would like to get rid of the peer dependencies. It's working nicely with scalts currently, but I want to avoid a dependency with it. We can do an other project called scalts-serialize or something else that depends on scalts that adds un/marshallers for optional, either, etc... The point is that scalts is not bullet proof, it's kind of a proof of concept.
Internally, I would suggest to use Promise instead of Either.

Then, I would like a more flexible and easier api. Currently, it's very nice for common cases, but not so nice to use with custom un/marshallers or with complex generics types.
I would go for something like this :

Serialize(...genericTypes : Function[][]) : ISerialize

interface ISerialize {
    name(jsonName : string) : ISerialize; // transform property name
    marshall(marshaller : Marshaller) : ISerialize; // give the marshaller to use
    unmarshall(unmarshaller : Unmarshaller) : ISerialize; // give the unmarshaller to use
    // etc...
}

Here, we have a function where we can put every types we want (including generics) and returns an ISerialize (generic types should be provided, see microsoft/TypeScript#10576).
That means we can use chaining like this :

class Foo {
    @Serialize([Map], [String, Number]).name('complex_property').marshall(() => ...).unmarshall(() => ...)
    complexProperty : Array<Map<string, number>>;
}

To resume :

• Get rid of peer dependencies
• Easier and more flexible api
• Smarter un/marshallers to deal with complex generic types
• User should be able to import the default un/marshallers, use and extend them
• Documentation
• Better error messages
• Throw an error when there is no un/marshaller found, don't return a serialize error
• Keep using Babel ? Typescript with target set to es5 is not enough ?
• User should be able to register defaults un/marshallers for given types (can be used internally too)
• Possibility to create async un/marshallers

[thomaswinckell]

@rfmejia Please give me your feedback if you're interested in using/developing this project.

[rfmejia]

@thomaswinckell I'm interested in helping with tickets as much as I can. I particularly like the feature to flexibly supply types and un/marshallers.

User should be able to register defaults un/marshallers for given types (can be used internally too)

I agree, this should be the default design of our library (similar to Scala libraries that have "implicit" un/marshallers supplied).

Once you spec out your improved API ideas (promise-based) share it here so we can review it. I currently like the composability of Either in certain scenarios but it is more natural to use promises for a many web developers.

[thomaswinckell]

I agree, this should be the default design of our library (similar to Scala libraries that have "implicit" un/marshallers supplied).

I also like Scala implicits.

I currently like the composability of Either in certain scenarios but it is more natural to use promises for a many web developers.

I also like it, but I just remind an idea : I would like to be able to use asynchronous un/marshallers. With this, you could, for instance, fetching data from an identifier and resolve the data.
In the future, we could also use Either or Future<Either> instead of Promise in a scalts-serialize library.

Once you spec out your improved API ideas (promise-based) share it here so we can review it.

I am starting to use this project again on an other personal project that has complex needs, so I will do what I can to be fast.

[rfmejia]

I am starting to use this project again on an other personal project that has complex needs, so I will do what I can to be fast.

Great, I'm using this library for a project of mine too. Take your time with this, we can address other points you raised in the meantime. I can monitor this repo for issues and try to help with them.

[thomaswinckell]

@rfmejia I have started to write the V2. You can check it on the v2 branch. There is still some main feature to do (handle optionals and default values), some tests, some documentation and probably some issues... I will create issues soon, so you will be able to contribute if you want.

By the way, I am looking at this project https://github.com/lilezek/tson that is doing something similar to this project (less powerful, but more simple), and especially to the metadata emitter written especially for this project : https://github.com/lilezek/awesome-metadata. It still very young but I like the idea to retrieve ALL the metadata (generics, optional, ...) and not only the main type. We could add support for this metadata emitter. Since it's very young, I prefer to not depend on it.

[rfmejia]

I'll go over the changes in depth sometime within the next few days, at a glance it looks great. For the metadata emitter, this is a great addition to the library and maybe it can be part of some major 2.x release down the line.

[chanlito]

when is v2 release?

[thomaswinckell]

@chanlito I am a bit busy on other projects for now, but I will come back to this one soon. I will let you know.