Экранные формы и валидации

Макет показывает, как форма выглядит, но не отвечает на вопросы, которые сразу задаёт разработчик. Можно ли оставить поле пустым? Какие символы допустимы? Что написать, если значение неверное? Ответы на них и называют валидациями: это проверки введённых данных перед тем, как система их примет.

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

Кейс: регистрация в «Узелке»

В магазине «Узелок» запускают регистрацию покупателя. Дизайнер нарисовал форму с полями «Email», «Пароль», «Телефон» и флажком согласия. В требованиях сказано одно: «Покупатель вводит данные и регистрируется». Разработчик интерфейса сделал пароль от 6 символов, разработчик сервера принял от 8 (числа условные), а база данных вообще не проверяла уникальность почты. В итоге часть людей получала отказ после нажатия кнопки без объяснения, а в базе появились две учётные записи на один адрес.

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

Таблица полей

Каждое поле формы описывают строкой таблицы. Для регистрации она может выглядеть так:

Что записать про каждое поле

Минимальный набор столбцов такой:

• Поле и тип: как называется и что хранит, например строка или флаг.
• Обязательность: можно ли отправить форму, оставив поле пустым.
• Формат: допустимые символы, длина, шаблон. Числа в примере условные.
• Значение по умолчанию: что стоит в поле до ввода, если что-то стоит.
• Текст ошибки: что покажем при нарушении, словами для человека.
• Зависимости: от каких полей зависит это поле. Если выбран самовывоз, адрес доставки не нужен.

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

Три вида проверок

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

Где проверяют ввод

Проверку нельзя оставить на одном уровне, у каждого есть слабое место:

• Интерфейс подсказывает сразу, но его можно обойти: запрос отправляется и без формы.
• Сервер проверяет каждый запрос и поэтому является главной проверкой. Но он не всегда знает про данные, которые уже хранятся в базе.
• База данных не даёт сохранить заведомо неверную запись, например две учётные записи на один email. Но ошибка видна поздно, и её сложно превратить в понятный текст.

Проверку на сервере всегда делают, даже если браузер проверяет те же поля. Проверка в браузере нужна для быстрой обратной связи, а не как защита.

Как описать, на каком уровне что проверяется

Добавляем в таблицу полей столбец «Где проверяется». Для нашей формы email проверяется во всех трёх местах: формат в интерфейсе и на сервере, уникальность на сервере и в базе. Согласие проверяется в интерфейсе и на сервере, в базе хранится результат. Так видно, что ни одно требование не осталось без владельца.

Где это встречается в работе

• Описание формы в требованиях перед согласованием макета (статья 02-15).
• Передача разработчикам: таблица полей становится основой для интерфейса и для запроса к серверу.
• Тестирование: каждая строка таблицы даёт проверки на границах значений (статья 02-25).
• Разбор жалоб поддержки вроде «система не принимает мой номер».
• Проектирование ограничений в базе данных (статья 04-03) и в API (статья 05-07).

Итог

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

Что дальше

Дальше разберём состояния экрана: что видит пользователь, пока данные загружаются, когда их нет и когда запрос закончился ошибкой (статья 02-17).