Zod: Защищаем приложение от пользователя и нерадивых бекендеров
HTML-код
- Опубликовано: 28 сен 2024
- В этом видео я покажу на примере React/Typescript приложения паттерн "Молодая советская республика в кольце врагов". А именно как с помощью zod защититься от не валидных входных данных
Подписывайтесь на мой telegram канал:
t.me/cleanfron...
Исходники:
codesandbox.io...
![[Limbus Company - Teaser] Season5 - Oblivion](http://i.ytimg.com/vi/8anKuEeZLeI/mqdefault.jpg)
Хорошая тема, у меня штуки по типу Zod,Yup как-то плотно ассоциировались с валидацией форм. Мы на своём проекте Json Schema юзаем для валидации входных параметров.
zod еще можно использовать в связке с react-hook-form/resolvers/zod , и потом через errors вывести ошибки валидации прямо на саму форму.
Не всегда спасает, например была ситуация когда мне нужно в схему прокинуть значение из вне, в yup это все кладется в контекст и в .when его можно отловить, в zod такого нет
Есть же default, чтоб с ошибкой не падал, будет значение по умолчанию
Круто! побольше таких видео по кейсам с реальной разработки и разных практик реализаций! Спасибо за контент и канал!
Никогда не понимал использование этих штук для "валидации" чего-то кроме форм. Вы просто в браузер клиента тащите 13кб мёртвого кода и используете 1% от него. Для сложных форм это может быть оправдано, но и то лучше взять более точечные и лёгкие решения. Зачем валидировать всё подряд то? Хотите проверить какое-то значение и получить тайп гвард? Возьмите tiny-invatiant, его хватит с головой, вы просто сможете выбросить исключение если получите не то что ждали и дадите пользователю понять что произошло, а не будете тратить ресурсы чтобы проверить то что проверять не надо и всё равно выбросите исключение.
А на вопрос "Кто знает что туда придёт что-то не то?" ответ простой. Знаете об этом вы, кто написал этот код. И тесты, которые надо написать на свой код, чтобы удостоверится в правильности его работы. Аргументы про "у нас маленькая команда, мы тесты не пишем" не принимаются. Значит вы расписываетесь в том что ваш код вы не контролируете и вам не важно правильно он работает или нет.
Валидация этой либой переменных окружения это вообще абсурд. Вы не полном серьёзе, в рантайме, в браузере клиенте, скармливаете тонну нодовских переменных, прокидывая всё это добра на клиент? Чтобы при билде приложения удостоверится в наличии нужны строк из .env файла? Подумайте сами что происходит в этот момент.
Не могу я представить такой ситуации, когда при билде вы прокинули весь нодовский process в браузер, а потом произошла магия и что-то там не пришло? Ну это бред, проверка ни на что.
Любой популярный сборщик (в webpack-e и vite-e это ключ define) умеет прокидывать глобально нужные данные. При сборке приложения прокиньте какие вам нужно переменные на клиент и не тащите туда огромный process. И при билде приложения у вас всё будет безопасно, а если что-то не то будет в env файле, то просто упадёт сборка.
То использование инструмента, которое я показал в видео про улучшение DX. (Возможно нужно было лучше в видео акценты расставить) Про то что бы получать ошибки как можно раньше. Условно сделал git pull а там новая переменная среды которой в твоем .env нет. Ты сразу получаешь ошибку
То что в localStorage у тебя старая версия данных после внесения изменений тоже быстро узнаешь
Что ты набрал из полей форму и отпечатался в имени одного из филдов. На самом деле из таких мелочей складывается очень приятный DX
И да есть тесты, но не все по TDD пишут что бы такое тестами отлавливать
Если это клиентское приложение в котором важен размер бандла тащить такое не стоит (не считая приложений с действительно сложными формами)
Но не для всех приложений это актуально, люди подключают либы на 100кб и живут нормально если это условный внутренний интерфейс, где люди подождут, но разработка ускориться
Привет, как логаете в Sentry? Есть какие-то глобал настройки или все точечно?
что-то сломалось у зода видомо, больше не показывает ошибки в таком виде 😔
В хуке useQueryParams на 11:08 получается нет подписки на изменение строки поиска? И *const paramsKey = key as keyof P;* вполне заменяется на *const paramsKey: keyof P = key;* , если нет необходимости использовать приведение, то лучше не использовать, ибо as - это что-то вроде варнинга, указывающего на тонкое место.
Насчет делать ли индивидуальную валидацию и ли общую при отправке - это как заказчик решит (хотя он может и не думать об этом, тогда все на твое усмотрение).
Ударим дирижаблями zod по контре нерадивых бекендеров и злокозненных юзеров! А если серьезно, то применять или нет - зависит от конторы/проекта. А то может так быть, что некогда валидацией заниматься, не говоря уже про тесты.
А какой смысл отслеживать get строку если роутера нет и любое изменение фактически будет только при перезагрузки страницы
"нерадивых бекендеров", мдя, совсем вы, фронтмены обленились и обнаглели. То что раньше называлось сделать свою работу отказоустойчивой а код продуманным, теперь называется "сделать одолжение нерадивому глупому беку".
Похоже на оверхедный костылинг🤔
Оверхедный - точно. Костылинг на вряд ли.
В моем понимании если что то работает с любыми вводными и выдает гарантии соответствия данных типам это очень даже (а какой антоним костыльно?)
@@paromovevg костылинг это то, что вместо налаживания процессов(это можно делать даже не кулаками по лицу бекендера, а объяснив бизнесу сколько они теряют в бабках из-за этого овоща) мы занимаемся подкладыванием соломки везде
@@paromovevg приемлемо думаю отлично подойдет
@@windus08 , ну не так уж и везде, а там, где мы имеем дело со сторонними сервисами, за которые мы не отвечаем. Тем более есть более критические участки приложения, где желательно схему провалидировать, есть менее - там уже на ваше усмотрение
Спасибо за видео! 2 недели назад только рассказал команде про необходимость валидации DTOшек, прилетающих из разнообразных сервисов. Только я взял для примера `yup`, но не суть. Бонусом также рассказывал про пользу использования объектов-заглушек/null-object, в случае невалидных данных.
null-object , имеешь ввиду , что поставляешь какой-то фиктивный объект, в случае если данные извне не проходят валидацию ?
Привет, спасибо большое за уроки!
Спасибо за твои видео!!!! много информации как это все вложить в голову )))))
Зависит от бизнеса, если бизнесу важно для 0.01 процента тех кто себе стреляет в ногу, делать дополнительную работу, то делать, если бизнес не заинтересован - не делать
Мне понравилось, очень информативно. Плюс можно посмотреть исходник.
Опечатка на превью
Круто!
Евгений, а zod есть ли смысл использовать с graphQl? Или это лишнее? И еще вопрос. Под предыдущими роликами задавал. Как мы работаете с svg и изображениями в целом?
С graphql нет смысла это делать, так как сам транспортный уровень даёт определённые гарантии. По поводу иконок. Сам ещё не выработал однозначной позиции.
Есть 2 варианта
1. Склеивать иконки в спрайт
2. Хранить иконки как обычные компоненты в JSX
У второго варианта лучший DX но у первого варианта лучше производительность, можно статически закешировать
@@paromovevg тоже метаюсь между этими двумя вариантами. Мне кажется эта прикольная идея для видео показать какие вы инструменты например для спрайта и другое