Open vursen opened 2 weeks ago
After discussing this issue, we reached a consensus that pattern
makes too little sense for both ComboBox and MultiSelectComboBox. While these fields resemble classic text fields, they are different because their values are typically beans rather than strings. This means that pattern can only validate the string representation of these values, which seems to be rather niche and not worth being supported out of the box. Therefore, our decision is to deprecate the pattern constraint in these components in both their versions: WC and Flow.
Based on the git history, the pattern
property was initially just propagated to the underlying vaadin-text-field
since https://github.com/vaadin/vaadin-combo-box/pull/557. Before switching to vaadin-text-field
, the iron-input
and allowedPattern
was used (which worked like our allowedCharPattern
, which is now supported by all input controls including vaadin-combo-box
).
BTW the vaadin-multi-select-combo-box
doesn't even use pattern
property and I think it doesn't need it.
Description
Although
setPattern
is available in ComboBox, it only sets the related attribute and doesn't affect validation. This contrasts with the web component where the pattern is actually checked during validation. Without validation, the purpose of the pattern is unclear.Expected outcome
ComboBox should invalidate if the custom value doesn't match the pattern, same as it works in the web component.
Minimal reproducible example
Environment
Vaadin version(s): 24.5 and earlier OS: Mac OS
Browsers
No response