Библиотека Vest построена вокруг декларативного описания правил
валидации, где каждая проверка рассматривается как независимый тест.
Утилиты и хелперы обеспечивают композицию, управление выполнением и
переиспользование логики валидации.
createSuite —
создание набора правил
Основная точка входа в описание валидации — создание набора правил
(suite). Он формирует изолированный контекст, в котором регистрируются
проверки.
Ключевые особенности:
- изоляция состояния между вызовами;
- ленивое выполнение проверок;
- возможность повторного запуска без пересоздания логики.
Внутри suite описываются тесты, которые затем выполняются по
требованию, а не в момент объявления.
test — базовая единица
проверки
Функция теста является центральной концепцией. Каждый вызов описывает
одно логическое условие.
Особенности механизма:
- тесты регистрируются, но не выполняются сразу;
- выполнение происходит при запуске валидации;
- порядок тестов сохраняется и может влиять на результат при
использовании раннего выхода.
Тест принимает:
- имя поля или контекста;
- описание условия;
- функцию проверки.
context — единый
источник данных
Контекст представляет собой объект с входными данными, которые
используются всеми проверками внутри suite.
Основные свойства:
- неизменяемость во время выполнения валидации;
- доступность во всех тестах;
- возможность расширения через вычисляемые поля.
Контекст позволяет централизовать доступ к данным формы или объекта,
исключая необходимость передачи параметров в каждый тест.
Управление выполнением
проверок
only — выборочная
активация тестов
Утилита only ограничивает выполнение набора правил
только указанными тестами. Это полезно при:
- отладке сложной валидации;
- частичной проверке формы;
- пошаговом заполнении данных.
Механизм работает как фильтр, исключая все тесты, не попавшие в
список активных.
skip — исключение
проверок
Функция skip позволяет отключить выполнение конкретных
правил без удаления их из кода.
Применение:
- временное отключение логики;
- переключение режимов валидации;
- условное подавление проверок.
В отличие от удаления, skip сохраняет структуру suite,
что важно для поддержки и читаемости.
include — условное
включение логики
include управляет динамическим подключением тестов на
основе состояния контекста.
Типичные сценарии:
- включение проверок только при заполнении определённых полей;
- активация дополнительных правил в зависимости от роли
пользователя;
- переключение режимов валидации (например, draft/submit).
Механизм работает на этапе построения или выполнения suite, в
зависимости от реализации.
Хелперы для построения
правил
enforce —
декларативные утверждения
enforce используется для описания условий в виде цепочки
утверждений. Это позволяет избегать ручных if-условий внутри тестов.
Основные возможности:
- цепочечный синтаксис;
- читаемость бизнес-логики;
- единообразие проверок.
Пример логики, выражаемой через enforce:
- проверка длины строки;
- сравнение значений;
- проверка диапазонов;
- комбинирование условий через логические операторы.
optional —
обработка необязательных полей
Хелпер optional позволяет корректно обрабатывать
отсутствующие значения.
Поведение:
- если значение отсутствует, тесты не выполняются;
- если значение присутствует, выполняются стандартные проверки.
Это устраняет необходимость вручную проверять null,
undefined или пустые строки в каждом тесте.
group — логическая
группировка правил
group объединяет набор тестов в логическую категорию.
Это упрощает:
- структурирование сложной валидации;
- повторное использование блоков правил;
- разделение ответственности между частями формы.
Группы могут:
- выполняться независимо;
- иметь собственные условия активации;
- использоваться повторно в разных suite.
Работа с асинхронной
валидацией
async tests —
проверка внешних данных
Асинхронные утилиты позволяют интегрировать:
- запросы к серверу;
- проверку уникальности данных;
- внешние API-валидации.
Особенности:
- поддержка Promise-ориентированной логики;
- корректная агрегация результатов;
- возможность отмены устаревших проверок при повторном запуске.
debounce и
управление частотой проверок
Для предотвращения избыточных вычислений применяются механизмы
контроля частоты выполнения:
- задержка запуска тестов;
- объединение повторных вызовов;
- игнорирование промежуточных состояний.
Это особенно важно при валидации полей ввода в реальном времени.
Инструменты композиции
логики
compose — объединение
правил
Композиция позволяет объединять несколько независимых проверок в
единый блок логики.
Преимущества:
- повторное использование валидационных модулей;
- разделение сложных правил на простые части;
- упрощение тестирования.
Композиция работает как функциональный конвейер, где результат одного
блока может использоваться другим.
map и преобразование
значений
Утилиты преобразования позволяют модифицировать данные перед
проверкой.
Примеры преобразований:
- приведение строк к нормализованному виду;
- удаление пробелов;
- преобразование типов данных;
- предварительная фильтрация значений.
Это снижает сложность тестов, перенося подготовку данных в отдельный
слой.
pipe — последовательная
обработка
Механизм pipe организует цепочку операций, где результат каждого шага
передаётся следующему.
Применение:
- подготовка данных;
- последовательная проверка условий;
- построение сложных вычисляемых правил.
Pipe делает логику предсказуемой и линейной.
Управление ошибками и
результатами
fail — явное проваливание
теста
fail используется для ручного указания ошибки
валидации.
Особенности:
- возможность задавать пользовательское сообщение;
- привязка ошибки к конкретному полю;
- использование в сложной бизнес-логике.
bail — остановка
дальнейших проверок
bail прерывает выполнение текущего набора тестов при
достижении критической ошибки.
Сценарии применения:
- отсутствие обязательных данных;
- некорректный формат входа;
- невозможность продолжения проверки.
Это снижает нагрузку и ускоряет выполнение.
warn — некритические
нарушения
Некоторые проверки не должны блокировать выполнение формы. Для таких
случаев используется механизм предупреждений.
Особенности:
- не влияет на итоговый статус валидации;
- сохраняется в результатах;
- используется для UX-улучшений.
Переиспользование и
модульность
custom helpers —
расширение системы
Vest поддерживает создание пользовательских утилит, которые
инкапсулируют повторяющуюся логику.
Примеры:
- проверка email;
- валидация телефонных номеров;
- правила паролей;
- бизнес-специфические ограничения.
Такие хелперы позволяют строить доменную валидацию, независимую от
конкретных форм.
shared rules — общие
модули
Общие наборы правил используются в нескольких suite.
Преимущества:
- единая точка изменения логики;
- уменьшение дублирования;
- согласованность поведения в разных частях приложения.
conditional
pipelines
Условные цепочки объединяют несколько хелперов в зависимости от
состояния данных.
Пример логики:
- если поле заполнено — активировать расширенную проверку;
- если пользователь авторизован — применить дополнительные
правила;
- если режим черновика — отключить часть проверок.
Контроль структуры и
порядка выполнения
execution order —
детерминированность
Порядок регистрации тестов влияет на:
- приоритет ошибок;
- стратегию раннего выхода;
- читаемость результатов.
Система сохраняет строгую последовательность, что важно для
воспроизводимости поведения.
lazy evaluation —
отложенное выполнение
Все проверки в Vest выполняются только при вызове валидации.
Это даёт:
- оптимизацию производительности;
- возможность динамически изменять suite;
- поддержку условной логики.
result aggregation
— сбор результатов
После выполнения все ошибки агрегируются в единый объект
результата.
Он включает:
- ошибки по полям;
- предупреждения;
- статус выполнения;
- структурированное представление для UI.
Такой подход позволяет отделить логику валидации от отображения
ошибок.