coreui / coreui-pro / 35903802942

95%

main: 94%

push

github

fix(TimePicker): emit timeChange once, with the time the field holds (#1399)

* fix(TimePicker): emit timeChange once, with the time the field holds

`setTime()` (and `now()`/`reset()` through it) set the field, whose
`timeChange` bridge already emitted the picker's `timeChange`, and then
emitted it again with the raw argument: after `reset()` the second
payload was the unconverted config string, and with seconds off it kept
the seconds the field drops. The panel path emitted once, but also when
the value did not change, and with the time the panel reported rather
than the one the field accepted.

Every path now goes through `_applyTime`, shaped like DatePicker's
`_applyDate`: it writes the field unless the field reported the change
itself, reads the value the field accepted, moves the panel only when
its time differs from that value, and emits after that state has
settled, only when the value changed. The payload therefore equals
`getTime()`, a `setTime()` with the current value is silent and leaves
an open panel and its focus alone, and a listener that sets another
time during the event leaves the panel on that time.

When the field refuses a panel pick the event reports `null` and the
panel keeps the pick, as before, so the next click builds on it instead
of starting from midnight. `clear()` goes through the field's own clear,
so focus stays in the field, and a listener that clears the field from
`errorChange` still reaches the picker. The guard that keeps the field
bridge from re-entering is a counter released in `finally`, so a
`setTime()` that throws on a bad argument does not silence later typing.

The methods and events tables say so. React and Vue still emit on every
call with the raw value; aligning them is a separate change.

* build: raise the minified JS budgets by 1 KB

The TimePicker change in this branch routes every value change through one
`_applyTime` and adds 122 B gzip to coreui.min.js and 116 B to
coreui.esm.min.js and coreui.bun... (continued)

6017 of 6635 branches covered (90.69%)

Branch coverage included in aggregate %.

21 of 21 new or added lines in 1 file covered. (100.0%)

11114 of 11499 relevant lines covered (96.65%)

603.97 hits per line