Опишите данные и состояния заранее
Пусть форма содержит название предмета и описание неисправности. Для учебного примера название обязательно, а описание должно укладываться в установленное приложением ограничение. Договоритесь о названиях полей, типах данных и формате ошибок до подключения красивых компонентов. У интерфейса есть разные состояния: пользователь редактирует, данные проверяются, запрос отправляется, сохранение подтверждено или возникла ошибка. Не сводите всё к одному признаку «загрузка». Например, ошибка поля требует исправить текст, а недоступность сети — другого объяснения. В React отображение связывают с состоянием приложения. Пользователь должен видеть, что происходит сейчас, а введённый текст не должен исчезать просто потому, что первая попытка отправки не удалась.
Проверяйте на клиенте и на сервере
Ant Design Form позволяет задавать правила полей и обрабатывать успешное прохождение клиентской проверки через onFinish. Однако успешная проверка формы означает лишь готовность отправить данные, а не сохранение заявки. Запрос всё ещё должен получить подтверждение от API. Сервер повторно проверяет входные данные, потому что запрос может прийти без вашего интерфейса. В контроллерах ASP.NET Core с атрибутом ApiController ошибки валидации модели обычно автоматически приводят к ответу HTTP 400. Конкретное поведение зависит от выбранной конфигурации и подхода к API; его нужно согласовать с клиентом. Проверка формата не заменяет бизнес-правила и проверку прав доступа. Непустое название предмета ещё не означает, что пользователь вправе изменить чужую заявку. Эти решения принимает сервер, опираясь на свою модель данных и авторизацию.
Показывайте успех только после подтверждения
Предположим, API вернул подтверждённый результат с идентификатором новой заявки. Тогда интерфейс может показать номер и предложить перейти к карточке. Если сервер вернул ошибки полей, их полезно сопоставить с соответствующими элементами формы и сохранить остальные введённые значения. Отдельный случай — запрос ушёл, но ответ не получен. Это не всегда означает, что сохранение не состоялось. Автоматическое повторение может создать дубликат. Для операций создания заранее продумывают способ сверки результата или защиту от повторной обработки на стороне сервера. Отключённая кнопка уменьшает случайные повторные нажатия, но сама по себе не решает сетевую неопределённость. Журналирование помогает разбирать сбои, однако в сообщения пользователю не следует переносить внутренние трассировки и лишние технические сведения. Сообщение должно объяснять доступный следующий шаг, сохраняя введённые данные там, где это уместно.
Попробуйте на практике
Спроектируйте на бумаге поведение формы заявки без установки библиотек и запуска сервера.
- Запишите два поля, их типы и правила, затем придумайте по одному корректному и ошибочному примеру ввода.
- Опишите ответы API для успешного создания и ошибки проверки. Укажите, как клиент найдёт ошибочное поле.
- Нарисуйте переходы между редактированием, отправкой, подтверждённым успехом и ошибкой.
- Добавьте сценарий потерянного ответа и запишите, как приложение будет выяснять результат до повторного создания.
Как проверить результат. Клиентская проверка не считается сохранением, сервер проверяет данные независимо, а неизвестный результат не превращается автоматически в повторный запрос. Успех связан с подтверждением API.
Частые вопросы
Можно ли оставить проверку только в Ant Design?
Нет. Клиентская проверка улучшает взаимодействие, но сервер должен самостоятельно проверять данные и права на действие.
Достаточно ли блокировать кнопку на время запроса?
Это полезно для интерфейса, но не гарантирует отсутствие дубликатов при повторе запроса или потере ответа. Нужен продуманный серверный сценарий.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.