Zod: Защищаем приложение от пользователя и нерадивых бекендеров 

Круто! побольше таких видео по кейсам с реальной разработки и разных практик реализаций! Спасибо за контент и канал!

Спасибо за видео! 2 недели назад только рассказал команде про необходимость валидации DTOшек, прилетающих из разнообразных сервисов. Только я взял для примера `yup`, но не суть. Бонусом также рассказывал про пользу использования объектов-заглушек/null-object, в случае невалидных данных.

Спасибо за твои видео!!!! много информации как это все вложить в голову )))))

Привет, спасибо большое за уроки!

Хорошая тема, у меня штуки по типу Zod,Yup как-то плотно ассоциировались с валидацией форм. Мы на своём проекте Json Schema юзаем для валидации входных параметров.

Никогда не понимал использование этих штук для "валидации" чего-то кроме форм. Вы просто в браузер клиента тащите 13кб мёртвого кода и используете 1% от него. Для сложных форм это может быть оправдано, но и то лучше взять более точечные и лёгкие решения. Зачем валидировать всё подряд то? Хотите проверить какое-то значение и получить тайп гвард? Возьмите tiny-invatiant, его хватит с головой, вы просто сможете выбросить исключение если получите не то что ждали и дадите пользователю понять что произошло, а не будете тратить ресурсы чтобы проверить то что проверять не надо и всё равно выбросите исключение. А на вопрос "Кто знает что туда придёт что-то не то?" ответ простой. Знаете об этом вы, кто написал этот код. И тесты, которые надо написать на свой код, чтобы удостоверится в правильности его работы. Аргументы про "у нас маленькая команда, мы тесты не пишем" не принимаются. Значит вы расписываетесь в том что ваш код вы не контролируете и вам не важно правильно он работает или нет. Валидация этой либой переменных окружения это вообще абсурд. Вы не полном серьёзе, в рантайме, в браузере клиенте, скармливаете тонну нодовских переменных, прокидывая всё это добра на клиент? Чтобы при билде приложения удостоверится в наличии нужны строк из .env файла? Подумайте сами что происходит в этот момент. Не могу я представить такой ситуации, когда при билде вы прокинули весь нодовский process в браузер, а потом произошла магия и что-то там не пришло? Ну это бред, проверка ни на что. Любой популярный сборщик (в webpack-e и vite-e это ключ define) умеет прокидывать глобально нужные данные. При сборке приложения прокиньте какие вам нужно переменные на клиент и не тащите туда огромный process. И при билде приложения у вас всё будет безопасно, а если что-то не то будет в env файле, то просто упадёт сборка.

zod еще можно использовать в связке с react-hook-form/resolvers/zod , и потом через errors вывести ошибки валидации прямо на саму форму.

Мне понравилось, очень информативно. Плюс можно посмотреть исходник.

Похоже на оверхедный костылинг🤔

Есть же default, чтоб с ошибкой не падал, будет значение по умолчанию

Круто!

В хуке useQueryParams на 11:08 получается нет подписки на изменение строки поиска? И *const paramsKey = key as keyof P;* вполне заменяется на *const paramsKey: keyof P = key;* , если нет необходимости использовать приведение, то лучше не использовать, ибо as - это что-то вроде варнинга, указывающего на тонкое место. Насчет делать ли индивидуальную валидацию и ли общую при отправке - это как заказчик решит (хотя он может и не думать об этом, тогда все на твое усмотрение). Ударим дирижаблями zod по контре нерадивых бекендеров и злокозненных юзеров! А если серьезно, то применять или нет - зависит от конторы/проекта. А то может так быть, что некогда валидацией заниматься, не говоря уже про тесты.

что-то сломалось у зода видомо, больше не показывает ошибки в таком виде 😔

Зависит от бизнеса, если бизнесу важно для 0.01 процента тех кто себе стреляет в ногу, делать дополнительную работу, то делать, если бизнес не заинтересован - не делать

Евгений, а zod есть ли смысл использовать с graphQl? Или это лишнее? И еще вопрос. Под предыдущими роликами задавал. Как мы работаете с svg и изображениями в целом?

Привет, как логаете в Sentry? Есть какие-то глобал настройки или все точечно?

Опечатка на превью

"нерадивых бекендеров", мдя, совсем вы, фронтмены обленились и обнаглели. То что раньше называлось сделать свою работу отказоустойчивой а код продуманным, теперь называется "сделать одолжение нерадивому глупому беку".