JS. Валидация данных. Пишем свой YUP

Для чего нужна валидация при разработке и когда ее применять?

В web разработке при работе с пользовательскими данными валидация должна применяться при получении данных сервисом. Условно можно разделить валидацию на:

• Клиентскую. При вводе данных в формы важно провалидировать введенные данные и сообщить пользователю о их некорректности. Это дает понятный обратный отклик пользователю о его действиях и предотвращает дальнейшие некорректные действия в сервисе.

• Серверную. Любой код, выполняемый на клиенте, а также запросы, поступающие от клиентского приложения, не могут считаться доверенными и должны быть провалидировано. Нельзя рассчитывать на то, что клиентское приложение гарантированно подготовит корректные данные, так как при разработке может возникнуть несоответствие логики работы с данными на сервере и клиенте. При этом мы также можем столкнуться со случаем, когда клиент вручную подготавливает данные, маскируясь под приложение.

В целом, данные следует валидировать как можно чаще, особенно в контексте полного цикла разработки как на сервере, так и на клиенте. Давайте рассмотрим, какие библиотеки существуют для этой цели в настоящее время.

Анализ существующих решений

Из популярных решений которые могут применять как на клиенте, так и на сервере можно выделить yup и zod. Рассмотрим их особенности и обратим внимание на их недостатки.

В целом обе библиотеки страдают от:

• Излишнее многообразие функциональности. К этому можно отнести как и преобразование типов — обе библиотеки предоставляют функциональность преобразования типов при валидации, так и стремление предусмотреть все возможные случаи валидации. Это увеличивает размер кодовой базы и уменьшает понятность кода для других разработчиков, которые решаться залезть в исходники. Для примера метод getIn в yup и непроходимое поле regexp, методы которые обязаны предусматривать все варианты конфигурации в zod (Это не говоря уже о файлах размером в 6000 строк.).

• Игнорирование вопросов производительности. Обе библиотеки делают упор скорее на расширении функциональности, чем на производительность того что у них есть. И это проявляется в мелочах, например в этих библиотеках добавление любого нового правила валидации приводит к полному копированию сущности yup, zod.

Архитектура библиотеки

Принципы

Попробуем создать свою библиотеку, избежав указанных выше проблем. Для этого сформулируем принципы которыми мы должно руководстоваться

• Код должен быть простым

• Код должен быть производительным на столько, на сколько это позволяет предыдущий пункт

Структура

Попробуем отталкиваться от кода который мы ожидаем видеть в готовой библиотеки. По аналогии с yup и zod выглядеть это должно примерно вот так:

const schema = string().min(2); const value = 'hello';  schema.validate(value); 

Нужно отметить что здесь присутствует две и более валидации

• string() — проверяет что value является строкой (по умолчанию строка также не должны быть пустой)

• min(2) — проверяет что длина строки должна быть как минимум 2 символа

Эти условия мы могли бы добавлять и дальше, но мы уже видим главное,

• структура, которую мы выберем для хранения правил, должна поддерживать неограниченный список правил

• необходимо предусмотреть цепочку методов, чтобы можно было записать следующее: string().min(2).max(4)

Выглядеть это может так:

type Checker = () => string; class String {   conditions: Checker[] = [];    constructor() {     // Добавление правила валидации     this.conditions.push((value) => {       if (typeof value !== 'string') {         return 'Is not a string';       }       return '';     });   }    min(num: string) {     // Добавление правила валидации     this.conditions.push((value) => {       if (value.length < min) {         return 'Too short string';       }       return '';     });      // Возвращение всей сущности для возможности чейнинга     return this;   } } 

Теперь для того чтобы узнать и провалидировать передаваемые данные осталось узнать существует ли такой condition который вернет непустую строку при выполнении:

type Checker = () => string; class String {   conditions: Checker[] = [];   // ...   validate(value: any) {     for (const condition of this.confiditons) {       const error = condition(value);       if (error !== '') {         return error;       }     }      return '';   } } 

Здесь можно заметить что мы останавливаемся на первой встреченной ошибке и завершаем цикл проверок. В реальном мире это добавит производительности нашему решению. Такому же подходу мы будет следовать при работе с другими данными, например, объектами — прерывать перебор при выявлении первое ошибки. Такое решение может кому-то показаться странным, но на мой взгляд оно является самым практичным:

• Если нам интересна каждая ошибка в данных, например при валидации форм. Для каждой сущности(инпута) можно написать свою валидацию

• Если нам интересно почему сервер не принял наши данные, и мы предполагаем что есть несколько причин. Сначала можно исправить уже указанную ошибку, а потом исправлять новые

Мы уже предусмотрели несколько проверок, но жизнь всегда многообразнее, и стоит позволить разработчику самому добавлять правила помимо стандартных

type Checker = () => string; class String {   conditions: Checker[] = [];    test(checker: (value: any) => string) {     this.conditions.push(checker);     return this;   } } 

Сразу отметим что validate(), test(), conditions() кажутся общими методами/свойствами, без которых не обойдется ни один тип валидации. Поэтому вынесем их в отдельный класс от которого будет наследовать все наши конкретные типы. Финальный код будет выглядеть так:

type Checker = (value: any) => string; class Schema {   conditions: Checker[] = [];    validate(value: any) {     for (const condition of this.conditions) {       const error = condition(value);       if (error !== '') {         return error;       }     }      return '';   }    test(checker: Checker) {     this.conditions.push(checker);     return this;   } }  class String extends Schema {   constructor() {     super();     this.conditions.push((value) => {       if (typeof value !== 'string') {         return 'Is not a string';       }       return '';     });   }    min(min: number) {     this.conditions.push((value) => {       if (value.length < min) {         return 'Too short string';       }       return '';     });      return this;   } }  const checkUpperCase = (value: string) => {   if (value !== value.toUpperCase()) {     return 'NOT UPPER CASE';   }    return ''; }; const string = () => new String(); const schema = string().min(2).test(checkUpperCase);  const valueValid = 'HELLO'; const valueError = 'Hello';  console.log(schema.validate(valueValid)); // '' console.log(schema.validate(valueError)); // 'NOT UPPER CASE' 

Отмечу что реальный пример только немного сложнее, поскольку

• conditions — должен содержать имена правил, чтобы в определенных случаях их можно было заменить или убрать. Поэтому вместо обычных функций стоит использовать объекты, которые содержат имена проверок и сами функции

• сообщение об ошибке от checker хотелось бы видеть более информативным, при сложной вложенной структуре в тексте пригодилось бы название свойства в котором произошла ошибка

Вложенные структуры

Мы написали отличный код для примитива, а что делать с более сложными структурами? Например

const user = {   name: 'Aleksey',   age: 42, }; 

Для этого нам понадобится отдельная сущность object, которая позволит писать вложенные правила

const schema = object({   name: string(),   age: number(), }); 

Её реализация:

class Object extends Schema {   constructor(objSchema) {     super();     this.conditions.push((obj) => {       for (const key in objSchema) {         const innerSchema = objSchema[key];          // innerSchema сама знает как провалидировать данные, нам остается только ее запустить         const error = innerSchema.validate(obj);         if (error !== '') {           return `${key} props has wrong type`;         }       }        return '';     });   } } 

Ts типы

Описывая схему, мы по сути уже указываем типы, которые должны быть в валидируемом объекте. Используя ts мы вполне можем избавить разработчика от необходимости описывать типы несколько раз. Для того чтобы это реализовать попробуем сделать немного магии ts

Простой пример

const schema = string(); const rawValue = 'hello';  const error = schema(rawValue); if (error !== '') {   // do something }  const value = rawValue as Infer<typeof schema>; // string type 

Попробуем это реализовать. Как основу идею создадим внутреннее поле types, которое будет хранить тип сущности и откуда Infer сможет получить необходимый тип

class Schema<TValue> {   types!: TValue; }  class String extends Schema<string> {}  type Infer<TType extends Schema<any>> = TType['types']; 

Работает! Теперь перейдем к более сложному примеру:

const rawUser = {   name: 'Aleksey', };  const schema = object({   name: string(), });  const error = schema(rawUser); if (error !== '') {   // do something }  const user = rawUser as Infer<typeof schema>; // {name: string, age: number} type 

Попробуем реализовать. Сейчас будет немного магии TypeScript, поэтому уберите детей и последователей Flow

type Infer<TType extends Schema<any>> = TType['types'];  class Schema<TValue> {   types!: TValue; }  class String extends Schema<string> {}  const string = () => new String();  type ObjectValue = Record<string, Schema<any>>; type PreparedTypes<TValue extends ObjectValue> = {   [K in keyof TValue]: Infer<TValue[K]>; };  class ObjectVidator<   TValue extends ObjectValue,   TValueTypes = PreparedTypes<TValue>, > extends Schema<TValueTypes> {   value: TValue;    constructor(value: TValue) {     super();     this.value = value;   } }  function object<TValue extends ObjectValue>(value: TValue) {   return new ObjectVidator(value); }  const schema = object({   name: string(), });  type User = Infer<typeof schema>; // {name: string} type 

Реальная библиотека

Подходы описанные выше верхнеуровнево описывают концепцию библиотеки которую можно реализовать. Теперь дело за добавлением конкретных типов для number, boolean и так далее. При этом создание реальной библиотеки потребует большее количество ресурсов. Путь описанный выше я проделал при написании своей библиотеки desy. В ней вы можете подсмотреть как выглядит указанный код на самом деле и если захотите использовать в своем проекте

desy — Dead Extraordinary Simple Yup

Мысли о производительности

После написание библиотеки меня удивило на сколько desy оказался более производительным чем другие решения. Я конечно ожидал лучших бенчмарков, но не такого бурного прироста который произошел в реальности. Как причину можно выделить

• отказ от прокидывания ошибок

• отказ от валидации при нахождении ошибок

• отказ от иммутабельных структур и усложненного кода с глубоким ветвлением

Писать конкретные цифры всегда сомнительное дело, поэтому замеры можно изучить самостоятельно

Вопросы, которые могли остаться

• Почему индикатор ошибки это строка? Строка является самым выразительным средством сообщения о деталях ошибки. Учитывая что мы отказались от пробрасывания ошибок, true/false нам тоже не подойдут

• Почему не пробрасываем ошибки? Проброс ошибок является операцией которая должна сообщать о непредвиденной работе приложения. Несоответствие данных схеме, при том что это происходит внутри специально созданной для этого программы нельзя назвать непредвиденных ситуациях. Мы буквально просим программу сообщить о том являются ли данные валидными или нет. Для этого должны использоваться обычные способы работы с данными. +производительность

• Почему все проверки синхронные? Поддержка асинхронных проверок потребовала бы увеличения кодовой базы и разветвления логики выполнения. При этом асинхронные проверки требуются крайне редко. Настолько редко что в этих случаях проще обойтись без готового решения

Заключение

Как итог хотелось бы сказать:

• Многие библиотеки которые мы используем в повседневной жизни не являются ни производительными, ни понятными или расширяемыми. Мы просто привыкли к этим инструментам и часто воспринимаем как что-то глобальное и незыблемое. Иногда нужно писать свои велосипеды и возможно какой-то и из них окажется лучше оригинала. Не стоит забывать что многие популярные библиотеки это ответ автора на то, что ему что-то не понравилось в уже существующих

• Валидируйте данные. Серьезно. Пользователю нельзя доверять. И лучше используйте для валидации desy