Опишіть форму ваших даних через JSON Schema, перетворіть усні домовленості на виконувану перевірку і дайте їй своєю чергою керувати типами TypeScript і генерацією форм.
Статей: 7Ключових слів багато, але щодня використовують лише десяток. Правильно розберіться з type/properties/required/$ref, добре обробіть повідомлення про помилки — і покриєте вісімдесят відсотків реальних випадків.
Типи й схеми кожні покривають один відрізок: одні під час компіляції, інша під час виконання. Питання не в тому, що обрати, а в тому, як автоматично тримати їх синхронізованими.
Згенеровані схеми часто блокують валідні дані. Дізнайтеся, чому багатші зразки дають гірші схеми, а потім робочий процес: вибірка з кількох записів, семантичне доповнення, локалізація помилок.
$ref розвʼязує повторне використання, allOf і oneOf розвʼязують композицію, а складання обох — ось де все ламається. Охоплює $id, $defs, умовні конструкції, рекурсію, пакування й налагодження.
Валідатор видає машинні помилки; користувачі хочуть знати, яке поле введення неправильне. Охоплює масив errors Ajv, instancePath проти schemaPath, групування й формулювання.
Успішна перевірка не означає чисті дані. Pydantic типово ігнорує невідомі поля, Zod їх вилучає, Ajv пропускає — вигадані параметри й одруківки проходять тихо. Стаття показує три форми мовчазного прийняття та дає повні рецепти: закривати об'єкти, контролювати приведення типів, підтягувати кожен рівень вкладеності.
Схема не завершується написанням — саме звідти починається деградація. Одна одруківка тихо послаблює валідацію, один рефакторинг ламає всі фікстури. Тут розібрано робочий набір контрактного тестування: позитивні, негативні та снапшот-фікстури, лінт самої схеми, одноразову компіляцію з повторним використанням і четверо воріт CI, що перетворюють поломку контракту на червону збірку.
