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

В этом видео я покажу на примере React/Typescript приложения паттерн "Молодая советская республика в кольце врагов". А именно как с помощью zod защититься от не валидных входных данных
Подписывайтесь на мой telegram канал:
t.me/cleanfrontend
Исходники:
codesandbox.io/s/react-typesc...

[@user-vm2db5cq1g]

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

[@bandiwor8823]

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

[@user-td3bz8st6v]

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

[@hrustalevdev]

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

[@RussianFrontend]

null-object , имеешь ввиду , что поставляешь какой-то фиктивный объект, в случае если данные извне не проходят валидацию ?

[@d3i0]

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

[@KichaViruSkin]

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

[@Artur-pk3sw]

Не всегда спасает, например была ситуация когда мне нужно в схему прокинуть значение из вне, в yup это все кладется в контекст и в .when его можно отловить, в zod такого нет

[@Ramosok]

Круто!

[@user-hruser]

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

[@r0mm4k]

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

[@user-re7zb6oo2s]

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

[@paromovevg]

С graphql нет смысла это делать, так как сам транспортный уровень даёт определённые гарантии. По поводу иконок. Сам ещё не выработал однозначной позиции. Есть 2 варианта 1. Склеивать иконки в спрайт 2. Хранить иконки как обычные компоненты в JSX У второго варианта лучший DX но у первого варианта лучше производительность, можно статически закешировать

[@user-re7zb6oo2s]

@@paromovevg тоже метаюсь между этими двумя вариантами. Мне кажется эта прикольная идея для видео показать какие вы инструменты например для спрайта и другое

[@viktorkasap]

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

[@windus08]

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

[@paromovevg]

Оверхедный - точно. Костылинг на вряд ли. В моем понимании если что то работает с любыми вводными и выдает гарантии соответствия данных типам это очень даже (а какой антоним костыльно?)

[@windus08]

@@paromovevg костылинг это то, что вместо налаживания процессов(это можно делать даже не кулаками по лицу бекендера, а объяснив бизнесу сколько они теряют в бабках из-за этого овоща) мы занимаемся подкладыванием соломки везде

[@user-td3bz8st6v]

@@paromovevg приемлемо думаю отлично подойдет

[@hrustalevdev]

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

[@CJIu3eHb]

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

[@awenn2015]

А какой смысл отслеживать get строку если роутера нет и любое изменение фактически будет только при перезагрузки страницы

[@user-ki9oy7zq3q]

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

[@iliasorokin6674]

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

[@madbad1310]

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

[@izzy7541]

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

[@paromovevg]

То использование инструмента, которое я показал в видео про улучшение DX. (Возможно нужно было лучше в видео акценты расставить) Про то что бы получать ошибки как можно раньше. Условно сделал git pull а там новая переменная среды которой в твоем .env нет. Ты сразу получаешь ошибку То что в localStorage у тебя старая версия данных после внесения изменений тоже быстро узнаешь Что ты набрал из полей форму и отпечатался в имени одного из филдов. На самом деле из таких мелочей складывается очень приятный DX И да есть тесты, но не все по TDD пишут что бы такое тестами отлавливать Если это клиентское приложение в котором важен размер бандла тащить такое не стоит (не считая приложений с действительно сложными формами) Но не для всех приложений это актуально, люди подключают либы на 100кб и живут нормально если это условный внутренний интерфейс, где люди подождут, но разработка ускориться