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

Заполнить валидным значением поле имя это как

  • автор:

Валидация форм на стороне клиента

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

Начальные требования: Владение компьютером, достаточное понимание HTML, CSS, и JavaScript.
Цель: Понять, что такое валидация на стороне клиента, почему это важно и как применять различные техники для её реализации.

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

Однако, не следует рассматривать валидацию на стороне клиента как достаточную меру безопасности! Любые данные, отправляемые через форму, необходимо дополнительно проверять на безопасность и на стороне сервера, поскольку валидацию на стороне клиента достаточно просто обойти и она может не остановить злоумышленников. Чтобы лучше понимать потенциальные угрозы, рекомендуем ознакомиться с разделом Безопасность вебсайтов; валидация на стороне сервера выходит за рамки этого модуля, но о ней следует помнить.

Что такое валидация формы?

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

  • «Обязательное поле» (Вы не можете оставить поле пустым).
  • «Пожалуйста, введите номер телефона в формате xxx-xxxx» (Чтобы данные считались корректными, их необходимо указать в определённом формате).
  • «Пожалуйста, введите корректный email-адрес» (вы ввели данные в неправильном формате).
  • «Длина пароля должна быть от 8 до 30 символов и включать одну заглавную букву, один символ, и одну цифру.» (Требования к формату данных достаточно конкретные).

Это называется валидацией формы. По мере ввода, браузер и/или сервер проверяют данные, чтобы определить, соответствуют ли они требуемому формату. Валидация, выполняемая в браузере, называется валидацией на стороне клиента, а выполняемая на сервере — валидацией на стороне сервера. В этом разделе мы сосредоточимся на валидации, выполняемой на стороне клиента.

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

Мы хотим максимально упростить заполнение веб-форм. Тогда почему мы настаиваем валидации данных? На это есть три основные причины:

  • Мы хотим получать правильные данные в правильном формате. Наши приложения не будут работать должным образом, если данные от пользователей хранятся в неправильном формате, некорректны сами по себе или вовсе пропущены.
  • Мы хотим защитить данные пользователей. Принуждение пользователей вводить надёжные пароли облегчает защиту их аккаунтов.
  • Мы хотим защитить себя. Существует множество способов, позволяющих злоумышленникам с помощью незащищённых форм навредить приложению (смотрите Безопасность вебсайтов).

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

Типы валидации на стороне клиента

Существует два типа валидации на стороне клиента, с которыми вы столкнётесь в Интернете:

  • Встроенная валидация форм использует функционал валидации HTML5, который мы неоднократно обсуждали в этом модуле. HTML5-валидация обычно не требует большого количества JavaScript-кода и демонстрирует лучшую производительность, но не настолько настраиваема, как валидация с помощью JavaScript.
  • JavaScript-валидация кодируется с помощью JavaScript. Она полностью настраиваема, но требует программирования всей логики (или использования библиотеки).

Использование встроенной валидации форм

Одной из самых важных функций элементов форм HTML5 (en-US) является способность валидировать бóльшую часть пользовательских данных без использования JavaScript. Это выполняется с помощью атрибутов валидации у элементов формы. Многие из них мы уже рассмотрели в этом курсе:

  • required (en-US): Определяет, что для отправки формы данное поле предварительно должно быть заполнено.
  • minlength (en-US) и maxlength (en-US): Задаёт минимальную и максимальную длину текстовых данных (строк)
  • min (en-US) и max (en-US): Задаёт минимальное и максимальное значение для поля, расчитанного на числовой тип данных
  • type : Определяет тип данных, на который рассчитано поле: число, email-адрес или какой-то другой предустановленный тип
  • pattern : С помощью регулярного выражения, определяет шаблон, которому должны соответствовать вводимые данные.

Если данные, введённые в поле формы, соответствуют правилам перечисленных выше атрибутов, они считаются валидными, если нет — не валидными

Когда элемент валиден, справедливы следующие утверждения:

  • Элемент соответствует CSS-псевдоклассу :valid , позволяющему стилизовать только валидные элементы.
  • Если пользователь пытается отправить данные, браузер отправит форму при условии, что ничто другое (например, JavaScript) не помешает ему это сделать

Когда элемент не валиден, справедливы следующие утверждения:

  • Элемент соответствует CSS-псевдоклассу :invalid или, в зависимости от ошибки, другим псевдоклассам (например, :out-of-range ), которые позволяют применять определённые стили к элементам, не являющимся валидными.
  • Если пользователь пытается отправить данные, браузер заблокирует форму и выведет сообщение об ошибке.

Примеры встроенной валидации форм

В этом разделе мы протестируем некоторые из атрибутов, которые обсуждали выше.

Простой начальный файл

Давайте начнём с простого примера: поле, позволяющее указать своё предпочтение — банан или вишня. Этот пример включает обычное текстовое поле , связанный с ним элемент и кнопку отправки формы . Исходный код можно найти на GitHub по адресу fruit-start.html, а ниже приведён рабочий пример.

form> label for="choose">Would you prefer a banana or cherry?label> input id="choose" name="i_like" /> button>Submitbutton> form> 
input:invalid  border: 2px dashed red; > input:valid  border: 2px solid black; > 

Для начала скопируйте файл fruit-start.html в новую папку на вашем жёстком диске.

Атрибут required

Самым простым в HTML5-валидации является атрибут required (en-US) . Добавьте его к элементу, чтобы сделать заполнение обязательным. Элемент с данным атрибутом соответствует CSS-псевдоклассу :required , а если поле ввода пустое, вместо отправки формы отобразится сообщение об ошибке. Пока поле пустое, оно также будет соответствовать CSS-псевдоклассу :invalid .

Добавьте к полю атрибут required , как показано ниже.

form> label for="choose">Would you prefer a banana or cherry? (required)label> input id="choose" name="i_like" required /> button>Submitbutton> form> 

Обратите внимание на CSS, который включён в файл примера:

input:invalid  border: 2px dashed red; > input:invalid:required  background-image: linear-gradient(to right, pink, lightgreen); > input:valid  border: 2px solid black; > 

Данный CSS задаёт полю красную пунктирную рамку, когда оно не валидно, а когда валидно — сплошную чёрную. Мы также добавили фоновый градиент для обязательных не валидных полей. Проверьте новое поведение в примере ниже:

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-validation.html (отдельно можно найти исходный код.)

Попробуйте отправить форму без введения значения. Обратите внимание, что не валидное поле получает фокус, появляется сообщение об ошибке («Заполните это поле») и блокируется отправка формы.

Наличие атрибута required у любого элемента, который его поддерживает, означает, что элемент соответствует CSS-псевдоклассу :required , независимо от того, имеет он значение или нет. Если элемент не содержит значение, он будет соответствовать псевдоклассу :invalid .

Примечание: Для повышения удобства взаимодействия указывайте пользователям, какие поля являются обязательными. К тому же, этого требует руководство по обеспечению доступности WCAG. Требуйте обязательного ввода только тех данных, которые вам действительно нужны: например, так ли важно знать пол или должность пользователя?

Валидация с помощью регулярного выражения

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

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

  • a — Соответствует одному символу a (не b , не aa , и так далее).
  • abc — Соответствует символу a , за которой следует b , за которой следует c .
  • ab?c — Соответствует символу a , за которым опционально может следовать b , за которым следует c . ( ac или abc )
  • ab*c — Соответствует символу a , за которым опционально может следовать любое количество символов b , за которыми следует c . ( ac , abc , abbbbbc , и так далее).
  • a|b — Соответствует символу a или b .
  • abc|xyz — Соответствует в точности abc или в точности xyz (но не abcxyz или a или y , и так далее).

Есть еще много возможностей, которые мы не упомянули. Полный список со множеством примеров можно найти в документации по Регулярным выражениям

Давайте рассмотрим пример. Добавьте в атрибут pattern следующий шаблон:

form> label for="choose">Would you prefer a banana or a cherry?label> input id="choose" name="i_like" required pattern="[Bb]anana|[Cc]herry" /> button>Submitbutton> form> 
input:invalid  border: 2px dashed red; > input:valid  border: 2px solid black; > 

Это даёт нам следующее обновление — опробуйте его:

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-pattern.html (исходный код.)

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

Примечание: Некоторым типам элементов для валидации с помощью регулярного выражения не требуется атрибут pattern . Например, поле с типом email валидирует значение по шаблону одного email-адреса или, если присутствует атрибут multiple (en-US) , шаблону списка email-адресов, разделённых запятыми.

Примечание: Элемент (en-US) не поддерживает атрибут pattern .

Ограничение длины вводимых значений

Можно ограничить максимально допустимое количество символов для текстовых полей или (en-US) используя атрибуты minlength (en-US) и maxlength (en-US) . Поле будет не валидным, если количество символов его содержимого будет меньше minlength (en-US) или больше maxlength (en-US) .

Зачастую браузеры не позволяют пользователям вводить в текстовое поле значение, длина которого превышает максимально допустимую. Можно существенно повысить удобство использования, если помимо ограничения в атрибуте maxlength добавить доступный индикатор, отображающий текущее и максимально допустимое количество символов, что даст пользователю возможность уместить содержимое в заданные рамки. Хорошим примером является окно написания твита в Twitter. Для реализации такого функционала можно использовать JavaScript, включая решения, использующие maxlength .

Ограничение допустимых значений

В полях, предназначенных для ввода чисел (например, ), диапазон допустимых значений можно определить с помощью атрибутов min (en-US) и max (en-US) . Если поле содержит значение за пределами данного диапазона, оно будет не валидным.

Давайте рассмотрим другой пример. Создайте новую копию файла fruit-start.html.

Содержимое элемента замените на:

form> div> label for="choose">Would you prefer a banana or a cherry?label> input type="text" id="choose" name="i_like" required minlength="6" maxlength="6" /> div> div> label for="number">How many would you like?label> input type="number" id="number" name="amount" value="1" min="1" max="10" /> div> div> button>Submitbutton> div> form> 
  • Здесь мы в поле с типом text атрибутам minlength и maxlength , задали одинаковое значение 6, что соответствует количеству символов в словах banana и cherry.
  • В поле с типом number атрибуту min мы задали значение 1, а атрибуту max значение 10. При вводе чисел за пределами данного диапазона, поле будет становиться не валидным; с помощью стрелок увеличения/уменьшения пользователи не смогут выйти за границы диапазона. Текущее поле не является обязательным для заполнения, поэтому даже после очистки будет оставаться валидным.
input:invalid  border: 2px dashed red; > input:valid  border: 2px solid black; > div  margin-bottom: 10px; > 

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-length.html (исходный код.)

Примечание: (и другие типы, такие как range и date ) могут также принимать атрибут step (en-US) , который задаёт шаг увеличения или уменьшения значения при использовании кнопок вверх и вниз. В примере выше мы явно не указывали атрибут step , поэтому он получает значение по умолчанию, равное 1 . Это значит, что дробные числа, такие как 3.2, будут не валидными.

Полный пример

Ниже представлен полный пример, демонстрирующий использование встроенного функционала валидации. Сначала немного HTML:

form> p> fieldset> legend>Do you have a driver's license?abbr title="This field is mandatory" aria-label="required">*abbr>legend> input type="radio" required name="driver" id="r1" value="yes">label for="r1">Yeslabel> input type="radio" required name="driver" id="r2" value="no">label for="r2">Nolabel> fieldset> p> p> label for="n1">How old are you?label> input type="number" min="12" max="120" step="1" id="n1" name="age" pattern="\d+"> p> p> label for="t1">What's your favorite fruit?abbr title="This field is mandatory" aria-label="required">*abbr>label> input type="text" id="t1" name="fruit" list="l1" required pattern="[Bb]anana|[Cc]herry|[Aa]pple|[Ss]trawberry|[Ll]emon|[Oo]range"> datalist id="l1"> option>Bananaoption> option>Cherryoption> option>Appleoption> option>Strawberryoption> option>Lemonoption> option>Orangeoption> datalist> p> p> label for="t2">What's your e-mail address?label> input type="email" id="t2" name="email"> p> p> label for="t3">Leave a short messagelabel> textarea id="t3" name="msg" maxlength="140" rows="5">textarea> p> p> button>Submitbutton> p> form> 

И немного CSS для стилизации HTML:

form  font: 1em sans-serif; max-width: 320px; > p > label  display: block; > input[type="text"], input[type="email"], input[type="number"], textarea, fieldset  width: 100%; border: 1px solid #333; box-sizing: border-box; > input:invalid  box-shadow: 0 0 5px 1px red; > input:focus:invalid  box-shadow: none; > 

В статье Атрибуты валидации (en-US) можно найти полный список атрибутов, которые можно использовать для ограничения допустимых значений ввода и типов полей input , которые их поддерживают.

Примечание: Рабочий пример можно найти на GitHub по адресу full-example.html (исходный код.)

Валидация форм с помощью JavaScript

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

Constraint Validation API

Большинство браузеров поддерживают Constraint Validation API, который состоит из набора свойств и методов, доступных на DOM-интерфейсах следующих элементов форм:

  • HTMLButtonElement (представляет элемент )
  • HTMLFieldSetElement (en-US) (представляет элемент )
  • HTMLInputElement (en-US) (представляет элемент )
  • HTMLOutputElement (en-US) (представляет элемент )
  • HTMLSelectElement (en-US) (представляет элемент )
  • HTMLTextAreaElement (en-US) (представляет элемент (en-US))

Для перечисленных выше элементов Constraint Validation API делает доступными следующие свойства.

  • validationMessage : Возвращает локализованное сообщение, описывающее ограничения валидации (если таковые имеются), которым не удовлетворяет определённый элемент. Если элемент не участвует в валидации ( willValidate установлено в false ) или значение элемента удовлетворяет установленным ограничениям (является валидным), будет возвращена пустая строка.
  • validity : Возвращает объект ValidityState , который содержит несколько свойств, описывающих состояние валидности элемента. Подробное описание всех свойств доступности можно найти на странице справочника ValidityState ; ниже приведён список наиболее используемых:
    • patternMismatch : Возвращает true , если значение не соответствует шаблону, указанному в атрибуте pattern , и false если соответствует. Если true, элемент соответствует CSS-псевдоклассу :invalid .
    • tooLong : Возвращает true , если значение длиннее максимальной длины, указанной в атрибуте maxlength , и false если оно короче или равно ей. Если true, элемент соответствует CSS-псевдоклассу :invalid .
    • tooShort : Возвращает true , если значение короче минимальной длины, указанной в атрибуте minlength , и false если оно длинее или равно ей. Если true, элемент соответствует CSS-псевдоклассу :invalid .
    • rangeOverflow : Возвращает true , если значение больше указанного в атрибуте max максимума, и false если меньше или равно ему. Если true, элемент соответствует CSS-псевдоклассам :invalid и :out-of-range
    • rangeUnderflow : Возвращает true , если значение меньше указанного в атрибуте min , и false если больше или равно ему. Если true, элемент соответствует CSS-псевдоклассу :invalid и :out-of-range .
    • typeMismatch : Возвращает true , если значение не соответствует требуемому синтаксису (когда для type задано значение email или url ), и false если синтаксис корректный. Если true , элемент соответствует CSS-псевдоклассу :invalid .
    • valid : Возвращает true , если элемент соответствует всем ограничениям валидации — следовательно, считается валидным, и false если не соответствует какому-то ограничению. Если true, элемент соответствует CSS-псевдоклассу :valid ; иначе :invalid .
    • valueMissing : Возвращает true , если у элемента есть атрибут required , но не введено значенение, иначе возвращает false . Если true, элемент соответствует CSS-псевдоклассу :invalid .

    Также для перечисленных выше элементов Constraint Validation API делает доступными следующие методы.

    • checkValidity() : Возвращает true , если значение элемента проходит валидацию, иначе возвращает false . Если элемент не валиден, данный метод также запускает на нём событие invalid .
    • setCustomValidity(message) : Позволяет добавить в элемент кастомное сообщение об ошибке; при этом элемент будет считаться не валидным и отобразится указанная ошибка. Это позволяет использовать JavaScript-код, чтобы представить ошибку валидации иначе, чем это предусмотрено стандартными средствами валидации HTML5. При сообщении об ошибке данное кастомное сообщение показывается пользователю.
    Реализация кастомного сообщения об ошибке

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

    У этих автоматических сообщений есть два недостатка:

    • Не существует стандартного способа их стилизации с помощью CSS.
    • Они зависят от локали браузера, из-за чего страница может быть на одном языке, а сообщение об ошибке — на другом, как показано на следующем скриншоте браузера Firefox.

    Пример сообщения об ошибке на англоязычной странице в браузере Firefox с настроенным французским языком

    Настройка таких сообщений об ошибках является одной из наиболее распространённых причин использования Constraint Validation API. Давайте рассмотрим простой пример, как это делается.

    Начнём с простого HTML (Не стесняйтесь поместить это в пустой HTML-файл. Вы можете взять за основу свежую копию fruit-start.html, если хотите):

    form> label for="mail" >I would like you to provide me with an e-mail address:label > input type="email" id="mail" name="mail" /> button>Submitbutton> form> 

    Добавьте на страницу следующий JavaScript:

    const email = document.getElementById("mail"); email.addEventListener("input", function (event)  if (email.validity.typeMismatch)  email.setCustomValidity("I am expecting an e-mail address!"); > else  email.setCustomValidity(""); > >); 

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

    В коде обработчика мы проверяем, возвращает ли свойство поля email validity.typeMismatch значение true , что значит, что содержащееся значение не соответствует шаблону корректного email-адреса. Если возвращается true , мы вызываем метод setCustomValidity() (en-US) с кастомным сообщением. Это делает поле не валидным, поэтому попытка отправить форму приводит к ошибке и отображается кастомное сообщение об ошибке.

    Если свойство validity.typeMismatch возвращает false , мы вызываем метод setCustomValidity() с пустой строкой. Это делает поле валидным, поэтому форма может быть успешно отправлена.

    Попробовать пример можно ниже:

    Примечание:: Данный пример можно найти на GitHub по адресу custom-error-message.html (отдельно можно найти исходный код.)

    Более подробный пример

    Теперь, когда мы разобрали простой пример, давайте посмотрим, как можно использовать данный API для создания более сложной валидацию.

    Во-первых, HTML. Опять же, не стесняйтесь писать его вместе с нами:

    form novalidate> p> label for="mail"> span>Please enter an email address:span> input type="email" id="mail" name="mail" required minlength="8" /> span class="error" aria-live="polite">span> label> p> button>Submitbutton> form> 

    Эта простая форма использует атрибут novalidate , который отключает автоматическую валидацию браузером; это позволяет нашему скрипту взять управление валидацией на себя. Однако, это не отменяет поддержку Constraint Validation API или псевдоклассов, таких как :valid или ему подобных. Это значит, что хотя браузер автоматически и не проверяет валидность формы перед отправкой данных, вы можете сделать это самостоятельно и соответствующим образом стилизовать форму.

    Объектом валидации является обязательный для заполнения (en-US) , длина которого не должна быть меньше 8 символов. Давайте напишем код, проверяющий эти критерии, и покажем кастомное сообщение об ошибке в случае несоблюдения какого-то из них.

    Мы хотим показывать сообщение об ошибке внутри элемента . Данному элементу задан атрибут aria-live (en-US) , чтобы гарантировать, что наше кастомное сообщение об ошибке будет доступно всем, включая пользователей скринридеров.

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

    Перейдём к базовому CSS, чтобы немного улучшить внешний вид формы и обеспечить визуальную обратную связь при введении не валидных данных:

    body  font: 1em sans-serif; width: 200px; padding: 0; margin: 0 auto; > p *  display: block; > input[type="email"]  -webkit-appearance: none; appearance: none; width: 100%; border: 1px solid #333; margin: 0; font-family: inherit; font-size: 90%; box-sizing: border-box; > /* Это стили для не валидных полей */ input:invalid  border-color: #900; background-color: #fdd; > input:focus:invalid  outline: none; > /* Это стили для кастомных сообщений об ошибке */ .error  width: 100%; padding: 0; font-size: 80%; color: white; background-color: #900; border-radius: 0 0 5px 5px; box-sizing: border-box; > .error.active  padding: 0.3em; > 

    Теперь давайте рассмотрим JavaScript, который реализует кастомную валидацию.

    // Существуют разные способы получить DOM-узел; здесь мы определяем саму форму и // поле ввода email и элемент span, в который поместим сообщение об ошибке const form = document.getElementsByTagName("form")[0]; const email = document.getElementById("mail"); const emailError = document.querySelector("#mail + span.error"); email.addEventListener("input", function (event)  // Каждый раз, когда пользователь что-то вводит, // мы проверяем, являются ли поля формы валидными if (email.validity.valid)  // Если на момент валидации какое-то сообщение об ошибке уже отображается, // если поле валидно, удаляем сообщение emailError.textContent = ""; // Сбросить содержимое сообщения emailError.className = "error"; // Сбросить визуальное состояние сообщения > else  // Если поле не валидно, показываем правильную ошибку showError(); > >); form.addEventListener("submit", function (event)  // Если поле email валдно, позволяем форме отправляться if (!email.validity.valid)  // Если поле email не валидно, отображаем соответствующее сообщение об ошибке showError(); // Затем предотвращаем стандартное событие отправки формы event.preventDefault(); > >); function showError()  if (email.validity.valueMissing)  // Если поле пустое, // отображаем следующее сообщение об ошибке emailError.textContent = "You need to enter an e-mail address."; > else if (email.validity.typeMismatch)  // Если поле содержит не email-адрес, // отображаем следующее сообщение об ошибке emailError.textContent = "Entered value needs to be an e-mail address."; > else if (email.validity.tooShort)  // Если содержимое слишком короткое, // отображаем следующее сообщение об ошибке emailError.textContent = `Email should be at least $email.minLength> characters; you entered $email.value.length>.`; > // Задаём соответствующую стилизацию emailError.className = "error active"; > 

    Комментарии объясняют логику хорошо, но кратко:

    • При каждом изменении значения поля, мы производим его валидацию. Если данные валидны, удаляем ранее отображаемые сообщения об ошибках. Если данные не валдны, запускаем showError() , чтобы показать соответствующую ошибку.
    • При каждой попытке отправить форму, мы снова производим валидацию. Если данные валидны, позволяем отправку формы. Если данные не валидны, запускам showError() , чтобы показать соответствующее сообщение об ошибке, а также предотвращаем отправку формы с помощью preventDefault() .
    • Функция showError() использует различные свойства объекта validity поля ввода, чтобы определить тип ошибки и отобразить соответсвущее сообщение.

    Примечание: Рабочий пример можно найти на GitHub по адресу detailed-custom-validation.html (отдельно можно найти исходный код.)

    Constraint Validation API явяется мощным инструментом валидации форм, позволяющим получить контроль над пользовательским интерфейсом, существенно превосходящий возможности HTML и CSS.

    Примечание: Для получения дополнительной информации смотрите руководства Constraint validation guide (en-US) и Constraint Validation API.

    Проверка форм без встроенного API

    В некоторых случаях, например, при необходимости поддержки устаревших браузеров или кастомных элементов формы, вы не сможете или не захотите использовать Constraint Validation API. Вы по-прежнему сможете использовать JavaScript для валидации форм, но для этого всё нужно будет писать самостоятельно.

    Для создания своего валидатора формы, задайте себе несколько вопросов:

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

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

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

    • SmashingMagazine: Form-Field Validation: The Errors-Only Approach
    • SmashingMagazine: Web Form Validation: Best Practices and Tutorials
    • WebFX: 10 Tips for Optimizing Web Form Submission Usability
    • A List Apart: Inline Validation in Web Forms
    Пример без использования Constraint Validation API

    Чтобы проиллюстрировать это дальше приводится упрощённая версия предыдущего примера, которая работает с устаревшими браузерами.

    HTML почти тот такой же; мы только удалили функционал валидации HTML5.

    form> p> label for="mail"> span>Please enter an email address:span> input type="text" id="mail" name="mail" /> span class="error" aria-live="polite">span> label> p> button type="submit">Submitbutton> form> 

    CSS также не требует особых изменений; мы только заменили CSS-псевдокласс :invalid на реальный класс и не использовали селектор по атрибутам, так как он не работает в Internet Explorer 6.

    body  font: 1em sans-serif; width: 200px; padding: 0; margin: 0 auto; > form  max-width: 200px; > p *  display: block; > input.mail  -webkit-appearance: none; width: 100%; border: 1px solid #333; margin: 0; font-family: inherit; font-size: 90%; box-sizing: border-box; > /* Стилизация не валидных полей */ input.invalid  border-color: #900; background-color: #fdd; > input:focus.invalid  outline: none; > /* Стилизация сообщений об ошибках */ .error  width: 100%; padding: 0; font-size: 80%; color: white; background-color: #900; border-radius: 0 0 5px 5px; box-sizing: border-box; > .error.active  padding: 0.3em; > 

    Существенно изменился только JavaScript-код, который теперь должен выполнять гораздо больше работы.

    // Устаревшие браузеры поддерживают несколько способов получения DOM-узла const form = document.getElementsByTagName("form")[0]; const email = document.getElementById("mail"); // Ниже приведён способ получения узла следующего родственного DOM-элемента // Он опасен, потому что можно создать бесконечный цикл. // В современных браузерах лучше использовать `element.nextElementSibling` let error = email; while ((error = error.nextSibling).nodeType != 1); // Согласно спецификации HTML5 const emailRegExp = /^[a-zA-Z0-9.!#$%&'*+/=?^_`<|>~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/; // Многие устаревшие браузеры не поддерживают метод `addEventListener` // Есть простой способ заменить его; и далеко не единственный function addEvent(element, event, callback)  let previousEventCallBack = element["on" + event]; element["on" + event] = function (e)  let output = callback(e); // Колбэк, который возвращает `false`, останавливает цепочку колбэков // и прерывает выполнение колбэка события if (output === false) return false; if (typeof previousEventCallBack === "function")  output = previousEventCallBack(e); if (output === false) return false; > >; > // Теперь мы можем изменить наши критерии валидации // Поскольку мы не полагаемся на CSS-псевдокласс, для поля email // нужно явно задать валидный / не валидный класс addEvent(window, "load", function ()  // Проверка, является ли поле пустым (помните, оно не являтеся обязательным) // Если поле не пустое, проверяем содержимое на соответствует шаблону email const test = email.value.length === 0 || emailRegExp.test(email.value); email.className = test ? "valid" : "invalid"; >); // Здесь определяется поведение при вводе пользователем значения поля addEvent(email, "input", function ()  const test = email.value.length === 0 || emailRegExp.test(email.value); if (test)  email.className = "valid"; error.textContent = ""; error.className = "error"; > else  email.className = "invalid"; > >); // Здесь определяется поведение при попытке отправить данные addEvent(form, "submit", function ()  const test = email.value.length === 0 || emailRegExp.test(email.value); if (!test)  email.className = "invalid"; error.textContent = "I expect an e-mail, darling!"; error.className = "error active"; // Некоторые устаревшие браузеры не поддерживают метод event.preventDefault() return false; > else  email.className = "valid"; error.textContent = ""; error.className = "error"; > >); 

    Результат выглядит следующим образом:

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

    Проверьте свои навыки!

    Вы дошли до конца этой статьи, но можете ли вы вспомнить самую важную информацию? Вы можете найти дополнительные тесты, чтобы убедиться, что вы сохранили эту информацию, прежде чем двигаться дальше — Test your skills: Form validation (en-US) .

    Заключение

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

    • Отображать явные сообщения об ошибках.
    • Снисходительно относиться к формату ввода.
    • Указывать, где именно возникла ошибка. Особенно в больших формах.

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

    In this module

    • Ваша первая форма (en-US)
    • Как структурировать веб-формы
    • Основные встроенные элементы формы (en-US)
    • Типы полей ввода в HTML5 (en-US)
    • Другие элементы формы (en-US)
    • Стилизация веб-форм
    • Продвинутая стилизация форм (en-US)
    • UI псевдоклассы (en-US)
    • Валидация форм на стороне клиента
    • Отправка данных формы

    Продвинутые темы

    • Как создавать кастомные элементы формы
    • Отправка форм с помощью JavaScript
    • Таблица совместимости CSS-свойств для элементов формы (en-US)

    Found a content problem with this page?

    • Edit the page on GitHub.
    • Report the content issue.
    • View the source on GitHub.

    This page was last modified on 3 авг. 2023 г. by MDN contributors.

    Your blueprint for a better internet.

    Валидация форм¶

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

    Валидация форм Angular¶

    Для того чтобы задать валидацию, используются стандартные атрибуты валидации форм HTML5 ( required , minlength , max , pattern и т. д.).

    1 2 3 4 5 6
    form> div> label>Bill Amountlabel> input type="number" max="100" required /> div> form> 

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

     1 2 3 4 5 6 7 8 9 10 11 12
    form> div> label>Bill Amountlabel> input type="number" [(ngModel)]="bill.amount" #amount="ngModel" max="100" required /> div> form> 

    Теперь переменная #amount содержит объект с информацией о поле, на которое оно ссылается. Список необходимых для валидации свойств объекта:

    • dirty — true , если пользователь осуществлял ввод (выбор) значения;
    • touched — true , если поле потеряло фокус;
    • invalid — true , если поле невалидно;
    • valid — true , если поле валидно;
    • errors — содержит объект со свойствами тех атрибутов валидации, которые не удовлетворяют заданному условию.

    Общепринято отображать ошибки только тогда, когда пользователь хоть как-то взаимодействовал с полем, то есть когда свойства invalid и dirty или touched ровно true . Вывод той или иной ошибки зависит от того, какой именно атрибут валидации не прошел проверку.

     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
    form> div> label>Bill Amountlabel> input type="number" [(ngModel)]="bill.amount" #amount="ngModel" max="100" required /> div *ngIf="amount.invalid && (amount.dirty || amount.touched)" > div *ngIf="amount.errors.required"> Required field div> div *ngIf="amount.errors.max"> Max possible value is 100 div> div> div> form> 

    Валидация реактивных форм Angular¶

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

    Список встроенных валидаторов (Angular validators):

    • required — поле обязательно для заполнения;
    • email — проверка валидности email ;
    • min(min: number) — минимальное возможное значение;
    • max(max: number) — максимальное возможное значение;
    • minLength(minLength: number) — минимальная длина вводимой строки;
    • maxLength(maxLength: number) — максимальная длина вводимой строки;
    • pattern(pattern: string | RegExp) — регулярное выражение, которому должно соответствовать вводимое значение.
     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
    @Component( selector: 'reactive-form-validation', templateUrl: './reactive-form-validation.component.html', >) export class ReactiveFormValidationComponent  clientForm: FormGroup; constructor(private fb: FormBuilder)  this._createForm(); > private _createForm()  this.clientForm = this.fb.group( client: ['', [Validators.required]], clientAge: [ '', [ Validators.required, Validators.min(16), Validators.pattern(/^[0-9]+(. )/), ], ], >); > get _client()  return this.clientForm.get('client'); > get _clientAge()  return this.clientForm.get('clientAge'); > > 
     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
    form [formGroup]="clientForm" novalidate> div> label>Clientlabel> input type="text" formControlName="client" /> div *ngIf="_client.invalid && (_client.touched || _client.dirty)" > span *ngIf="_client.errors?.required" >Field is requiredspan > div> div> div> label>Agelabel> input type="text" formControlName="clientAge" /> div *ngIf="_clientAge.invalid && (_clientAge.touched || _clientAge.dirty)" > span *ngIf="_clientAge.errors?.required" >Обязательное полеspan > span *ngIf="_clientAge.errors?.min" >Значение должно быть больше или равно >span > span *ngIf="_clientAge.errors?.pattern?['/^[0-9]+(. )/']" >Разрешаются только цифрыspan > div> div> form> 

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

    Свойства полученного объекта поля, используемые для валидации:

    • dirty — true , если пользователь осуществлял ввод (выбор) значения;
    • touched — true , если поле потеряло фокус;
    • invalid — true , если поле невалидно;
    • valid — true , если поле валидно;
    • errors — содержит объект со свойствами тех атрибутов валидации, которые не удовлетворяют заданному условию.

    Остановимся на поле errors . Многие Angular validators принимают входные параметры ( maxLength , pattern и др.), поэтому для получения исчерпывающей информации о неправильном заполнении полей, к которым они применены, их значения в errors реализованы в виде объектов. В таком объекте содержатся данные о текущем значении и ограничения, накладываемые на это значение (см. пример выше).

    Например, ключи объекта ошибки валидатора pattern — сами регулярные выражения. Что позволяет однозначно идентифицировать ошибку и отобразить пользователю соответствующее сообщение.

    Более подробное описание можно найти в документации.

    Для работы с ошибками в реактивных формах предусмотрены прикладные методы:

    • setErrors(errors: ValidationErrors) — используется для того, чтобы задать ошибку вручную;
    • getError(errorCode: string) — вернет объект с данными о запрашиваемой ошибке, если поле валидно, то вернется null или undefined ;
    • hasError(errorCode: string) — вернет true , если поле имеет указанную ошибку.
    this.clientForm.get('client').hasError('required'); 

    Для динамического добавления полю валидаторов используется метод setValidators() .

    1 2 3
    this.clientForm .get('client') .setValidators([Validators.maxLength(100)]); 

    Чтобы удалить все привязанные к полю Angular validators, необходимо вызвать метод clearValidators() .

    this.clientForm.get('client').clearValidators(); 

    Еще один редко используемый, но крайне полезный метод updateValueAndValidity() , который запускает обновление значения и состояния формы или ее группы (поля).

    this.clientForm.get('clientAge').updateValueAndValidity(); 

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

     1 2 3 4 5 6 7 8 9 10 11
    export function accountValidator(): ValidatorFn  return ( control: AbstractControl ):  [key: string]: boolean > | null =>  let accountRgEx: RegExp = /^[0-9](. )/; let valid = !control.value || accountRgEx.test(control.value); return valid ? null :  account: true >; >; > 
    1 2 3 4 5
    import accountValidator> from './validators/account.validator.ts'; // accountNumber: ['', [accountValidators()]], // 

    В примере accountValidator() проверяет корректность номера банковского счета (20 цифр — проверка условная). Если номер введен не верно, тогда для поля accountNumber будет установлена ошибка account со значением true .

    Валидатор всегда должен возвращать null , если переданное значение удовлетворяет всем его проверкам.

    Асинхронные валидаторы Angular¶

    Использование механизма асинхронной валидации (Angular async validators) позволяет проверять введенное значение на удаленном сервере. Например, проверка уникальности имени пользователя при регистрации.

    Перейдем к практике. Допустим, имеется форма заказа какого-либо товара, где пользователь указывает желаемое его количество. Создадим валидатор checkGoodsLeftValidator() , который будет проверять, имеется ли запрошенное покупателем количество товара.

     1 2 3 4 5 6 7 8 9 10
    @Injectable( providedIn: 'root' >) export class GoodsService  constructor(private http: HttpClient) <> checkGoodsLeft( count: number | string ): Observableany>  return this.http.get('/api/goods/left'); > > 
    1 2 3 4 5 6 7 8 9
    export function checkGoodsLeftValidator( control: AbstractControl )  return this.checkGoodsLeft(control.value).pipe( tap((response) =>  return response ? null :  goodsLeft: true >; >) ); > 
     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
    @Component( selector: 'check-goods-left-validator-example', templateUrl: './check-goods-left-validator-example.component.html', >) export class CheckGoodsLeftValidatorExampleComponent  orderForm: FormGroup; constructor( private fb: FormBuilder, private goodsService: GoodsService )  this._createForm(); > private _createForm()  this.orderForm = this.fb.group( client: ['', [Validators.required]], goodsCount: [ '', [Validators.required], [ checkGoodsLeftValidator.bind( this.goodsService ), ], ], >); > > 

    Поскольку наш Angular async validator обращается к методу сервиса, а сам валидатор вызывается в контексте компонента, который его использует, здесь используется привязка контекста сервиса GoodsService с помощью bind() .

    Все асинхронные валидаторы указываются в массиве третьим параметром.

    Стилизация формы¶

    В зависимости от состояния и статуса валидации, форме и ее полям устанавливаются соответствующие CSS-классы, которые можно использовать для стилизации элементов.

    • ng-valid ;
    • ng-invalid ;
    • ng-pending ;
    • ng-pristine ;
    • ng-dirty ;
    • ng-untouched ;
    • ng-touched .

    Ссылки¶

    Валидация полей формы перед отправкой с помощью Google Tag Manager

    Контекстная, таргетированная реклама и веб-аналитика

    В предыдущем материале мы разобрали 9 способов отслеживания отправки формы с помощью Google Tag Manager. В этой статье поговорим о валидации полей формы перед ее отправкой и о том, как избежать отправки пользователем пустых данных в аналитику.

    Проблема отслеживания отправки форм

    Иногда на сайтах встречаются формы, которые можно отправить пустыми. Например, пользователь нечаянно или нарочно не заполняет ее, и нажимает кнопку отправить. В результате ваш триггер Google Tag Manager срабатывает, а тег передает данные о совершенном событии в счетчики веб-аналитики. Получается искажение статистики — заявка пустая или ее вообще не было, но +1 в аналитике конверсия засчиталась. Или в поле формы, например, где требуется указать электронный адрес (@. ), пользователь вводит заведомо неверную информацию (абракадабру, фейк), и отправляет свое обращение вам. Если на сайте не предусмотрено никакой проверки, то у вас в аналитике также зарегистрируется ложное событие, которого на самом деле не было.

    Вот как это выглядит на практике. Предположим, у нас есть форма, состоящая из нескольких полей:

    Пример формы с полями

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

    Событие отправилось в аналитику несмотря на то, что e-mail введен неверно

    Это будет происходить даже несмотря на то, что у текущей формы присутствует базовая проверка на корректность ввода информации в поля, в том числе по длине символов (валидация на стороне клиента):

    Простенький валидатор формы по корректности ввода и длине текста в полях

    Триггер Google Tag Manager все равно может сработать и передать недостоверную информацию в счетчики аналитики. Например, такая ситуация часто встречается при работе стандартного триггера типа Отправка формы, когда на вашем сайте есть форма с тегом form> и кнопкой submit:

    • обязательное поле (нельзя оставить его пустым);
    • корректный ввод данных в определенное поле (например, номер телефона в формате +7 xxx-xxx-xx-xx);
    • определенный формат данных (в пароле должна быть как минимум одна заглавная буква, один символ, одна цифра, и он должен быть от 8 до 30 символов).

    Все это называется валидацией формы. По мере ввода, браузер и/или сервер проверяют данные, чтобы определить, соответствуют ли они требуемому формату. В связи с этим валидация формы может проводиться двумя способами:

    • на стороне сервера (выполняется на сервере);
    • на стороне клиента (выполняется в браузере);

    Есть еще третий вариант — это проверка заполнения полей с помощью диспетчер тегов Google. Но он является частью JavaScript-валидации и будет рассмотрен в самом конце руководства.

    Валидация на стороне клиента

    Под валидацией на стороне клиента подразумевается проверка, совершаемся в браузере пользователя перед отправкой формы на сервер. Она помогает пользователю быстро обнаружить ошибки при заполнении данных и исправить их. На текущий момент существует два типа валидации на стороне клиента — встроенная валидация форм и JavaScript-валидация.

    1. встроенная валидация форм

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

    Практическая каждая форма на сайте внутри себя содержит элементы формы. Элементы формы — это различные типы элементов ввода, такие как текстовые поля, флажки, переключатели, кнопки отправки и многое другое. Самыми распространенными элементами формы являются элементы .

    Элемент отображается несколькими способами, в зависимости от атрибута type:

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

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

    Вам откроется консоль разработчика в браузере (клавиша F12 для Google Chrome) с уже выделенным/проинспектированным полем:

    Инспектирование конкретного поля

    Как видите, у поля Имя тип text — это текстовое поле для ввода информации согласно HTML-разметке. У других полей вашей формы могут быть другие типы.

    Помимо этого, поля имеют различные атрибуты. Например:

    • placeholder — задает короткую подсказку, описывающую ожидаемое значение поля ввода (примерное значение или краткое описание ожидаемого формата);
    • required — указывает, что перед отправкой формы необходимо заполнить поле ввода;
    • minlength и maxlength — указывают минимальное и максимальное количество символов, которые можно ввести в поле;
    • min и max — задают минимальное и максимальное значение для полей с числами и датами;
    • pattern — указывает регулярное выражение, по которому проверяется значение поля ввода при отправке формы;
    • value — задает начальное значение для поля ввода;

    Если данные, введенные в поле формы, соответствуют правилам перечисленных выше атрибутов, они считаются валидными, если нет — не валидными.

    Для того, чтобы узнать какие HTML-атрибуты заданы у конкретного поля формы, вам нужно сделать точно так же — поставить курсор мыши внутрь самого поля, нажать правой кнопкой мыши и выбрать пункт Просмотреть код. Вам откроется консоль разработчика с уже выделенным/проинспектированным полем, а рядом с типом будут перечислены все атрибуты, которые присутствуют у данного HTML-элемента:

    Пример поля с HTML-атрибутами

    Как видно из примера, у поля с типом e-mail (поле для ввода электронной почты) есть два HTML-атрибута:

    1. required — указывает, что перед отправкой формы необходимо заполнить поле ввода;
    2. placeholder — задает короткую подсказку (в данном примере текст E-mail).

    Соответственно, если я не заполню поле E-mail, то система выдаст предупреждение:

    Заполните это поле

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

    2. JavaScript-валидация

    Дополнительно к HTML-атрибутам (или вместо) для полей ваших форм имеет смысл настроить валидацию с помощью JavaScript. На этом языке программирования пишутся функции, которые проверяют данные и выводят сообщение, если пользователь неправильно заполнил поле, до момента отправки формы на сервер. Такие подсказки можно показывать как в момент набора текста, так и при попытке отправить форму.

    Например, на одном из моих тестовых проектов у поля для написания отзывов нет никаких HTML-атрибутов. Но если пользователь введет текст отзыва менее 25 и более 1000 символов, ему отобразится такое сообщение:

    Специальное оповещение на JavaScript

    Это и есть JavaScript-валидация, когда используется программирование и определенная логика срабатывания в браузере клиента перед отправкой формы на сервер. К сожалению (а может и к счастью), какой-то единой JS-функции для проверки валидации для всех сайтов и форм в интернете, которую можно было бы приложить в этом руководстве, не существует, поэтому для вашей конкретной задачи и формы вам нужно написать свое собственное решение. Попросите это сделать вашего разработчика. Как правило, самые популярные CMS-движки (WordPress, OpenCart, Tilda, 1С-Битрикс, Joomla и другие) имеют встроенные валидаторы.

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

    Поиск готовых решений JavaScript-валидаций

    Примечание: вы можете попробовать использовать готовые библиотеки PristineJS, Formik, Validator.js и другие.

    Подробнее о валидации форм на стороне клиента читайте в официальной документации Mozilla.

    Валидация на стороне сервера

    Проверку на стороне клиента можно легко обойти, поэтому важно произвести валидацию данных и на стороне сервера, то есть после отправки формы. Такая валидация гораздо надежнее, так как не зависит от клиента и помогает точнее обнаружить ошибки в заполненных полях. Например, пользователь может попытаться ввести некорректный адрес электронной почты, и если эта ошибка не будет обнаружена, то письмо, отправленное на этот e-mail, не будет доставлено.

    Реализация валидации на стороне сервера обычно осуществляется с помощью серверных языков программирования, таких как PHP, Python, Ruby, Java и других. Вот хороший пример с обработкой форм на PHP. Обязательно посмотрите это видео, чтобы иметь представление о том, как осуществляется проверка на стороне сервера:

    Как видите, такая работа выполняется на бэкенде и требует навыков программирования, а, следовательно, практически всегда ложится на плечи разработчика. Именно он должен продумать способы проверки заполнения полей форм — обязательные, на длину текста, на формат данных (телефон, e-mail), на уникальность (чтобы пользователей с одним и тем же логином не было в базе) и т.д.

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

    Валидация форм на стороне сервера важна, потому что позволяет защитить сайт от злонамеренных действий пользователей, таких как ввод некорректных данных, SQL-инъекций, XSS-уязвимостей и других атак. Проводить ее уместно почти всегда, даже если вы уже выполнили валидацию на стороне клиента с помощью HTML-атрибутов и JavaScript.

    Однако описанные выше способы валидации (как на стороне клиента, так и на стороне сервера) не отменяют тех действий, которые вам необходимо выполнить в Google Tag Manager.

    Валидация с помощью Google Tag Manager

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

    Но даже при валидации на стороне клиента с использованием HTML-атрибутов или функции JavaScript диспетчер тегов Google по умолчанию запускает тег отслеживания отправки формы всякий раз, когда она отправляется, независимо от неполных входных данных формы, а иногда и пустых форм. Стандартный триггер Отправка формы срабатывает даже при простом нажатии на кнопку, у которой имеется тип . Результат — ложное срабатывание и ложная отправка события (=конверсии) в счетчики аналитики.

    JavaScript-валидация и HTML-атрибуты тут не помогут. Чтобы избежать такого сценария, нужна дополнительная проверка и как минимум еще одно условие активации триггера. А поскольку в Google Tag Manager можно использовать код на JavaScript, то без программирования нам все равно не обойтись.

    В качестве примера я буду выполнять валидацию для формы с тремя полями — Ваше имя, Ваш E-mail и Ваш вопрос или сообщение:

    Пример формы с полями

    Для этого необходимо использовать пользовательскую переменную типа Собственный код JavaScript. Перейдите в раздел Переменные и создайте ее, взяв за основу нижеприведенный код. Он гарантирует, что при отправке формы нет пустых полей, а также проверяет правильность формата ввода электронной почты и телефона:

    var name = document . querySelector ( ‘CSS-селектор для имени’ ). value ;
    var email = document . querySelector ( ‘CSS-селектор для email’ ). value ;
    var tel = document . querySelector ( ‘CSS-селектор для телефона’ ). value ;
    var message = document . querySelector ( ‘CSS-селектор для сообщения’ ). value ;

    var emailRegExp =/^([ a — zA — Z0 — 9_. +-])+\@(([ a — zA — Z0 — 9 -])+\.)+([ a — zA — Z0 — 9 ]< 2 , 4 >)+$/ i ;

    var telRegExp = /^\+?[ 0 — 9 ()\- ]< 10 , 20 >$/;
    if ( name . length > 0 && message.length > 10 && emailRegExp.test(email) && telRegExp.test(tel)) < return true; return false ;

    • CSS-селекторы в Google Tag Manager. Часть I
    • Селекторы в jQuery. Часть II
    • Регулярные выражения в CSS-селекторах и GTM
    • CSS Selector Tester и его аналоги
    • Google Tag Manager и jQuery

    Чтобы извлечь значение из поля формы, необходимо проинспектировать каждый элемент формы с использованием консоли разработчика. Только теперь, выделив нужное поле формы, в инспекторе элементов нажмите на него правой кнопкой мыши и выберите Copy — Copy selector:

    Благодаря этому вы скопировали селектор конкретного поля формы. Вы можете перейти на вкладку Console и вставить эту строчку кода, нажав Enter:

    document . querySelector ( ‘selector’ ). value ;
    , где вместо selector вы вставляете ваше значение скопированного селектора.

    Проверка конструкции извлечения

    Вы должны увидеть значение, введенное в поле формы. Именно эта конструкция с селектором для конкретного HTML-элемента и присваивается переменной в собственном коде JavaScript:

    Пример переменной с селектором для конкретного поля формы

    1. name — переменная для поля с именем;
    2. email — переменная для поля с электронной почтой;
    3. tel — переменная для поля с телефоном;
    4. message — переменная для поля с сообщением.

    Окончательный набор переменных зависит от вашей формы и может отличаться как в меньшую, так и в большую сторону. Например, для формы из моего примера таких полей всего три (Ваше имя, Ваш E-mail и Ваш вопрос или сообщение), поэтому из кода я могу удалить переменные tel и telRegExp, отвечающие за извлечение значения из поля формы и проверки его на корректный ввод с использованием регулярного выражения. У меня их попросту нет. Удалить нужно еще и условие проверки:

    Редактирование шаблона переменной под свою форму

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

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

    Итоговый код для моего примера в Google Tag Manager будет выглядеть так:

    Итоговая переменная валидация полей

    Задайте переменной название и сохраните ее.

    Код переменной работает достаточно просто — сначала с вводного оператора var объявляется то количество переменных, которое присутствует в вашей форме (name, email, tel и т.д.). Если в форме присутствует электронный адрес, то объявляется переменная emailRegExp с регулярным выражением на проверку корректности ввода данных в нужном формате (с @ и т.д.). Если в вашей форме есть поле с телефоном, то так же объявляется переменная telRegExp с регулярным выражением на проверку корректности ввода данных в нужном формате. С помощью конструкций document.querySelector(‘selector’).value извлекаются значения, которые ввел пользователь в эти поля формы.

    Затем происходит проверка с помощью оператора if и нескольких условий, разделенных оператором && (И). Валидация полей по длине символов осуществляется с помощью свойства length. Если длина поля с именем name > 3 (можно задать любое другое значение) и переменная с сообщением message > 10 (можно задать собственное значение) и переменная с электронным адресом email удовлетворяет условию регулярного выражения, заданному в переменной emailRegExp, то текущее значение всей переменной собственного кода JavaScript будет true. В противном случае, если хоть одно условие проверки будет ложным, то и вся переменная CJS — Validate form примет значение false.

    Вы можете проверить это с помощью режима предварительного просмотра. Активировав режим отладки GTM, откройте форму и заполните сначала все поля формы корректно. Сделайте тестовую заявку. Выбрав соответствующий триггер, откройте вкладку Variables и посмотрите какое значение приняла ваша переменная. При правильно заполненных полях формы переменная должна принять значение true:

    Переменная принимает значение true если все поля заполнены корректно

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

    Переменная принимает значение false если хотя бы одно поля заполнено неверно

    На скриншоте выше видно, что поле e-mail не соответствует регулярному выражению из нашей проверки, поскольку электронная почта введена неправильно. Поэтому пользовательская переменная CJS — Validate form приняла значение false.

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

    Триггер с дополнительным условием валидации

    Сохраните изменения. Если у вас есть несколько форм, то вам нужно создать пользовательскую переменную CJS — Validate form для каждой из них на основе полей в форме, так как селекторы для каждого поля будут уникальными.

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

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

    Какие есть правила валидации полей

    На всех проектах Mindbox существуют правила заполнения полей. При передаче информации происходит проверка передаваемых данных. Валидация проверяет, что в поле записываются разрешенные для него символы и количество этих символов не превышает лимит.

    ФИО

    Зависит от настроек в анкете клиента:

    Русский алфавит

    В начальных настройках выбран русский алфавит.

    То есть разрешены символы из регулярного выражения:

    ^[А-яЁё][А-яЁё’\- ]*$ 
    • Первый символ (или единственный, если он один) должен быть любой буквой русского алфавита.
    • Дальше — любая буква русского алфавита, апостроф, дефис или пробел.
    Другие алфавиты и «любые символы»

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

    После добавления нового алфавита убрать его из настроек нельзя.

    Если нужного вам алфавита нет в представленном списке, выберите опцию «любые символы».

    Регулярное выражение для него:

    ^[\p`’‘’\- \.0-9\(\)\+=\?\*\/«\!\,_\@№\:·\p\p\p \p\p\p\p\p\p\p\p \p\p\p\p\p\p\p \p\p\p\p\p\p\p\p \p\p\p\p\p\p\p \p\p\p\p\p\p\p\p\p\p \p\p\p\p\p\p \p\p\p\p \p\p\p\p \pᲐ-Ჿ]*$ 

    В таком случае можно использовать буквы из перечисленных алфавитов, цифры и символы `’‘’-.()+=?*/»!,_@№:·

    Количество символов

    Не больше 100 в каждом поле.

    Иногда при передаче ФИО через общее поле FullName мы не можем определить, что является именем и фамилией, и записываем всё в имя. Подробнее.
    В таком случае ФИО в целом должно быть не более 100 символов с учетом пробелов, потому что запись сохраняется в одном поле.

    Мобильный номер

    Зависит от настроек в анкете клиента (см. скриншот выше).

    В начальных настройках выбран телефонный код России. Можно добавить код любой страны.

    Символы

    При записи мы отбрасываем все символы, кроме цифр. Поэтому наличие и порядок скобок, тире и плюсов не имеет значения. Главное, чтобы был код страны и достаточное количество цифр.

    Код

    Номер должен начинаться с международного или внутреннего кода (для России это 7 и 8 соответственно).
    Мы в любом случае сохраняем с международным кодом.

    Количество символов

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

    Email

    Проверяется регулярным выражением:

    ^([\p0-9_\-!#\$%&’\*\+/=\?\^`\<>\|~])+([\.\p0-9_\-!#\$%&’\*\+/=\?\^`\<>\|~])*@ ([\p0-9]([\p0-9\-][\p0-9])?\.)*[\p0-9]([\p0-9\-][\p0-9])?$ 
    • Часть до @
      • Минимум один символ.
      • Первый — любая буква, цифра или символ _-!#$%&’*+/=?^`|~
      • Дальше — любая буква, цифра или символ ._-!#$%&’*+/=?^`|~ (прибавляется точка)
      • Минимум один символ.
      • Может разделяться на доменные группы точками. При этом в каждой группе:
        • Первый и последний символ — любая буква или цифра.
        • Остальные — любая буква, цифра или тире.
        • 1-63 символа (включая точку-разделитель).
        Количество символов

        До 254 символов включительно.

        Пол

        Регистр не важен.

        Дополнительные поля

        Строка и идентификаторы

        Любые символы.
        До 1000 символов включительно.

        Перечисление

        Любые символы, кроме | .
        До 250 символов включительно в каждом значении.

        Символ | можно передавать в качестве разделителя в файлах импорта при использовании множественных значений.

        Целочисленный

        Только цифры.
        Значения от −2147483648 до 2147483647 (10 символов не включая минус).

        Десятичный

        Только цифры с точкой или запятой.
        До запятой — максимум 16 символов, после запятой — максимум 2 символа.
        Значения от −999999999999999999.99 до 999999999999999999.99

        Логический

        Регистр не важен.

        Дата, дата и время

        dd.MM.yyyy HH:mm:ss.FFF
        dd.MM.yyyy H:mm:ss.FFF
        dd.MM.yyyy HH:mm:ss
        dd.MM.yyyy H:mm:ss
        dd.MM.yyyy HH:mm
        dd.MM.yyyy H:mm
        dd.MM.yyyy
        d.M.yyyy HH:mm:ss.FFF
        d.M.yyyy H:mm:ss.FFF
        d.M.yyyy HH:mm:ss
        d.M.yyyy H:mm:ss
        d.M.yyyy HH:mm
        d.M.yyyy H:mm
        d.M.yyyy
        yyyy.MM.dd HH:mm:ss.FFF
        yyyy.MM.dd H:mm:ss.FFF
        yyyy.MM.dd HH:mm:ss
        yyyy.MM.dd H:mm:ss
        yyyy.MM.dd HH:mm
        yyyy.MM.dd H:mm
        yyyy.MM.dd
        yyyy.M.d HH:mm:ss.FFF
        yyyy.M.d H:mm:ss.FFF
        yyyy.M.d.M.d HH:mm:ss
        yyyy.M.d H:mm:ss
        yyyy.M.d HH:mm
        yyyy.M.d H:mm
        yyyy.M.d
        yyyy-MM-dd HH:mm:ss.fff
        yyyy-MM-dd HH:mm:ss.FFF
        yyyy-MM-dd H:mm:ss.FFF
        yyyy-MM-dd HH:mm:ss
        yyyy-MM-dd H:mm:ss
        yyyy-MM-dd HH:mm
        yyyy-MM-dd H:mm
        yyyy-MM-dd
        yyyy-M-d HH:mm:ss.FFF
        yyyy-M-d H:mm:ss.FFF
        yyyy-M-d HH:mm:ss
        yyyy-M-d H:mm:ss
        yyyy-M-d H:m:s
        yyyy-M-d HH:mm
        yyyy-M-d H:mm
        yyyy-M-d
        MM/dd/yyyy HH:mm:ss
        MM/dd/yyyy H:mm:ss
        MM/dd/yyyy HH:mm
        MM/dd/yyyy H:mm
        MM/dd/yyyy
        MM/dd/yy

        Если в поле типа дата передаются часы и минуты, они отбрасываются при записи.

        Если данные не проходят валидацию

        Невалидное значение не будет записано в поле.

        Срабатывает ли при этом операция?

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

        В большинстве случаев при нарушении правил валидации, операция выполняется.

        Исключения, при которых операция не выполняется:

        • Превышение лимита символов в полях ФИО (если сами символы валидные).
        • Превышение лимита символов в поле с типом «перечисление» (если передано имеющееся значение из поля или у поля включена настройка «Создавать значение перечисления, если не найдено»).
        • Наличие символа | в поле с типом «перечисление».
        • Невалидное поле — единственный идентификатор клиента. Мы не можем создать клиента без идентификаторов.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *