TypeScript: Десериализация JSON в классы с валидацией типов у свойств

[aigoncharov]

А чем не угодили class-transformer вместе с class-validator?
https://github.com/typestack/class-transformer

[aigoncharov]

А чем не угодили class-transformer вместе с class-validator?

https://github.com/typestack/class-transformer

https://github.com/typestack/class-validator/

[LabEG]

Моей реализации на самом деле уже почти 4 года, в текущем виде больше 2 лет. И на тот момент когда я ее создавал не было той библиотеки которая меня устраивала бы по функционалу и качеству. Да и сейчас кажется что моя проще.

[DimPal]

После конфускации с обезличиванием имен будет счастье…
Кстати, что будет с типизированными массивами и вложенными классами?

[LabEG]

Минификаторы не трогают свойства классов. А так да, проблема с обфускацией есть во всех языках с рефлексией.
Массивы валидируются. Массивы классов так же десериализуются. Вложенный класс если унаследован от Serializable так же десериализуется, если нет, то остается объектом. Огромные графы с массивами и классами так же десериализуются и валидируются.

[VolCh]

> Можно тоже самое реализовать и через декоратор или monkey patching. Но наследование является более правильным методом для Typescript.

Вот не согласен. Особенно учитывая, что множественного наследования нет. Если у меня User extends Person, а над Person контроля нет, как мне применить ваш Serializable?

[LabEG]

Такой кейс мне не встречался, т.к. я всегда принимаю данные в свои классы, но вопрос интересный.
Из того что пришло в голову это сделать доработку библиотеки что бы в User переопределить свойства, но уже с декораторами, а у Serializable сделать статичный метод Serializable.toClass(User, json): User

[justboris]

Смешная пирамида деклараций вот здесь: github.com/LabEG/Serializable/blob/master/src/models/AcceptedType.ts#L13

А зачем это?

[LabEG]

Это рекурсивный тип, аналог

type AcceptedTypes = AcceptedType | Array<AcceptedTypes>;

для глубоко вложенных массивов типа [[[[1,2]]]]. Дело в том что typescript разрешает рекурсивные типы, но перестает валидировать их при использовании. А такая пирамида позволяет провалидировать до 10 уровня, а дальше уже через any.

[justboris]

А если сделать так:

interface RecursiveArray<T> extends Array<T|RecursiveArray<T>> {}

type AcceptedType = ...;
type AcceptedTypes = RecursiveArray<AcceptedType>;

Живое демо, валидируется нормально.
Подсмотрено в тайпингах Lodash.

[LabEG]

Интересный прием. Спасибо!

[kemsky]

Тоже думал написать что-то похожее, но потом отказался от идеи, слишком много сил надо чтобы написать полноценное решение и будущее декораторов выглядело смутно. Самая неприятная проблема — работа с датами, но ее можно решить по-другому.

Сейчас есть интересная альтернатива — TypeScript Custom Transformers, что позволяет делать кодогенерацию во время компиляции, еще не все сделано, но уже можно пробовать. По идее можно будет обойтись без кучи декораторов. Еще один способ — кодогенерация по моделям бэкенда или свагеру.

[LabEG]

Я тоже не сразу написал библиотеку. С начало это производилось вручную в методе объекта, потом была выявлена закономерность, а в тайпскрипте появились декораторы и рефлексия. И как только появилось свободное время реализовал библиотеку.

Со временем работать просто. Если нужно исключить влияние таймзоны надо оставить его строкой, если нет, то десериализовать в локальное время.

TypeScript Custom Transformers — спасибо за наводку. Кажется эта штука избавит нас от browserify/webpack и позволит компилировать в ES2015.

Про кодогенерацию моделей и репозиториев с валидацией из свагера тоже есть идея, надеюсь скоро удастся реализовать.

[DimPal]

AFAIK, декораторы все еще экспериментальная фича, или я что то пропустил?

[LabEG]

Да, но она стабильна и последние два года не менялась. И думаю что уже скоро станет стандартом.

[metalalisa]

Если не хочется писать классы, есть github.com/gcanti/io-ts

[LabEG]

Мне не нравится подход со схемами, кроме того в моделях у меня бывают методы.

[boblgum]

За саму реализацию автору однозначно плюс в карму.
Но я советую как можно быстрее уходить от такого подхода. Вы двигаетесь в сторону ActiveRecord. В данном случае вы впиливаете функционал сохранения данных в Вашу модель. Этот функционал ни каким образом не относится к смыслу модели.
Вынесите этот функционал в сервис и получите более чистый и распределенный код.

[LabEG]

А вы правы, в комментарии выше уже всплывала эта проблема. И в Newtonsoft десериализация тоже реализована через статический метод. Реализую как Serializable.toClass(User, json): User