Создаем кастомный виджет формы вместо стандартного конструктора: валидация на JS

Когда я только начинал собирать сайты из готовых шаблонов, стандартные формы казались спасением. Но как только появлялась потребность в кастомной логике — зависимые поля, умные подсказки, нестандартное поведение — конструктор превращался в клетку. Гораздо надёжнее собрать свой виджет на HTML, CSS и JS: он будет выглядеть как часть продукта и вести пользователя по понятному сценарию.

Когда стандартного конструктора уже недостаточно

Готовый конструктор форм отлично справляется, пока перед нами простая задача: имя, телефон, email и кнопка «Отправить». Но в реальном продукте быстро всплывают нюансы, которые ломают эту идиллию:

• одно поле должно менять поведение другого (например, выбор страны переключает формат телефона);
• ошибки нужно показывать не общим блоком внизу, а непосредственно рядом с проблемным полем;
• проверка должна срабатывать не только по клику на кнопку, но и по мере ввода — чтобы пользователь сразу видел, что исправлять;
• часть логики живёт на клиенте, часть — на сервере, и они должны работать согласованно;
• дизайн обязан точно соответствовать дизайн-системе сайта, а не выглядеть чужеродным блоком.

Именно в таких ситуациях кастомный виджет выигрывает. Вы настраиваете поведение под сценарий продукта, а не под ограничения шаблона. На практике часто приходится допиливать даже «гибкие» конструкторы костылями, которые потом больно поддерживать. Свой компонент с самого начала затачивается под задачу и растёт вместе с продуктом.

Что такое кастомный виджет формы

Кастомный виджет — это не просто форма, а самостоятельный интерфейсный компонент. У него есть всё необходимое для автономной работы:

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

По сути, это уже не «форма из шаблона», а полноценный элемент продукта. Такой подход особенно ценен, когда вы идёте по пути «от шаблона к продукту»: берёте типовую заготовку и превращаете её в уникальный сервис. Компонент можно переиспользовать в разных частях проекта, тестировать изолированно и развивать независимо от остальной страницы.

Почему лучше не полагаться только на HTML-атрибуты

Встроенная HTML-валидация — полезный фундамент, но для сложного интерфейса её одной недостаточно. Атрибуты required, type="email", minlength и pattern дают базовую проверку, однако быстро упираются в потолок.

Что умеет HTML сам по себе

HTML-валидация — это база, которую браузер предоставляет «из коробки». Но как только нужно гибко управлять подсказками, зависимостями между полями и пользовательским опытом, без JavaScript не обойтись. Я часто вижу, как разработчики пытаются выжать максимум из нативных атрибутов, но в итоге получают неудобный интерфейс и дублирование логики на сервере. Лучше сразу заложить JS-слой, который возьмёт на себя всю интеллектуальную часть.

Как устроить валидацию на JavaScript

Валидация на JS строится по простой и понятной схеме:

1. Получаем данные из полей формы.
2. Проверяем каждое поле по заранее определённым правилам.
3. Формируем список ошибок (обычно в виде объекта, где ключ — имя поля, значение — текст ошибки).
4. Показываем ошибки пользователю, привязывая их к соответствующим полям.
5. Не отправляем форму, пока есть хотя бы одна ошибка.

Главная идея — не просто «запретить отправку», а объяснить, что именно нужно исправить. Пользователь должен понимать, какое поле подвело и почему.

Логика, которая работает в реальном интерфейсе

Хорошая форма проверяет не только очевидные вещи. В боевых проектах список правил обычно включает:

• пустые значения в обязательных полях;
• формат email (а иногда и проверку на существование домена);
• телефон (с учётом маски и длины);
• длину текста — минимальную и максимальную;
• совпадение паролей или подтверждений;
• обязательные чекбоксы (например, согласие с условиями);
• корректность выбранных опций в селектах и радиокнопках.

Для более сложных сценариев добавляются собственные правила: проверка диапазона чисел, контроль уникальности логина через асинхронный запрос, зависимость одного поля от другого (если выбрана «Доставка», то адрес обязателен). Здесь же пригождается метод setCustomValidity(), который позволяет задать кастомный текст ошибки прямо на элементе формы, сохраняя совместимость с нативными механизмами.

Базовая структура кастомного виджета

Ниже — минимальный каркас, который можно адаптировать под любой проект. Я намеренно использую novalidate, чтобы отключить встроенное поведение браузера и полностью управлять сообщениями и сценарием. Это даёт единообразие дизайна и логики.

<form id="custom-form" novalidate>
  <div class="form-group">
    <label for="name">Имя</label>
    <input type="text" id="name" name="name" required>
    <span class="error-message"></span>
  </div>
  <div class="form-group">
    <label for="email">Email</label>
    <input type="email" id="email" name="email" required>
    <span class="error-message"></span>
  </div>
  <button type="submit">Отправить</button>
</form>

Обратите внимание: контейнеры для ошибок (span.error-message) изначально пусты. В реальном компоненте их можно генерировать динамически через JS, но для простоты примера оставлен статический вариант. Главное — каждое поле должно иметь чёткую связь с местом вывода ошибки.

Пример валидации на JS

Базовый вариант

const form = document.getElementById('custom-form');
const nameInput = document.getElementById('name');
const emailInput = document.getElementById('email');

function showError(input, message) {
  const errorSpan = input.nextElementSibling;
  errorSpan.textContent = message;
  input.classList.add('is-invalid');
}

function clearError(input) {
  const errorSpan = input.nextElementSibling;
  errorSpan.textContent = '';
  input.classList.remove('is-invalid');
}

function validateName() {
  const value = nameInput.value.trim();
  if (!value) {
    showError(nameInput, 'Введите имя');
    return false;
  }
  clearError(nameInput);
  return true;
}

function validateEmail() {
  const value = emailInput.value.trim();
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!value) {
    showError(emailInput, 'Введите email');
    return false;
  }
  if (!emailRegex.test(value)) {
    showError(emailInput, 'Некорректный формат email');
    return false;
  }
  clearError(emailInput);
  return true;
}

function validateForm() {
  const isNameValid = validateName();
  const isEmailValid = validateEmail();
  return isNameValid && isEmailValid;
}

form.addEventListener('submit', (e) => {
  e.preventDefault();
  if (validateForm()) {
    // Отправка данных
    console.log('Форма валидна, отправляем...');
  }
});

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

Как сделать UX удобным, а не раздражающим

Плохая форма «ругается» сразу после загрузки страницы, ещё до того, как пользователь начал ввод. Хорошая — помогает человеку двигаться вперёд, мягко направляя и подсказывая.

Рабочие принципы

• Не показывайте ошибки до первого взаимодействия с полем. Пустое поле при загрузке — не ошибка, а приглашение к заполнению.
• Проверяйте поле при потере фокуса (blur) или после того, как пользователь ввёл первый символ и сделал паузу. Это даёт мгновенную обратную связь без назойливости.
• Не сбрасывайте ошибку до тех пор, пока проблема реально не исчезла. Если человек исправил значение, но оно всё ещё невалидно, ошибка должна оставаться.
• Используйте короткие, конкретные сообщения. Вместо «Некорректное значение» напишите «Введите email в формате [email protected]».
• Подсказывайте, что нужно сделать, а не просто констатируйте сбой. Фраза «Телефон должен содержать 11 цифр» понятнее, чем «Ошибка телефона».

Плохие и хорошие сообщения

Чем понятнее текст, тем меньше отказов от отправки. На своём опыте замечал, что замена сухих технических фраз на человеко-ориентированные подсказки повышала конверсию формы на 10–15% без каких-либо других изменений.

Частые ошибки при создании кастомной формы

1. Проверка только на отправке

Если ошибки видны только после клика по кнопке, пользователь вынужден возвращаться к полям, вспоминать, что он там вводил, и исправлять наугад. Гораздо лучше комбинировать проверку на вводе (или при выходе из поля) и финальную проверку при отправке. Так человек получает обратную связь сразу, а не скопом в конце.

2. Одинаковые сообщения для всех полей

Фраза «Неверный формат» бесполезна, если не указано, что именно ожидалось. Для email это один формат, для телефона — другой. Каждое поле должно иметь собственное, релевантное сообщение об ошибке.

3. Слишком ранняя валидация

Форма не должна ругаться, пока пользователь только начал печатать. Если ошибка появляется после первого же символа, это раздражает и создаёт ощущение, что интерфейс «ломается». Дайте человеку хотя бы пару секунд или дождитесь выхода из поля.

4. Отсутствие серверной проверки

Клиентская валидация — это удобство для пользователя, но не защита. Её легко обойти, отключив JavaScript или подменив запрос. Сервер обязан перепроверять все данные, и это правило не обсуждается. Дублирование правил на клиенте и сервере — не недостаток, а необходимость.

5. Игнорирование доступности

Если ошибка показана только цветом (красная обводка), часть пользователей её не заметит. Нужны текстовые сообщения, связанные с полем через aria-describedby, и понятные состояния элементов. Проверьте, что форму можно пройти с клавиатуры и скринридером.

6. Забывают про асинхронные проверки

Иногда нужно проверить уникальность email или логина через API. В этом случае важно показать индикатор загрузки и не блокировать интерфейс на время запроса. Асинхронная валидация требует аккуратного управления состояниями, иначе пользователь может отправить форму до получения ответа от сервера.

Как совместить JS-валидацию и встроенные возможности браузера

Полностью отказываться от нативных механизмов не обязательно. Часто лучший подход — использовать их как основу, а JavaScript как слой управления поведением и интерфейсом.

Рабочая схема выглядит так:

• HTML задаёт базовые ограничения (required, type, pattern) — это быстрый старт и семантика;
• CSS показывает визуальное состояние поля через псевдоклассы :valid и :invalid;
• JavaScript перехватывает управление: читает нативные состояния, добавляет кастомные правила, управляет текстами ошибок и сценариями;
• сервер подтверждает корректность данных и возвращает окончательный вердикт.

Я часто использую метод form.checkValidity() для быстрой проверки нативных ограничений перед запуском собственной логики. Это даёт устойчивую архитектуру без лишнего усложнения: браузер делает свою часть работы, а мы — свою.

Пошаговый план внедрения

Шаг 1. Определите сценарий формы

Прежде чем писать код, ответьте на вопросы:

• какие поля обязательны;
• какие поля зависят друг от друга (например, «Город» появляется только после выбора «Страны»);
• когда показывать ошибки — при потере фокуса, по мере ввода или только при отправке;
• что делать после успешной отправки — показать сообщение, перенаправить, очистить форму;
• нужен ли AJAX или обычная отправка с перезагрузкой страницы.

Чёткое понимание сценария сэкономит часы на переделках.

Шаг 2. Опишите правила проверки

Сначала перечислите правила на бумаге или в комментариях к коду. Это помогает не расползтись по логике и увидеть полную картину. Например:

// name: required, мин. 2 символа
// email: required, формат email
// password: required, мин. 8 символов, хотя бы одна цифра
// confirm: required, совпадает с password

Такой список станет отличной спецификацией для разработки и тестирования.

Шаг 3. Соберите HTML-скелет

Форма должна быть понятной и работоспособной даже без JavaScript. Это упростит поддержку и обеспечит базовую доступность. Не забудьте про атрибуты for у label, aria-describedby для связки с сообщениями об ошибках и семантически правильную структуру.

Шаг 4. Добавьте стили состояний

Минимум нужны классы для основных состояний:

• .is-valid — поле заполнено корректно;
• .is-invalid — есть ошибка;
• .is-loading — идёт отправка или асинхронная проверка;
• .is-success — форма успешно отправлена.

Эти классы добавляются и убираются через JavaScript, а CSS отвечает за визуальное оформление. Так разделение ответственности остаётся чистым.

Шаг 5. Напишите функции валидации

Лучше делать отдельную функцию на каждое поле или тип поля. Так код легче расширять и тестировать. Можно организовать правила в виде объекта:

const validators = {
  name: (value) => value.trim().length >= 2 ? '' : 'Имя должно содержать минимум 2 символа',
  email: (value) => /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value) ? '' : 'Некорректный email',
};

Затем общая функция проходит по всем полям и собирает ошибки.

Шаг 6. Проверьте поведение на ошибках

Протестируйте все крайние случаи:

• пустая форма при отправке;
• неправильный email;
• очень длинный текст (вдруг вёрстка ломается);
• повторная отправка (защита от двойного клика);
• очистка формы после успеха — поля должны сбрасываться, ошибки исчезать.

Автоматические тесты для функций валидации здесь очень выручают, но хотя бы ручная проверка по чек-листу обязательна.

Когда стоит делать виджет полностью с нуля

Кастомный виджет оправдан, если:

• форма — часть ключевого сценария продукта (регистрация, оформление заказа);
• важна точная стилизация, совпадающая с дизайн-системой до пикселя;
• нужны нестандартные правила, которые не вписываются в логику конструктора;
• форма должна быть быстрой и лёгкой, без лишних зависимостей;
• конструктор ограничивает развитие — вы постоянно упираетесь в его потолок.

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

Чек-лист перед публикацией

• Все поля имеют понятные подписи.
• Ошибки отображаются рядом с нужным полем, а не общим списком.
• Сообщения написаны простым языком, без технического жаргона.
• Есть проверка на клиенте и на сервере (дублирование правил — осознанное).
• Кнопка отправки блокируется на время запроса, чтобы избежать двойной отправки.
• Форма не ломается без JavaScript: данные можно отправить, пусть и без красивого UX.
• Состояния успеха и ошибки визуально различимы (цвет, иконка, текст).
• Интерфейс удобен на мобильных устройствах: поля не слипаются, клавиатура не перекрывает кнопку.
• Доступность: все элементы доступны с клавиатуры, ошибки связаны с полями через aria-describedby.

Мини-таблица: что проверять на каком уровне

Вывод

Кастомный виджет формы с валидацией на JavaScript даёт полный контроль над интерфейсом, логикой и пользовательским сценарием. Это особенно важно там, где стандартный конструктор уже мешает развивать продукт, а не помогает ему.

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

FAQ

Можно ли обойтись без JavaScript?

Да, если форма очень простая и вам достаточно базовой браузерной проверки. Но как только появляется необходимость в кастомных сообщениях, зависимых полях или асинхронной валидации, JavaScript становится необходимым. В реальных продуктах чистый HTML используют редко — он не даёт нужной гибкости.

Нужно ли отключать встроенную валидацию браузера?

Не обязательно. Если вас устраивают стандартные всплывающие подсказки и вы не планируете сильно менять UX, можно оставить нативную валидацию. Но для единых текстов ошибок, кастомного дизайна и сложных сценариев я обычно добавляю форме атрибут novalidate и беру контроль в свои руки. Это позволяет создать целостный интерфейс без сюрпризов от разных браузеров.

Достаточно ли проверки на клиенте?

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

Что важнее: красивый дизайн или логика?

В форме важнее логика, потому что пользователь приходит решать задачу, а не любоваться дизайном. Дизайн должен поддерживать сценарий, а не мешать ему. Красивая, но непонятная форма проигрывает неказистой, но интуитивной. Идеально, когда оба аспекта на высоте, но приоритет — за работоспособностью.

Как понять, что форма сделана хорошо?

Если пользователь быстро понимает, что делать, где ошибка и как её исправить, форма работает правильно. Хороший тест: дайте форму человеку, не знакомому с проектом, и посмотрите, возникнут ли у него вопросы. Отсутствие вопросов — лучший показатель.