fix(calendar): keep keyboard navigation alive after picking a date - #90
Merged
Conversation
The four `components` overrides were arrow functions written inside `Calendar`'s render, which is where shadcn's generator puts them. That makes them a new component type on every pass, and DayPicker keys its subtree on those identities: any re-render unmounted and remounted the whole grid instead of updating it. `CalendarDayButton` holds a ref and an effect that focuses the day matching `modifiers.focused`, so the remount threw away the focus that effect had just placed. Selecting a start date re-renders the range picker, which meant that after the first click the arrow keys did nothing at all. Confirmed against a running dashboard — click Aug 2, press Right twice, and the focus ring stays on 2. With the components hoisted it moves to 4, which is what it always should have done. Hoisting three of them is a straight move; they closed over nothing. The DayButton wrapper existed only to inject `locale`, so it now reads the same value back out of DayPicker's own context instead of closing over `Calendar`'s prop. This also clears the ten oxlint warnings the file was emitting on every CI run, four no-unstable-nested-components and six no-shadow, but those were the symptom rather than the reason.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Started as "silence the ten oxlint warnings in
calendar.tsx". Turned outthey were pointing at a real bug.
The bug
The four
componentsoverrides were arrow functions written insideCalendar's render, which is where shadcn's generator puts them. That makesthem a new component type on every render, and DayPicker keys its subtree
on those identities — so any re-render unmounted and remounted the entire grid
rather than updating it.
CalendarDayButtonholds a ref and an effect that focuses the day matchingmodifiers.focused. The remount threw away the focus that effect had justplaced. Since selecting a start date re-renders the range picker, the arrow
keys stopped working after the first click.
Verified in a browser, both ways
Same steps against a running dashboard — open Custom, click Aug 2, press Right
twice:
mainThe fix
Root,ChevronandWeekNumberclosed over nothing, so hoisting them tomodule scope is a straight move.
DayButtonexisted only to injectlocale,so it now reads the same value back out of DayPicker's own context
(
useDayPicker().dayPickerProps.locale) rather than closing overCalendar'sprop — identical value, since
Calendaris what passes it toDayPickerinthe first place.
Also
Clears the ten warnings the file emitted on every CI run — four
no-unstable-nested-components, sixno-shadow. They were the symptom.pnpm lint,pnpm typecheck,pnpm format:checkclean; 626 tests pass. Noneof the suites cover this component, which is why it was checked by hand.