В прошлом посте разбирали валидацию - проверку, что данные подходят для использования. Но валидные данные не равно стандартизированные данные. Вот где начинается нормализация.
👀 Зачем нужна нормализация когда есть валидация
Валидация ответит «данные валидны для использования», но не исправит их:
«89161234567» и «+7(916)123-45-67» оба телефона верные, и в базе создадут два разных аккаунта, но поиск по одному не найдёт второй
«Москва, ул. Ленина» и «г. Москва, улица Ленина» - один адрес, два разных написания
Нормализация решает эту проблему - приводит данные к единому виду до сохранения.
📌 Валидация обрамляет нормализацию с двух сторон
Данные которые передаём на нормализацию тоже должны соответствовать минимальным требованиям - быть валидны для обработки. Поэтому валидация происходит дважды:
Ввод пользователя
|
Базовая валидация: проверка, что данные пригодны для нормализации?
(не пусто, минимальная длина, тип данных)
|
Нормализация: привести к стандарту
|
Финальная валидация: данные пригодны для сохранения?
(формат, бизнес-правила, уникальность)
|
Сохранение в базу
🎯 До нормализации проверяем, что данные вообще пригодны для обработки
🎯 После нормализации проверяем, что результат соответствует требованиям системы
Можно ли сразу писать правила валидации под нормализованный формат?
Да, но только для простых полей. Например для email: вместо «просто проверь что есть @ и точка» пишешь правило «только lowercase, без пробелов». Тогда нормализация делает своё дело до валидации, и валидация проверяет уже «чистые» данные.
Но не всегда это возможно:
Телефон - пользователь может ввести «89161234567» или «+79161234567» или «8(916)123-45-67». Запретить все форматы кроме одного - плохой UX. Правильно: принять любой -> нормализовать -> валидировать итог
Адрес - невозможно написать правило которое покрывает все адреса страны. Поэтому и существуют внешние справочники вроде Дадата - они нормализуют данные.
ФИО - «Иван Иванов Иванович» и «Иванов Иван Иванович» оба правильные и нормализация нужна
🔴 Главный принцип: не наказывай пользователя за формат, если его можно исправить автоматически.
📌 Где происходит нормализация
На фронте (до отправки на сервер):
• Дает быструю обратную связь пользователю
• Снижает нагрузку на бэкенд
• Форматирование отображения в реальном времени
На бэкенде:
• Финальная нормализация перед записью в базу, так как бэкенд не доверяет данным с фронта
📌 Примеры нормализации на фронте
Простая без внешних сервисов:
• Обрезка пробелов: « Иван » -> «Иван»
• Регистр email: «IVAN@MAIL.RU» -> «ivan@mail.ru»
• Форматирование телефона: «89161234567» -> «+7 (916) 123-45-67»
• Удаление лишних символов из номера карты
Сложная (через внешние сервисы-справочники):
• Адреса - через Дадата / ФИАС
• ФИО - разбивка на имя, фамилию, отчество
• ИНН, ОГРН, реквизиты банков
🧩 Внешние сервисы - это справочники
Дадата, ФИАС, ГАР - это по сути справочники с API:
• Содержат эталонные данные (все адреса РФ, все ИНН, все банки)
• Фронт отправляет введённый текст -> справочник возвращает нормализованный объект
• Выбор из подсказок сам по себе является валидацией - пользователь не может ввести несуществующий адрес
🌿 Ловушки для QA
1) Бэкенд принимает только структурированный объект с ФИАС-кодом, если пользователь ввёл адрес вручную без выбора подсказки и нажал Submit, бэкенд вернёт ошибку
2) Нормализация на фронте и на бэкенде может различаться
3) Данные могут быть валидны, но не нормализованы - такие баги проявляются не сразу, а при поиске, сравнении и дедупликации
4) ФИАС-коды домов периодически меняются - ранее сохранённый адрес может стать невалидным
5) Debounce 300-400ms на запросы к Дадата - проверь поведение при быстром вводе и медленной сети
6) Если сервис-справочник недоступен, то поле ввода может заблокироваться или криво работать
Поставь 🔥, если полезно
#интеграции