coreui / coreui-pro / 34598394950

95%

main: 94%

push

github

feat(DateRangeInput): start and end date fields owning one range (#1245)

* feat(DateRangeInput): start and end date fields owning one range

A new field component: two DateInput fields and a separator inside one
`.form-control-group` frame, joined by the range the component owns.
`_applyRange()` is the only place the range changes — it writes both
fields, reads back what each kept after its own min/max validation,
and emits `startDateChange`, `endDateChange` and one `rangeChange` for
the ends that moved; a change reported by a field is not written back
to it. An end before the start is a state of the range, not of a field:
the frame gets `.is-invalid` and both fields stay editable.

The markup is the composition surface: `data-coreui-range-start`,
`data-coreui-range-separator` and `data-coreui-range-end` inside the
element are adopted (the separator and its SVG marked `aria-hidden`);
a missing part is generated, so `<div data-coreui-date-range-input>`
works on its own. Each end is named for assistive technology
(`ariaStartLabel` / `ariaEndLabel`, or its floating label) and can carry
its own hidden input (`startName` / `endName`). dispose() removes only
what the component built.

Registered in the ESM and UMD entrypoints, documented on
forms/date-range-input with a sidebar entry. DateRangePicker keeps its
own two fields for now; moving it onto this component is the next step
of the composition plan.

* chore: raise the JS bundle ceilings for DateRangeInput

`coreui.bundle.min.js` and `coreui.esm.min.js` crossed their budgets by
20 and 210 bytes (gzip) with the new component. Raised to 96.5 KB and
99.5 KB; the size pass at the end of v6 gets this trail.

* fix(DateRangeInput): natural field widths and arrows across the separator

The frame's `.form-control` rule let each date field grow into half the
width, so the arrow sat in the middle of an otherwise empty frame. Under
`.form-date-range` the fields (and their floating wrappers) keep their
natural wi... (continued)

5571 of 6219 branches covered (89.58%)

Branch coverage included in aggregate %.

175 of 183 new or added lines in 6 files covered. (95.63%)

10826 of 11231 relevant lines covered (96.39%)

455.38 hits per line