fix(calendar): calendar day selection and month navigation not updating - #421
Open
shakurt wants to merge 4 commits into
Open
fix(calendar): calendar day selection and month navigation not updating#421shakurt wants to merge 4 commits into
shakurt wants to merge 4 commits into
Conversation
… clicks ClickableTooltip attached its own native capture-phase click listener (with stopPropagation) directly on the trigger element to toggle open state. In the calendar, DayItem already has its own onClick that opens the tooltip explicitly, so the two handlers raced and the native listener could swallow the day cell's React onClick after the first click. Added a toggleOnTriggerClick opt-out and disabled it for the calendar's usage, and pass selectedDate into CalendarDayDetails as an explicit prop instead of re-deriving it from context.
The calendar widget in widgetItems (used by the default/ADVANCED UI's ContentSection) rendered <CalendarLayout /> without a DateProvider ancestor, unlike the WIDGET_DEFINITIONS entry used by the custom canvas UI. Without the provider, every useDate() call fell back to a stub where setSelectedDate/setCurrentDate are no-ops and selectedDate/currentDate are recomputed to "now" on every render. That silently broke day selection and month navigation with no console errors, since the calendar was pinned to whatever "today" resolves to on each render.
goToToday, isToday and getHijriDate were recreated on every render, and the context value object was a fresh literal each time, so every consumer of useDate() re-rendered whenever DateProvider re-rendered for any reason, even when none of currentDate/selectedDate/today actually changed. Wrapped the callbacks in useCallback and the provided value in useMemo, keyed on their real dependencies.
…NITIONS widget-visibility.context.tsx is being phased out in favor of widget-registry.tsx, and duplicating the DateProvider wrap here was redundant with WIDGET_DEFINITIONS[calendar].node, which already wraps CalendarLayout correctly. Point the old registry's calendar entry at the new one instead of maintaining two copies of the same wiring.
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.
Problem
In the default UI, clicking a calendar day or the prev/next month buttons did nothing —
no re-render, no error, no network request. The popup always showed today's date/events
regardless of which day was clicked.
Root cause
The calendar widget in
widgetItems(used by the default/ADVANCED UI'sContentSection)rendered
<CalendarLayout />without aDateProviderancestor, unlike theWIDGET_DEFINITIONSentry used by the custom canvas UI. Without the provider, everyuseDate()call silently fell back to a stub wheresetSelectedDate/setCurrentDateare no-ops and
selectedDate/currentDateare recomputed to "now" on every render —so nothing the user clicked could ever change the displayed date.
Changes
DateProvider(the actual fix for the reported bug).
ClickableTooltipwas attaching its own native capture-phase clicklistener (with
stopPropagation) on the trigger element, racing withDayItem's ownonClick. Added atoggleOnTriggerClickopt-out and disabled it for the calendar, andpass
selectedDateintoCalendarDayDetailsas an explicit prop instead ofre-deriving it from context.
DateProvider's context value/callbacks so consumersdon't re-render on unrelated parent re-renders.
Testing
Manually verified in
bun dev: clicking different days updates the popup contentcorrectly, and prev/next/today navigation works.