Проблема с зодом в том, что его использование приводит к тому, что у нас появляется 2 источника правды: тайпскрипт и сам зод. Почему? Потому что схему зода можно преобразовать в тип тса, но тип тса нельзя преобразовать в зод (да, есть инструменты, типа ts-to-zod, но они лишь преобразовывают тип в схему, но нет лайвтайм проверки при изменении типа). В итоге нам либо получать все внешние типы из зода, что "очень удобно", либо иметь отдельно схему и отдельно тип. Можно, конечно, сравнивать полученный из зода тип с типом из тса, но это костыль. А ещё зод один из самых медленных валидаторов. В итоге лично я перешёл с zod на ajv и теперь генерирую схему на основе типа, а не наоборот. И любое изменение типа сразу же генерирует тс ошибку. И вот это уже действительно 1 источник правды - типы. В идеале вообще использовать runtipes или аналоги, парсящие сами тс типы, они на 1-2 порядка быстрее обычных валидаров, но там есть нюансы с компилятором.
Генерировать zod на основе типов или генерировать json схемы на основе типов, одно и тоже. Любая генерация это мутотень, как по мне. Dx у такого решения хуже. Zod единственное решение, в котором можно обойтись совсем без генерации Zod - самое простое и универсальное решение, из возможных. Но да, что бы работал один источник правды - нужно все типы описывать схемами. Схемы похуже читаются Да zod медленнее, но у него и специфика другая, он больше сделан под front-end и у него много всего заточено под валидации форм. Zod идеален для тех, кто только начинает свой путь безопасного ts, так как это самый универсальный инструмент. А дальше можно под специфику подобрать более профильный инструмент + у zod есть трансформации, что действительно позволяет делать приятные штуки, по типу превращения всяких строковых дат в Date и парсинга вложенных строковых представлений
@@paromovevg > "Генерировать zod на основе типов или генерировать json схемы на основе типов, одно и тоже." Именно поэтому генерация схемы из типа не очень полезна, т.к. после генерации у тебя нет никакой связи между типом и схемой. А того же ajv сначала прописывается тип, а только потом строится схема на основе тс ошибок, которые у тебя будут в схеме, пока она не удовлетворит сам тип. То есть генерации схемы как таковой вообще нет. А если мы говорим о каких-нибудь runtipes, то тут вообще никакой реальной схемы нет, только тип в тсе. > "Zod - самое простое и универсальное решение, из возможных." Спорное заявление. > "что бы работал один источник правды - нужно все типы описывать схемами. Схемы похуже читаются" Это во-первых, а во вторых все типы через зод не опишешь. Вернее можно, но не будешь же ты те же пропсы компонентов через него описывать? А прочие внутренние типы? В итоге у нас всё равно 2 источника правды. > "Да zod медленнее, но у него и специфика другая, он больше сделан под front-end" Как это выражается? Чем он превосходит тот же ajv или runtipes? > "у него много всего заточено под валидации форм." Очень полезно. Кто и зачем будет валидировать формы зодом? Кто вообще сегодня будет работать с формами без библиотеки для форм? А если это одна маленькая форма на весь сайт, то тут даже жс не нужен, хтмла хватит. > "Zod идеален для тех, кто только начинает свой путь безопасного ts, так как это самый универсальный инструмент." Опять же, спорное заявление. Чем он именно лучше аналогов? Чем он универсальнее? > "+ у zod есть трансформации" У аналогов они тоже есть. Такое мнение имеет право на жизнь, но заявления слишком категоричны. Тем более заявление про 1 источник правды в принципе ложно. Если бы видео было про то, что валидация в тсе нужна, пользуйтесь валидаторами, но лично я предпочитаю зод и вот почему..., то это одно, но посыл больше похож на рекламу собственного курса, чем на относительно объективное мнение, имхо.
@@BOCbMOU Вообще-то это и есть реклама курса. Насчет того, что у zod нет одного источника правды я не ухватил мысль. Может что-то не так понял. На мой взгляд, источник правды один - это схема. Другое дело, что читается она действительно сложнее, чем типы в чистом виде.
Это не просто рекламный видос, это первый урок курса. но если бы вы досмотрели до конца вы бы и runtypes там увидели и json schema и другие альтернативы > а только потом строится схема на основе тс ошибок, которые у тебя будут в схеме, пока она не удовлетворит сам тип В zod тоже так же можно, сделать тип, и потом строить схему пока не удовлетворит от ts. Но никто так не делат, потому что это описание одной структуры данных 2 раза Но с другой стороны можно не делать эту двойную работу, а сначала написать схему, а потом просто вывести на её основе тип. > "Zod - самое простое и универсальное решение, из возможных." Среди ts-first, самый популярный по скачиваниям. Поддерживает вообще любые структуры данных и сценации использования. ajv популярней в принципе, но он ограничен просто схемой, и не поддерживает работу с формами и преобразования > Очень полезно. Кто и зачем будет валидировать формы зодом? Видимо у нас разный опыт, да форму из 2х полей зодом валидировать нет смысла, но бывают вещи и посложнее, и тут я видел много убогих самописов, которые изи zod ом заменяются Тогда интеграция с react-hook-form очень хорошо работать начинает > "Да zod медленнее, но у него и специфика другая, он больше сделан под front-end" ajv - многословный, или извольте генерировать на основе типов rutupes вообще уже почти год не пооддеривается особо и 200к скачиваний против 7кк у zod zod - поддерживает как и валидацию форм, так и работу со схемами + трансформации и много интеграций Как уже говорил выше, решение не идеальное, и под специфику лучше есть (например ajv для валидации api запросов) Но zod можно использовать для любого кейса unknown -> строгий тип. И под этим я понимаю универсальность
3:09 те кто по опытнее на такие "не типизированные данные" кидают валидации от Joi и все, нет никаких проблем 20:42 тут ты правильно подметил, стоит попробовать использовать зод на фронте, надеюсь там есть не только проверка типов но и допом можно накатить валидации как в joi
Я так и сделал. Это дошло уже до шизофрении. В js инструмент на инструменте инструментом погоняет. Потому что ни один не делает работу хорошо. В ts не лучше, хотя и он инструмент над js.
Ну да ну да. Пример из самого видео - бэкэнд выслал не пойми какие данные, пользователь в качестве эксперимента поменял что-то в localStorage. Но виноват, конечно же, фронтэнд и js 😆
согласен, но рил чем больше проект разростается - тем сложнее держать всё в голове :_( это слёзы, но как же заколебал typescript..... почему тяжело сделать нечто шедевральное и крутое как c#.....?????
Наука
Респект тебе, спасибо
Проблема с зодом в том, что его использование приводит к тому, что у нас появляется 2 источника правды: тайпскрипт и сам зод. Почему? Потому что схему зода можно преобразовать в тип тса, но тип тса нельзя преобразовать в зод (да, есть инструменты, типа ts-to-zod, но они лишь преобразовывают тип в схему, но нет лайвтайм проверки при изменении типа). В итоге нам либо получать все внешние типы из зода, что "очень удобно", либо иметь отдельно схему и отдельно тип. Можно, конечно, сравнивать полученный из зода тип с типом из тса, но это костыль. А ещё зод один из самых медленных валидаторов.
В итоге лично я перешёл с zod на ajv и теперь генерирую схему на основе типа, а не наоборот. И любое изменение типа сразу же генерирует тс ошибку. И вот это уже действительно 1 источник правды - типы.
В идеале вообще использовать runtipes или аналоги, парсящие сами тс типы, они на 1-2 порядка быстрее обычных валидаров, но там есть нюансы с компилятором.
Генерировать zod на основе типов или генерировать json схемы на основе типов, одно и тоже.
Любая генерация это мутотень, как по мне. Dx у такого решения хуже. Zod единственное решение, в котором можно обойтись совсем без генерации
Zod - самое простое и универсальное решение, из возможных. Но да, что бы работал один источник правды - нужно все типы описывать схемами. Схемы похуже читаются
Да zod медленнее, но у него и специфика другая, он больше сделан под front-end и у него много всего заточено под валидации форм.
Zod идеален для тех, кто только начинает свой путь безопасного ts, так как это самый универсальный инструмент. А дальше можно под специфику подобрать более профильный инструмент
+ у zod есть трансформации, что действительно позволяет делать приятные штуки, по типу превращения всяких строковых дат в Date и парсинга вложенных строковых представлений
@@paromovevg > "Генерировать zod на основе типов или генерировать json схемы на основе типов, одно и тоже."
Именно поэтому генерация схемы из типа не очень полезна, т.к. после генерации у тебя нет никакой связи между типом и схемой. А того же ajv сначала прописывается тип, а только потом строится схема на основе тс ошибок, которые у тебя будут в схеме, пока она не удовлетворит сам тип. То есть генерации схемы как таковой вообще нет. А если мы говорим о каких-нибудь runtipes, то тут вообще никакой реальной схемы нет, только тип в тсе.
> "Zod - самое простое и универсальное решение, из возможных."
Спорное заявление.
> "что бы работал один источник правды - нужно все типы описывать схемами. Схемы похуже читаются"
Это во-первых, а во вторых все типы через зод не опишешь. Вернее можно, но не будешь же ты те же пропсы компонентов через него описывать? А прочие внутренние типы? В итоге у нас всё равно 2 источника правды.
> "Да zod медленнее, но у него и специфика другая, он больше сделан под front-end"
Как это выражается? Чем он превосходит тот же ajv или runtipes?
> "у него много всего заточено под валидации форм."
Очень полезно. Кто и зачем будет валидировать формы зодом? Кто вообще сегодня будет работать с формами без библиотеки для форм? А если это одна маленькая форма на весь сайт, то тут даже жс не нужен, хтмла хватит.
> "Zod идеален для тех, кто только начинает свой путь безопасного ts, так как это самый универсальный инструмент."
Опять же, спорное заявление. Чем он именно лучше аналогов? Чем он универсальнее?
> "+ у zod есть трансформации"
У аналогов они тоже есть.
Такое мнение имеет право на жизнь, но заявления слишком категоричны. Тем более заявление про 1 источник правды в принципе ложно.
Если бы видео было про то, что валидация в тсе нужна, пользуйтесь валидаторами, но лично я предпочитаю зод и вот почему..., то это одно, но посыл больше похож на рекламу собственного курса, чем на относительно объективное мнение, имхо.
@@BOCbMOU Вообще-то это и есть реклама курса. Насчет того, что у zod нет одного источника правды я не ухватил мысль. Может что-то не так понял. На мой взгляд, источник правды один - это схема. Другое дело, что читается она действительно сложнее, чем типы в чистом виде.
Это не просто рекламный видос, это первый урок курса. но если бы вы досмотрели до конца вы бы и runtypes там увидели и json schema и другие альтернативы
> а только потом строится схема на основе тс ошибок, которые у тебя будут в схеме, пока она не удовлетворит сам тип
В zod тоже так же можно, сделать тип, и потом строить схему пока не удовлетворит от ts. Но никто так не делат, потому что это описание одной структуры данных 2 раза
Но с другой стороны можно не делать эту двойную работу, а сначала написать схему, а потом просто вывести на её основе тип.
> "Zod - самое простое и универсальное решение, из возможных."
Среди ts-first, самый популярный по скачиваниям. Поддерживает вообще любые структуры данных и сценации использования. ajv популярней в принципе, но он ограничен просто схемой, и не поддерживает работу с формами и преобразования
> Очень полезно. Кто и зачем будет валидировать формы зодом?
Видимо у нас разный опыт, да форму из 2х полей зодом валидировать нет смысла, но бывают вещи и посложнее, и тут я видел много убогих самописов, которые изи zod ом заменяются
Тогда интеграция с react-hook-form очень хорошо работать начинает
> "Да zod медленнее, но у него и специфика другая, он больше сделан под front-end"
ajv - многословный, или извольте генерировать на основе типов
rutupes вообще уже почти год не пооддеривается особо и 200к скачиваний против 7кк у zod
zod - поддерживает как и валидацию форм, так и работу со схемами + трансформации и много интеграций
Как уже говорил выше, решение не идеальное, и под специфику лучше есть (например ajv для валидации api запросов)
Но zod можно использовать для любого кейса unknown -> строгий тип. И под этим я понимаю универсальность
@@CJIu3eHb речь про источники правды для всего приложения. И тут у нас за типизацию отвечают как тс типы, так и зод схемы.
годно жеж!
ролик еще не досмотрел просто ставлю лайк за то как красиво обосрал астрологов)
что насчёт valibot?
"Авось" это великий бог 😄
вижу отсылку в названии видео😂
$mol is everywhere
когда чертову cms продолжим прогать ?
Поддерживаю
Скоро все будет
Слишком много воды... По сути, важного, от силы 20%....
А по стартапу с нуля будет продолжение? Уже давно не было выпусков😂.
Продолжение на моей платформе micro-courses.ru/course/micro-courses-dev
На ютуб этот формат смотрят так себе
@@paromovevg уже вчера нашел, спасибо….оказалось уже два новых видео есть, уже и их посмотрел и опять жду продолжения!👍
3:09 те кто по опытнее на такие "не типизированные данные" кидают валидации от Joi и все, нет никаких проблем
20:42 тут ты правильно подметил, стоит попробовать использовать зод на фронте, надеюсь там есть не только проверка типов но и допом можно накатить валидации как в joi
Сколько же костылей навалили на js, не успеваешь изучать :)
Чем больше разрабатываешь на нем - тем больше хочется уйти в какой-нибудь с++ или java.
Очень не хватало такого контента!
Я так и сделал. Это дошло уже до шизофрении. В js инструмент на инструменте инструментом погоняет. Потому что ни один не делает работу хорошо. В ts не лучше, хотя и он инструмент над js.
Современный фронт на джаве или плюсах не напишешь
Про сервер я молчу, там подобные языки топ
@@user-yp3rz4ij2v ну я имел ввиду вообще с фронта ушел. Как часто говорят в фильмах... Слишком стар я стал для этого дерьма).
Ну да ну да. Пример из самого видео - бэкэнд выслал не пойми какие данные, пользователь в качестве эксперимента поменял что-то в localStorage. Но виноват, конечно же, фронтэнд и js 😆
ZOD
Есть valibot который очень лёгкий
Ну посмотри тогда размер пакета в npm Zod меньше весит чем Valibot. или я не прав?
typescript делает простые вещи сложными, а сложные any... В итоге все равно в обычный js собирается, так может typescript - лишнее ? 😀
Не представляю как без ts делать проекты на 100к строк кода и больше
согласен, но рил чем больше проект разростается - тем сложнее держать всё в голове :_( это слёзы, но как же заколебал typescript..... почему тяжело сделать нечто шедевральное и крутое как c#.....?????
@@paromovevg ты просто не умеешь
херня какая-то такая же как и typescript