Repository navigation
[scheduler] Honor viewConfig hour limits in the compact day and week views - #23316
Conversation
…views CompactDayView and CompactWeekView never read the store's time-grid config, so viewConfig.day / viewConfig.week silently did nothing on the touch views while DayView and WeekView honored them. Read the same selector and forward the range, and re-add the narrowed viewConfig prop the standalone types were omitting. CompactThreeDayView is left out: EventCalendarViewConfig has no threeDay key and the view has no non-compact counterpart, so which key it should read is an open API question.
Deploy previewBundle size
Check out the code infra dashboard for more information about this PR. |
rita-codes
added
type: enhancement
flaviendelangle
left a comment
flaviendelangle
left a comment
There was a problem hiding this comment.
PR review
No findings. This PR extends the existing viewConfig hour-limit support (already shipped for DayView/WeekView) to the compact day and week views, and it does so by mirroring the sibling views exactly — same timeGridConfig selector, same prop ordering, same Omit + narrowed re-declaration type shape (Pick<EventCalendarViewConfig, 'day' | 'week'>). Nothing is merge-blocking.
What I verified:
- Selector and null path:
eventCalendarViewSelectors.timeGridConfigreturnsstate.viewConfig?.[view] ?? null; theconfig?.startTimeoptional chaining handles the unset case, confirmed by the passing "24 rows by default" tests. - Prop spread reorder (
days={days}now before{...props}):CompactDayViewPropsextends onlyReact.HTMLAttributes, so no typed prop can collide withdays/startTime/endTime; the ordering is identical toDayView.tsx/WeekView.tsx. - Standalone flow:
viewConfigwas already extracted into store parameters byuseExtractEventCalendarParameters(used by both community and premium standalone wrappers), so the newly typed prop reaches the store in all four standalone components. - Runtime: all 348
x-schedulerunit tests pass in a worktree at the PR head, andpnpm --filter "@mui/x-scheduler*" run typescriptpasses for both touched packages. - Docs/generated files: compact views have no public docs page yet (only the experiments playground), and scheduler is outside proptypes/API-docs generation, so no stale or missing generated artifacts.
Residual gap, not actionable: the new tests exercise viewConfig through EventCalendarProvider rather than through the public StandaloneCompactDayView/StandaloneCompactWeekView prop, but that matches the coverage level of the sibling standalone views and the extraction hook is shared, pre-existing code.
Verdict
Approve - faithful replication of the proven DayView/WeekView pattern with passing tests and typecheck, and no behavioral deviations found.
🤖 Review generated with Claude Code
CompactDayViewandCompactWeekViewnever read the store's time-grid config, soviewConfig.day/viewConfig.weeksilently did nothing on the touch views whileDayViewandWeekViewhonored them. The props already existed and were forwarded all the way down (CompactDayTimeGridspreadsDayTimeGridPropsintoDayTimeGrid) — the views just never filled them in.Changes
CompactDayView/CompactWeekViewreadeventCalendarViewSelectors.timeGridConfigand forwardstartTime/endTime, mirroringDayView/WeekViewexactly.viewConfigthey were omitting, matchingStandaloneDayViewProps/StandaloneWeekViewProps.renderWithProvidershelper in each file with a provider-props argument instead of duplicating the JSX.Out of scope
CompactThreeDayViewis left as is:EventCalendarViewConfighas nothreeDaykey and the view has no non-compact counterpart, so which key it should read is an open API question rather than a bug fix.