coreui / coreui-pro / 38252874155

96%

main: 94%

push

github

fix(DateInput, pickers): report the value before the error, and let the pickers relay the field (#1617)

A field announced a new validation error before it committed the value,
so an `errorChange` listener that set a date ran in the middle of the
update. DateInput ended with the listener's date on screen and `null`
from `getDate()`, DatePicker dropped a `setDate()` made from that
listener, TimePicker applied it and then reported `null` over it, and
DateRangeInput finished with the range it had started from.

The field now commits its whole state first: sections, hidden value,
validity and the value `getDate()` returns. Only then does it fire the
`input` and `change` of its hidden field, `dateChange` (`timeChange`)
and `errorChange`, each compared with the last one it reported. A write
made from any of these listeners leaves the field on that write's value,
and the update it interrupted reports nothing the write has already
reported.

DatePicker, TimePicker and DateRangeInput no longer keep a copy of the
value: `getDate()`, `getTime()`, `getStartDate()` and `getEndDate()` read
the fields, and return `null` while the fields are still being built.
The pickers relay each change of the field to the calendar, the time
panel and their own change event, which therefore fires before the
field's `errorChange` from the keyboard, the panel or a method alike.
The `_applying` guards, which dropped any write made from a listener, are
gone. The calendar is moved only when it shows another date than the
field, so a pick does not turn its page while a date a listener writes
during the pick still reaches it. The time panel is not written back
while it reports a change, so a refused pick stays there. A method that
leaves the value as it was shows it again in the calendar and the time
panel.

DateRangeInput writes both ends before either range event, holds the
fields' `errorChange` until the range events are out, and reports each
end against the last value it reported for... (continued)

7765 of 8352 branches covered (92.97%)

Branch coverage included in aggregate %.

118 of 118 new or added lines in 5 files covered. (100.0%)

13366 of 13660 relevant lines covered (97.85%)

1695.51 hits per line