coreui / coreui-pro / 35853906716

95%

main: 94%

push

github

fix(Calendar): move the arrow keys by date, not by list position (#1392)

* fix(Calendar): move the arrow keys by date, not by list position

The arrow keys stepped through the list of selectable cells, so the step
was counted in cells rather than days: a disabled day between the start
and the target moved the landing spot, two panels walked the arrows
through the boundary days both panels render, and ArrowDown in the single
row of quarters jumped from Q1 to Q4.

An arrow now computes the date one step away (a day or a week, a week for
week rows, a month or three, a quarter or a year, a year or three), keeps
stepping past dates that cannot be selected for up to ten years, stops at
minDate and maxDate, pages the view when no visible cell shows the target,
and focuses the target in its own month. ArrowLeft and ArrowRight follow
the reading direction in RTL. Every path reads a week row as the start of
its week, as the first render already did.

When no panel has a selectable date, each grid becomes the tab stop. The
arrows on it move to the nearest selectable date before or after the view,
PageUp and PageDown page the view and hand focus to the first stop they
bring into view, and Home/End no longer scroll the page. PageUp and
PageDown from a cell into such a month land on the grid. Every grid is
named after the period it shows.

Two defects surfaced on the way. A week row with no visible day, the sixth
row of a month when adjacent days are hidden, was selectable and made the
constructor throw; it is no longer selectable. Refreshing the cell classes
marked every selectable day as belonging to the current month, so with
selectAdjacentDays the adjacent days lost their styling on the first hover.

* build(bundlewatch): raise the JS budgets by 1 KB

Moving the calendar arrow keys by date adds 639 to 671 bytes to the
minified bundles and 806 to 826 bytes to the unminified ones (gzip -9,
measured against v6-dev), and the budgets had about 70 bytes left. The
re... (continued)

5970 of 6594 branches covered (90.54%)

Branch coverage included in aggregate %.

100 of 107 new or added lines in 1 file covered. (93.46%)

11124 of 11516 relevant lines covered (96.6%)

628.47 hits per line