Zod. Основные преимущества и неочевидные кейсы использования

[KReal]

Звучит хорошо, звучит интересно. Но не нашёл ссылки на гитхаб)

[atomr_mf]

Вы имеете ввиду репозиторий с этими же примерами?) При написании статьи думал, что конкретных кусочков кода, которые должны навести на мысль как и где применить в своих проектах, должно хватить. В каждом проекте своя архитектура. Но скорее всего, вы правы, для полноты картины можно было этот код оформить в гите.

На будущее учту, спасибо)

[KReal]

Ну, я имел в виду, скорее, ссылку на то место, где можно ознакомиться с документацией и скачать что-то)

[VanKrock]

так на сайте на главной странице справа вверху треугольничек со значком гитхаба. Или вы не про это?

[KReal]

Так а где ссылка на сайт?)

[glebsts]

Использовал в одном проекте, было все хорошо на простых формах, а потом мне понадобилась сложная форма, где дополнительный сет полей был опционален в зависимости от одного булевого поля, плюс валидность значений некоторых полей зависела от значений других (например, два datepicker, начало и конец, конец не может быть раньше начала). Долго пытался сделать, наткнулся на обсуждение каких-то ограничений в zod, и пересел на joi (joi.dev), который оказался более гибким.

[evgeniyPP]

То, что Вы описали, легко делается через .refine (документация)

[glebsts]

Конкретно для nested set of fields (важная деталь, которую я не вписал в предыдущий компентарий) не нашел. Уже не вспомню деталей, но вроде как зод не мог парсить строковой референс на вложенное поле, был тред на SO, решение - joi. По ощущениям, реально более гибкая декларация вышла.

То есть, данные имели тип примерно

`{a:string; hasNested:boolean; nested: {start:Date; end:Date;}}`

По-моему, не работала связка с react-hook-form для name='nested.start'

Пишу с телефона, за точный синтаксис не поручусь.

[evgeniyPP]

Валидация данных с API и валидация форм – это как раз таки самые очевидные кейсы использования.

Неочевидный кейс – это, например, использовать Zod вместо автотестов на фронтенде. Вместо того, чтобы писать тесты, вы можете любые данные на входе, например, в функцию проверять через z.parse. Тогда при любой несостыковке при ручном проходе по интерфейсу тут же выпадает понятная ошибка на весь экран и баг тут же фиксится.

Или же, когда два типа вроде как должны сходиться, но не сходятся, и TypeScript не понимает и ругается, можно вместо использования as <type>, как это сейчас делается, писать тот же z.parse, чтобы подогнать тип. Тогда и TypeScript доволен, и вы уверены, что нигде не накосячили.

Еще можно валидировать параметры функции более тщательно, чем TypeScript это может.
Вот, например у меня функция, которая создает новый id:

type ObjectWithId = {
  id: number;
  [key: string]: unknown;
}

export function generateNewId<T extends ObjectWithId>(items: T[]) {
  return items.reduce((acc, cur) => Math.max(acc, cur.id), 0) + 1;
}

TypeScript проверит на число, но мне нужно именно целое и только положительное.
Zod поможет:

const objectWithIdSchema = z
  .object({
    id: z.number().int().positive(),
  })
  .passthrough();

type ObjectWithId = z.infer<typeof objectWithIdSchema>;

export function generateNewId<T extends ObjectWithId>(items: T[]) {
  const parsedItems = objectWithIdSchema.array().parse(items);
  return parsedItems.reduce((acc, cur) => Math.max(acc, cur.id), 0) + 1;
}