Соглашения по оформлению

Библиотека Validator.js построена вокруг набора чистых функций, каждая из которых выполняет строго одну задачу проверки строки. Основной принцип оформления кода при работе с ней — предсказуемость поведения и отсутствие скрытых побочных эффектов.

Каждая функция в библиотеке представляет собой изолированный валидатор вида:

validator.isEmail(str)
validator.isURL(str)
validator.isNumeric(str)

Формат вызова всегда одинаков: первый аргумент — проверяемая строка, дополнительные параметры передаются через объект настроек.

Типизация входных данных и приведение к строке

Одно из ключевых соглашений Validator.js — работа исключительно со строковыми значениями. Независимо от исходного типа данных, значение приводится к строке перед проверкой.

Это означает, что поведение валидаторов предсказуемо:

validator.isEmail("test@mail.com") // true
validator.isEmail(123) // "123" -> false

В прикладном коде это приводит к необходимости явного контроля входных данных до передачи в библиотеку. Особенно важно учитывать следующие моменты:

  • null и undefined преобразуются в строки "null" и "undefined"
  • числа приводятся к строковому представлению
  • объекты приводятся к "[object Object]"

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

Возвращаемые значения и бинарная логика

Все функции проверки возвращают строго boolean:

  • true — значение соответствует критерию
  • false — значение не соответствует критерию

Отсутствие исключений при невалидных данных является важной особенностью библиотеки. Ошибки не выбрасываются даже при некорректных типах входных значений.

Такой подход формирует соглашение:

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

Пример:

if (validator.isLength(password, { min: 8 })) {
  // обработка валидного значения
} else {
  // обработка ошибки
}

Использование объектов настроек

Многие функции Validator.js поддерживают параметр конфигурации в виде объекта. Это основной способ расширения поведения без изменения самой функции.

Пример:

validator.isLength(str, { min: 5, max: 20 })

Соглашения по оформлению объектов настроек:

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

Важно учитывать, что конфигурационные объекты не мутируют входные данные и не сохраняются между вызовами.

Разделение валидации и санитизации

Validator.js разделяет два типа операций:

Валидация

  • проверка соответствия формату
  • возврат boolean
  • отсутствие изменения входных данных

Санитизация

  • преобразование строки к безопасному виду
  • возврат новой строки
  • удаление или нормализация символов

Примеры санитизации:

validator.normalizeEmail(email)
validator.trim(str)

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

Иммутабельность и отсутствие побочных эффектов

Validator.js следует функциональному стилю программирования:

  • входные данные не изменяются
  • функции не сохраняют состояние
  • результат зависит только от аргументов

Это позволяет безопасно использовать функции в любых контекстах:

  • серверные приложения
  • клиентские формы
  • потоковые обработки данных

Пример корректного использования:

const clean = validator.trim(userInput);
const valid = validator.isAlphanumeric(clean);

Композиция валидаторов

Вместо сложных встроенных цепочек логика часто строится через композицию функций.

Пример:

const isValidUsername = (value) =>
  validator.isLength(value, { min: 3, max: 15 }) &&
  validator.isAlphanumeric(value);

Такой подход обеспечивает:

  • повторное использование логики
  • прозрачность проверки
  • простоту тестирования

Работа с Unicode и локалями

Некоторые валидаторы учитывают особенности Unicode:

  • символы разных алфавитов
  • пробелы различных типов
  • международные форматы email и URL

Соглашение: при необходимости строгой латинской проверки используются дополнительные опции или комбинирование с регулярными выражениями.

Обработка ошибок на уровне приложения

Validator.js не занимается генерацией сообщений об ошибках. Это архитектурное соглашение:

  • библиотека возвращает только true/false
  • текстовые сообщения формируются отдельно

Пример слоя обработки:

if (!validator.isEmail(email)) {
  errors.push("Некорректный email");
}

Такой подход позволяет:

  • локализовать сообщения
  • централизовать управление ошибками
  • адаптировать UX без изменения логики проверки

Интеграция с серверными фреймворками

В серверных приложениях Validator.js часто используется в middleware-слое.

Пример типичной схемы:

  1. получение данных из запроса
  2. нормализация входных значений
  3. применение валидаторов
  4. формирование ответа

Соглашение: валидация должна выполняться до бизнес-логики, чтобы исключить распространение некорректных данных.

Тестирование валидаторов

При построении тестов для функций, использующих Validator.js, применяется набор типовых сценариев:

  • корректные значения
  • граничные значения
  • пустые строки
  • неожиданные типы данных

Пример:

expect(validator.isEmail("test@mail.com")).toBe(true);
expect(validator.isEmail("invalid")).toBe(false);
expect(validator.isEmail(null)).toBe(false);

Соглашение: тесты должны проверять не только позитивные, но и негативные сценарии.

Производительность и частота вызовов

Validator.js оптимизирован для частого использования в потоках данных, однако при массовой обработке следует учитывать:

  • повторные проверки одного и того же значения неэффективны
  • сложные валидаторы (URL, email) имеют более высокую стоимость
  • избыточная валидация ухудшает производительность

Рекомендуется кэширование результатов при повторных вычислениях в рамках одной операции.

Соглашения именования в кодовой базе

При использовании Validator.js в проектах часто вводятся единые правила:

  • функции-обертки называются в стиле isValidX
  • санитизация обозначается как sanitizeX
  • валидаторы группируются по типам данных

Пример структуры:

isValidEmail()
isValidPassword()
sanitizeEmail()

Это упрощает поддержку и повышает читаемость кода.

Безопасность и ограничения доверия к данным

Validator.js используется как первый слой защиты от некорректного ввода, но не заменяет полноценную валидацию на сервере.

Ключевые принципы:

  • клиентская проверка не считается доверенной
  • серверная валидация обязательна
  • валидаторы не защищают от всех видов атак (например, бизнес-логических)

Особое внимание уделяется:

  • SQL-инъекциям (не решаются Validator.js)
  • XSS (требует отдельной санитизации)
  • переполнению логики приложения

Структурирование набора валидаторов

В крупных проектах часто формируется централизованный слой правил:

const validators = {
  email: (v) => validator.isEmail(v),
  password: (v) => validator.isLength(v, { min: 8 }),
};

Такой подход обеспечивает:

  • единообразие правил
  • централизованное обновление логики
  • уменьшение дублирования кода
Оглавление