coreui / coreui-pro / 34829961392

94%

push

github

fix(Calendar): honour disabledDates for whole periods, survive a click on a week row (#1283)

Four defects from the pre-alpha audit, each measured before and after.

`isMonthDisabled`, `isQuarterDisabled` and `isYearDisabled` walked every day of
the period, checked each one, then discarded the answer and returned `false`.
`disabledDates` therefore never disabled a month, quarter or year cell, and the
scan was paid for nothing. Two of them also scanned the wrong window — from the
given date to the end of the *current* calendar year rather than to the end of
the period. The three now share `isPeriodDisabled`, which takes the period's own
bounds and returns `true` when every day in it is disabled.

The `min`/`max` path was always correct and is untouched; it is what greys out
cells in the ordinary case, which is why this went unnoticed.

In week selection the row is what takes the interaction, so `_handleCalendarClick`
and `_handleCalendarMouseEnter` received an event with no `.calendar-cell` above
it, read `closest` off the resulting `null` and threw. Both now resolve the
target through `_getEventTarget`, which falls back to the row, and bail out if
there is neither.

The row's `range-hover` class was computed with `isYearInRange` while the row's
`range` class beside it used `isDateInRange`. Hovering to pick the end of a week
range therefore highlighted every row in the same year, including rows before the
range even starts. It reads dates now, like its neighbour.

`buildDateRegexPattern` escaped the format's separators with a character class
that closed one bracket early: `[.*+?^${}()|[\\]\\]` ends at the `]` after the
backslash, so the pattern demanded a special character *followed by* a literal
`]` and matched almost nothing. Separators went into the expression unescaped,
and `12X31X2022` parsed as a date. Fixed to the same class the file already uses
correctly a few lines above.

Tests: six new cases, all verified red beforehand, plus three controls... (continued)

3969 of 4388 branches covered (90.45%)

Branch coverage included in aggregate %.

20 of 22 new or added lines in 2 files covered. (90.91%)

7319 of 7603 relevant lines covered (96.26%)

694.64 hits per line