출처: 조드

#zod.kr

https://share.google/zEUcTN3yKe0BBy7iP

David Warrington from #Shopify also joins us next Thursday 28th May: He'll be taking #Zod beyond basic data validation with this #TypeScript-first validation library.

(Picture possibly unrelated. This isn't David, nor does it represent his presentation style… TBC)
#FrontEndSheff #Sheffield #JavaScript

https://www.meetup.com/front-end-sheffield/events/314557160/

At our Thursday 28th May #FrontEndSheff meetup:

🕶️ Thomas Baker introduces us to Sass - that's Syntactically *Awesome* Style Sheets and makes the case against just using 'vanilla' #CSS
🛍️ David Warrington from #Shopify declares that #TypeScript isn't enough… not without the #Zod validation library

🎟️ Available now: https://www.meetup.com/front-end-sheffield/events/314557160/

Формы как контракт в Next.js: Zod, fieldErrors и одинаковые правила на client и server

С формами в Next.js проблема обычно начинается не на уровне кнопки submit. Кнопка как раз почти всегда работает. Настоящая путаница начинается позже, когда форма уже живёт в проекте какое-то время. В одном месте ошибка показывается под полем, в другом только общей строкой сверху. Где-то кнопка блокируется на pending, а где-то можно отправить запрос несколько раз подряд. Клиент считает данные валидными, а сервер отвечает, что правило нарушено. Поле уже зелёное, а сохранение всё равно не прошло. В этот момент становится видно, что форма была собрана как кусок UI, а не как контракт. Используем как примеры паттерны из проекта Workbench. Полезно смотреть на форму не как на набор input и submit, а как на договор между UI, валидацией и местом записи данных. У такого договора есть простая форма - какие данные считаются допустимыми, где и как они проверяются, в каком виде ошибка возвращается в интерфейс, что происходит на pending, когда форма блокируется, что считается успехом, а что общей ошибкой, не привязанной к конкретному полю. Как только форма описывается так, код перестаёт расползаться. И здесь Zod в Next.js даёт не просто удобную схему, а способ удерживать client и server в одном наборе правил.

https://habr.com/ru/articles/1025472/

#nextjs #typescript #app_router #zod #forms #validation #react #вебразработка

Как я написал свою библиотеку валидации схем и создал свою альтернативу Zod

Несколько лет назад в одном из моих проектов на чистом JavaScript возникла задача: валидировать большие вложенные объекты со сложной структурой. Объекты содержали различные подобъекты, к каждому из которых применялись свои правила валидации в зависимости от типа. Задача усложнялась двумя дополнительными требованиями:

https://habr.com/ru/articles/1023038/

#валидация #схема #standard_schema #zod #zod_vs_yup #typescript

TypeScript в Next.js как система контрактов, а не типизация ради типизации

Когда разработчик начинает писать на Next.js с TypeScript, первая реакция часто довольно холодная. Вместо того чтобы двигаться быстрее, он начинает чаще видеть ошибки. Где-то не совпал shape объекта, где-то строка не подходит в более узкий тип, где-то TypeScript напоминает, что значение может быть undefined. На этом месте легко сделать неправильный вывод. Кажется, что TS просто добавляет трение и требует больше служебного кода. Обычно проблема не в TypeScript, а в способе мышления. Если использовать его как набор аннотаций поверх уже написанного кода, пользы действительно немного. Но если смотреть на типы как на систему контрактов между слоями приложения, картина меняется. Особенно в Next.js App Router, где у нас постоянно есть границы server и client, внешний ввод из URL, формы, мутации и разные состояния интерфейса. В этот момент TypeScript перестаёт быть типизацией ради типизации. Он начинает отвечать на более важный вопрос: какие состояния в проекте вообще допустимы, а какие не должны пройти дальше границы. По такой модели я выстроил один из своих проектов Workbench. Не начинать с мысли давайте везде поставим типы, а начинать с мысли где у нас проходит граница, что в неё входит и что из неё может выйти. После этого многие решения в коде становятся почти очевидными.

https://habr.com/ru/articles/1018382/

#nextjs #typescript #app_router #server_components #type_safety #zod #react #вебразработка