coreui / coreui-pro / 35908868252

95%

main: 94%

Build Type

push

github

Committed by web-flow

Commit Message

fix(DatePicker, DateRangePicker): keep working after a rejected call, emit calendar picks only on change (#1400)

* fix(DatePicker, DateRangeInput): release the apply guard when the field throws

`_applyDate` and `_applyRange` raise a flag while they write the field,
so the field's own change event does not re-enter them, and lowered it
only on the way out. A call the field rejects with a TypeError, such as
`setDate(undefined)` or `setRange(undefined, null)`, left the flag
raised for good: every later `setDate()`/`setRange()` returned at the
guard and every typed date was ignored, with no event and no error.

The flag now drops in `finally`, so the failing call still throws and
the component keeps working after it. The DatePicker methods table also
says `setDate` emits only when the value changes, which it already did.

* fix(DateRangePicker): emit a calendar pick only when the end it sets changes

A pick in the calendar always emitted `startDateChange` or
`endDateChange`, also when the field ended up holding what it held
before: clicking the start that was already selected, or a pick the
field refused while that end was already empty (null to null). Typing
and `setRange()` already emitted only on a change, so the three paths
disagreed.

The calendar handlers now compare the end's value before and after the
field takes the pick and emit only when it changed. The events table
already promised "when the start changes"; the methods table now says
`setRange` emits the event of each end that changes.

* fix(DatePicker, DateRangeInput): check both range ends before writing, compare dates by instant

`setRange(start)` without an end wrote the start field, then threw on the
end, leaving the start field showing a date the range did not hold: no
event fired and a later end edit reported the stale start. `setRange`
now type-checks both ends before writing either, so a bad call changes
nothing; the guard in `_applyRange` goes back to lowering its flag after
the r... (continued)

Coverage Stats

6015 of 6633 branches covered (90.68%)

Branch coverage included in aggregate %.

17 of 17 new or added lines in 3 files covered. (100.0%)

1 existing line in 1 file now uncovered.

11120 of 11506 relevant lines covered (96.65%)

615.5 hits per line