feat(date-picker): add unparsable-change event

[vursen]

Description

The PR introduces a new event unparsable-change to date-picker. This event is fired when the user attempts to commit or clear input that the component has failed to parse as a date. This event is intended as a supplement to the change event, which means it will be fired only when there is no change event.

Here is a table that illustrates which event is fired based on the nature of the value change:

Value change	Event	Note
empty => parsable	change
empty => unparsable	unparsable-change
parsable => empty	change
parsable => parsable	change
parsable => unparsable	change	The value property changes to an empty string
unparsable => empty	unparsable-change
unparsable => parsable	change	The value property changes to a non-empty string
unparsable => unparsable	unparsable-change

The PR also prevents date-picker from validating on Enter if the input hasn't changed (related to #6591).

Part of vaadin/flow-components#5537

Type of change

• Feature

[knoobie]

Would it make sense to pass the unparseable value to event to allow handling with flow? This would reduce the need for additionals calls to __committedUnparsableValue or syncing it with the server for better (?) performance.

[vursen]

Yeah, we've considered this option too, but in that case we will need to pass it also with the change event. Note, the component fires change rather than unparsable-change when the user changes parsable input to unparsable and vice versa. So, ultimately, we come to the same outcome as with property synchronization in Flow. Both approaches seem to offer relatively similar performance: all the data is sent within a single round-trip – which is triggered by change or unparsable-change. Property synchronization appears to be more preferable, as it doesn't require changing the API of the change event.

[knoobie]

Understandable, but wouldn't that be a good change anyway? This would align the change event also to the change event from the normal inputs where you can access the value https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event

[vursen]

This would align the change event also to the change event from the normal inputs where you can access the value

Just to make sure we understand each other, did you mean passing the input value via event.detail or some other way? I'm not sure if the native change event does it this way. The native event provides access to the target element through which you can access the value, yes.

[knoobie]

You are right, dismiss my comment 😬 it's done by accessing the event.target.value instead of details

[vursen]

note: Now that the validation is the responsibility of the commit logic, we no longer need to trigger validation here, which fixes #6591.

[vursen]

note: This line is unnecessary since the selected date is already updated by __commitDate(null).

[vursen]

note: The validation can now be triggered twice on blur or outside click when it coincides with change. I considered that it's something that can be optimized later since (1) the Flow components will no longer rely on client-side validation timing (2) validate() calls themselves are pretty cheap in web-components.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

No Coverage information
0.0% Duplication

[vaadin-bot]

This ticket/PR has been released with Vaadin 24.3.0.