#zod — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #zod, aggregated by home.social.
-
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/
-
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/
-
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/
-
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/
-
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/
-
Random Old Comic: Schtick https://www.toyboxcomix.com/2020/01/06/schtick/ Schtick #DC #DorothyZbornak #Fortnite #GoldenGirls #Peely #Zod
-
Zod y el Riesgo de Denegación de…
Zod es una biblioteca de validación de esquemas para JavaScript y TypeScript que permite definir y validar estructuras de datos de manera sencilla. El método .refine() se utiliza para aplicar validaciones personalizadas sobre los datos que se están validando.
https://norvik.tech/news/analisis-zod-refine-denial-of-service
#Technology #Zod #Refine #DenegacionDeServicio #ValidacionDeEntradas #NorvikTech #DesarrolloSoftware #TechInnovation
-
Формы как контракт в 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 #вебразработка
-
Формы как контракт в 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 #вебразработка
-
Формы как контракт в 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 #вебразработка
-
Формы как контракт в 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 #вебразработка
-
Согласованность API по принципу единого источника истины
Представим ситуацию: идет тяжёлый спринт, вы выполнили кучу задач, написали тонну нового функционала, готовитесь к релизу и вдруг обнаруживайте, что часть фич перестала работать! Идёте разбираться и обнаруживайте, что оказывается бэкендер Вася в последний момент решил переименовать поля в json-е, а вам об этом не сказал! Ситуация образная, но позволяет быстро обрисовать одну из болей во время разработки. В этой статье я бы хотел рассказать об одном из вариантов её решения в коде с помощью подхода Единого источника истины(Single source of truth).
https://habr.com/ru/articles/1003398/
#API #honojs #zod #RPC #SSOT #OpenAPI #typescript #monorepo #javascript
-
Согласованность API по принципу единого источника истины
Представим ситуацию: идет тяжёлый спринт, вы выполнили кучу задач, написали тонну нового функционала, готовитесь к релизу и вдруг обнаруживайте, что часть фич перестала работать! Идёте разбираться и обнаруживайте, что оказывается бэкендер Вася в последний момент решил переименовать поля в json-е, а вам об этом не сказал! Ситуация образная, но позволяет быстро обрисовать одну из болей во время разработки. В этой статье я бы хотел рассказать об одном из вариантов её решения в коде с помощью подхода Единого источника истины(Single source of truth).
https://habr.com/ru/articles/1003398/
#API #honojs #zod #RPC #SSOT #OpenAPI #typescript #monorepo #javascript
-
Согласованность API по принципу единого источника истины
Представим ситуацию: идет тяжёлый спринт, вы выполнили кучу задач, написали тонну нового функционала, готовитесь к релизу и вдруг обнаруживайте, что часть фич перестала работать! Идёте разбираться и обнаруживайте, что оказывается бэкендер Вася в последний момент решил переименовать поля в json-е, а вам об этом не сказал! Ситуация образная, но позволяет быстро обрисовать одну из болей во время разработки. В этой статье я бы хотел рассказать об одном из вариантов её решения в коде с помощью подхода Единого источника истины(Single source of truth).
https://habr.com/ru/articles/1003398/
#API #honojs #zod #RPC #SSOT #OpenAPI #typescript #monorepo #javascript
-
Согласованность API по принципу единого источника истины
Представим ситуацию: идет тяжёлый спринт, вы выполнили кучу задач, написали тонну нового функционала, готовитесь к релизу и вдруг обнаруживайте, что часть фич перестала работать! Идёте разбираться и обнаруживайте, что оказывается бэкендер Вася в последний момент решил переименовать поля в json-е, а вам об этом не сказал! Ситуация образная, но позволяет быстро обрисовать одну из болей во время разработки. В этой статье я бы хотел рассказать об одном из вариантов её решения в коде с помощью подхода Единого источника истины(Single source of truth).
https://habr.com/ru/articles/1003398/
#API #honojs #zod #RPC #SSOT #OpenAPI #typescript #monorepo #javascript
-
Zod: строгая валидация и удобная типизация. Опыт перехода
Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру. В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных. К Zod мы пришли не сразу. Долгое время типы и валидация у нас жили в разных слоях приложения: TypeScript определял структуру данных во время разработки, а отдельные функции или библиотеки (вроде Yup) проверяли входящие значения в рантайме. Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string') ? С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.
https://habr.com/ru/companies/banki/articles/994886/
#zod #typescript #валидация_данных #runtime_валидация #react_hook_form #типизация_данных #frontend_разработка #валидация_форм #developer_experience #валидация
-
🎬 Rich actions with confirmation dialogs, onSuccess & onError callbacks
👁️ Conditional visibility based on data, auth, or complex logic
📦 Two packages: @.json-render/core (types, schemas) + @.json-render/react (renderer, hooks)🔧 Schema definition with #Zod for type-safe component props
📤 Export as standalone #React code with no runtime dependencies -
Хроники Valibot: как мы искали безупречные данные в мире JavaScript
Если вы когда-нибудь писали фронтенд на TypeScript и получали в проде Cannot read property 'x' of undefined , — добро пожаловать в клуб! TypeScript спасает нас от сотен ошибок… но только пока код не запущен. Как только он скомпилировался, типы исчезают, и в рантайме вы снова остаетесь один на один с невалидными данными. И вот тут начинается: меняется API, формы шлют что угодно, аналитика ломает отчёты, а тесты молчат. В Островке мы попробовали библиотеку Valibot — легковесный runtime-валидатор, который умеет проверять данные на границах контекстов и при этом остаётся дружелюбным к TypeScript . Под катом рассказываем, почему статической типизации уже недостаточно, чем Valibot отличается от Zod, и как валидатор помогает нам строить более надёжную архитектуру без лишнего кода.
https://habr.com/ru/companies/ostrovok/articles/987380/
#valibot #zod #architecture #forms #js #валидация_данных #runtime #формы #api #типобезопасность
-
Random Old Comic: Feel https://www.toyboxcomix.com/2018/02/01/feel/ Feel #DC #DorothyZbornak #Finn #PoeDameron #StarWars #Zod
-
J'applique systématiquement la même logique avec Zod mais dans `src/config.ts`. Ça permet d'éviter de nombreux problèmes au runtime.
Pour éviter les appels à `process.env`, il est possible d'utiliser la règle ESLint `n/no-process-env` et d'ajouter une exception pour le seul fichier `src/config.ts`.
🔗 https://tsev.dev/posts/2025-12-03-safe-environment-variables-in-javascript/
-
Un standard pour les lib de validation TypeScript (Zod, Valibot, etc.).
L'objectif est d'avoir une spec standardisée pour que les outils interagissant avec ces schémas fonctionnent quel que soit la lib de validation choisie. Un peu comme les PSR rn PHP.
Vitest supporte d'ailleurs ce format depuis la v4, pour rendre certaines assertions plus faciles à écrire.
-
Структура против хаоса — практическая валидация форм с помощью Zod
Всем привет, с вами Артем Леванов, Front Lead в компании WebRise. В прошлой статье мы разобрали, как навести порядок в создании форм — выделили примитивы, ячейки и типовые поля. Следующая проблема, с которой сталкивается любая форма — валидация . Формы могут быть красивыми и структурными, но без единого подхода к валидации они быстро превращаются в хаос. В этой статье поговорим о том, почему встроенные и кастомные проверки плохо масштабируются, особенно в динамических формах, и как Zod решает эту проблему, превращая валидацию в декларативную и типобезопасную систему.
https://habr.com/ru/articles/967540/
#reactjs #react #zod #валидация #валидация_форм #typescript #javascript #валидация_htmlформ
-
A few months ago I published a #rust crate that generates #typescript and #zod boilerplate from #tauri commands. I never thought anyone else would use it and opened my repo to see two pull requests and a few issues added to the tracker. There's obviously a few gaps due to messy development but it gets the job done.
-
Comment utiliser Zod en pratique pour valider les variables d'environnement, les configurations, les *payloads* reçues de vos utilisateurs, etc.
-
Zod-valid. Безопасная валидация API данных
Zod-valid — это Typescript библиотека, зависимая от другой известной библиотеки zod , для безопасной валидации API данных. API редко гарантирует идеальные данные: поля могут быть пропущены, типы не совпадать, структуры меняться. Без проверки этих данных приложение рискует вызвать runtime-ошибки или ломать бизнес-логику. Валидировать данные заранее — значит обеспечить предсказуемое поведение и защитить приложение от неожиданных значений.
-
First day in Mastodon after coming from Twitter vs One week later
-
Random Old Comic: Insomnia https://www.toyboxcomix.com/2018/03/29/insomnia/ Insomnia Suggested by M "Something Sarcastic" Sipher. #DC #DorothyZbornak #GoldenGirls #Zod
-
I kneel before Zod. Always have, always will. #TerenceStamp #Zod #Legend #Actor #Movies
-
Простая и мощная валидация форм для SolidJS с Zod
solidjs-hook-form — библиотека для удобной и быстрой работы с формами в SolidJS. Использует Zod для мощной валидации и встроенную реактивность SolidJS для высокой производительности. Легковесная, не навязывает стили и дает полный контроль над UI. Идеальна для разработчиков, которые хотят меньше возиться с формами и больше фокусироваться на логике приложения. Попробуйте, если работаете с SolidJS — возможно, это то, что вам нужно!
https://habr.com/ru/articles/936196/
#Typescript #solidjs #javascript #Frontend #form #form_validation #zod #forms #jsx #tsx
-
zod vs typebox: Which one you'd prefer, and why?
-
Наводим порядок в загрузке данных Angular с помощью резолверов
Всем привет! Сегодня хочу разобрать кейс, с которым сталкивается почти каждый Angular-разработчик на существующем проекте. Часто в компонентах можно встретить такой код:
https://habr.com/ru/articles/922376/
#angular #resolver #zod #cache #javascript #typescript #frontend #web #perfomance
-
Random Old Comic: Schtick https://www.toyboxcomix.com/2020/01/06/schtick/ Schtick #DC #DorothyZbornak #Fortnite #GoldenGirls #Peely #Zod
-
ArkType: Ergonomic TS validator 100x faster than Zod
#HackerNews #ArkType #Ergonomic #TS #validator #100x #faster #than #Zod #Ergonomics #TypeScript #Validation #Speed #Performance
