Comments 5
Мне кажется, что данный подход можно улучшить.
Во-первых, неясно, зачем вам typescript, раз все равно валидация проходит в runtime. Во-вторых, валидация в runtime спорная. Если пришел объект без id, пытаться чинить (и молча проглатывать) это с помощью data!.id || null неправильно. Оно ничем не поможет в дальнейшем, и только усложнит отладку.
Typescript согласно своей (спорной) идеалогии не вмешивается в runtime, но есть несколько проектов, которые пытаются решить эту ситуацию. Например, github.com/pelotom/runtypes протаскивает типы в js, и с их помощью позволяет валидировать входящие объекты. В случае ошибки он выбрасывает исключение, и это правильно. Интересен так же подход github.com/paroi-tech/typeonly, это следующий язык, суперсет над typescript. Кроме того, можно определять типы typescript динамически на основе js-объекта с помощью keyof и typeof, и опять-таки пользоваться исходным объектом для runtime-валидации.
Конечно, интереснее всего было бы с помощью typescript писать fullstack-приложения, т.е. определять сущности в nest и typeorm один раз, и эти же определения использовать на фронтенде в vuex. А затем пробрасывать в runtime javascript для валидации (и даже формы валидировать без запроса на бек). Все к этому уверенно движется.
Во-первых, неясно, зачем вам typescript, раз все равно валидация проходит в runtime. Во-вторых, валидация в runtime спорная. Если пришел объект без id, пытаться чинить (и молча проглатывать) это с помощью data!.id || null неправильно. Оно ничем не поможет в дальнейшем, и только усложнит отладку.
Typescript согласно своей (спорной) идеалогии не вмешивается в runtime, но есть несколько проектов, которые пытаются решить эту ситуацию. Например, github.com/pelotom/runtypes протаскивает типы в js, и с их помощью позволяет валидировать входящие объекты. В случае ошибки он выбрасывает исключение, и это правильно. Интересен так же подход github.com/paroi-tech/typeonly, это следующий язык, суперсет над typescript. Кроме того, можно определять типы typescript динамически на основе js-объекта с помощью keyof и typeof, и опять-таки пользоваться исходным объектом для runtime-валидации.
Конечно, интереснее всего было бы с помощью typescript писать fullstack-приложения, т.е. определять сущности в nest и typeorm один раз, и эти же определения использовать на фронтенде в vuex. А затем пробрасывать в runtime javascript для валидации (и даже формы валидировать без запроса на бек). Все к этому уверенно движется.
+1
Валидация, транспорт и генерирование типов апи из схемы — это всё задачи фреймворка swagger, thrift, grpc, gql/apollo.js. Решать это вручную — жуткий колхоз, кодовая помойка и полное непонимание принципов распределённых систем. Отсутствие базовых знаний о базовых знаниях о мире
0
Кстати есть уже готовый, отличный инструмент Vuex ORM Axios
0
Sign up to leave a comment.
Работа с данными на границе Vue.js-приложения