Изменение поведения проверки ввода веб-компонентов Vaadin 24 Flow onblur

Question

Поведение того, как входные элементы в форме запускают проверку, изменилось между Vaadin 23 и 24. Под проверкой я подразумеваю либо цепочку формы, bean-компонент с аннотациями Bean Validation API и связующим BeanValidationBinder, либо некоторые ограничения для поля ввода.

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

Примеры использования BeanValidationBinder в формах ValidationView:

• Версия 24: https://github.com/tengcomplex/vaadin24-binder-validation-demo
• V23 ведет себя как 14, проверял локально.
• Версия 14: https://github.com/tengcomplex/vaadin14-binder-validation-demo

В живых демонстрационных примерах ограничений полей в документации Vaadin это также воспроизводится:

• Версия 24: https://vaadin.com/docs/latest/comComponents/text-field/#constraints
• Версия 23: https://vaadin.com/docs/v23/comComponents/text-field/#pattern
• Версия 14: https://vaadin.com/docs/v14/ds/comComponents/text-field/#pattern

В этой демонстрации BeanValidationBinder не используется, но принцип должен быть тот же.

• Нажмите на текстовое поле «Номер телефона».
• Не вводите никаких данных.
• Выйдите из текстового поля с помощью табуляции или мыши.

Посмотрите, как текстовое поле становится красным в V24 без ввода данных. В предыдущей версии он стал красным только в том случае, если перед выходом вы ввели что-то неправильно.

Проблема https://github.com/vaadin/platform/issues/3066 , похоже, является подходящим местом этого изменения.

Не могу найти упоминаний об этом в различных местах изменений на V24.

• https://vaadin.com/docs/latest/upgrading
• Github vaadin/платформа/релизы

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

Рассмотрим форму с N входами, компонент со строковыми полями и аннотациями @NotEmpty и BeanValidationBinder, инициализированный с помощью методаbindInstanceFields(). При загрузке фокус имеет первый вход. Пока все в порядке, все в порядке. Но если пользователь напрямую щелкает третий ввод в форме, отображается сообщение об ошибке первого ввода, которое может выглядеть неинтуитивно.

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

Глядя в основном на com.vaadin.flow.comComponent.textfield.TextField, я не вижу какого-либо общего способа избежать проверки при размытии. Перезаписать все необходимые веб-компоненты или предоставить собственный BeanValidationBinder возможно, но это кажется неправильным.

Кажется, существует потребность в деактивации проверки размытия в https://github.com/vaadin/web-comComponents/issues/354 с точки зрения использования без потока, что может быть полезно, если оно когда-либо будет подхвачено и реализовано.

Вопросы: можно ли как-то добиться «старого» поведения проверки в приложении V24? Есть ли планы реализовать для этого какую-то обратную совместимость? Можно ли считать это ошибкой и проблема будет уместной?

Answer 1

Вы не сравниваете одно и то же: в демо-версии V24, на которую вы ссылаетесь, поле также настроено как «обязательное» (обратите внимание на маленькую синюю точку после метки). Выход из обязательного поля уведомляет пользователя о том, что ввод отсутствует. Такое же поведение наблюдается в V23 (и, скорее всего, в V14).

Answer 2

Краткое изложение возможных обходных путей

Поскольку подтверждено, что эта проблема известна и что Vaadin собирается реализовать проверку только для «грязных» полей в #6146, возможно, просто необходимо иметь временное решение для текущих выпусков V24. Во время оценки я сталкивался с разными подходами.

• Реализуйте свой собственный Binder. Кажется а) сложным и б) даже невозможным. AFAICT вы получаете только DomEvents, которые сообщают Binder о необходимости проверки. С первого взгляда я не смог понять, как получить тип события и узнать, могло ли значение быть изменено.
• Реализуйте свои собственные веб-компоненты, не создавая событий проверки onblur. Кажется, много работы и очень неудобно для будущих обновлений и т. д.
• Не трогайте логику проверки, обрабатывайте желаемый вид только с помощью CSS. Настройте класс CSS, например, «noerror», добавив его для необходимых компонентов. Сделайте так, чтобы даже если есть ошибка, просто не показывать ее. После первого события ValueChangeListener удалите этот класс, и пусть компонент ведет себя как по умолчанию. Немного утомительно возиться с атрибутами CSS, возможно, потребуются корректировки при будущих изменениях. Однако это кажется наименее болезненным подходом.

Answer 3

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

В настоящее время мы рассматриваем предложение изменить поведение по умолчанию, чтобы поле проверялось на размытие только после того, как пользователь действительно взаимодействовал с ним, например, набрав что-нибудь. Для получения дальнейших обновлений перейдите по ссылке https://github.com/vaadin/web-comComponents/issues/6146.