Idea: Validation via decorators

[michaelkrog]

I have been looking at your solution and find it quite interesting. One thing we would like to have in our types is however details about validation.

In our backend entities we have validation based on hibernate validation annotations. Projects exists to have something similar in typescript fx https://github.com/typestack/class-validator. But it requires output to be typescript classes instead of interfaces.

Is there any interest in having such an option in this project? If so, I could probably add a new module for it as a PR.

[tomasz-wozniak75]

Hey Michael
Thanks for the interest in our project. I think that You have very interesting idea, do You want to generate decorators as an additional type info for developers or You want to use in another way?

We have branch "version-1.2.7" it was intended to upgrade some dependencies but in this release we can add your functionality so You can branch off from this branch.

I think that it would be good to use ConversionListener to extend types and fields with decorators (or maybe you want to add comments), please look at spring-rest2ts-swagger module where ConversionListeners are used to add comments to TS code based on swagger annotations. Such approach gives us possibility to use this new functionality with all models converters. It should be placed in a separate module.

In general You are welcome and if You have any question You can write to me directly on linkedin or skype([email protected])

kind regards
Tomasz

[tomasz-wozniak75]

Michael please keep in mind that interfaces exists only in the compile time so I checked TS documentation

A Decorator is a special kind of declaration that can be attached to a class declaration, method, accessor, property, or parameter. Decorators use the form @expression, where expression must evaluate to a function that will be called at runtime with information about the decorated declaration.

As You see You can't even add decorators to interfaces this is the reason why library which You mention requires classes.
I was thinking about converting java model to TS classes but it requires special JS deserializer which during deserialization will add proper types to JSON objects but it is a greater work.
But still I think that your idea is helpful if we put into TS comments info about validators as a help for FE developers.

kind regards
Tomasz

[michaelkrog]

Thx for the quick reply. 👍

So a good first step for me would be to create a ConversionListener that can add the validation rules as comments. The developer can then use that info for manually adding the validation rules to his forms.

Later on, maybe we can revisit the optiob to output TS classes instead of interfaces in order to add validation as functional decorators. The benefit would be that forms could easily validate the object being edited without any manually created validation rules on the front end side.

I am on vacation the next 2 weeks, but when I get back I will look into adding validation rules as comments - and in a new separate module.

[tomasz-wozniak75]

ok, sounds good, have a nice holidays :)

[tomasz-wozniak75]

Hi Michael
In version-1.4.0 we added support for library jackson-js which allows to deserialize JSON to ES6 types (ES6 custom classes, Maps, Dates, Sets) it works well and it is the best library which we were able to find but it is not actively supported. There is a risk in a commercial projects but with jackson-js it is really straightforward to add support for javax.validation annotations. We tested also class-transformer it has 4k stars but it is also not supported and it is not able even to deserialize Map class correctly, jackson-js is really great job comparing to class-transformer.
Maybe one day author will return to this library.