[scheduler] Highlight only the edited occurrence of a recurring event#22873
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
@rita-codes Could you please review this PR when you have a chance? Thanks! |
Deploy previewBundle size
Check out the code infra dashboard for more information about this PR. |
|
@rita-codes BeforeReact.Scheduler.component.-.MUI.X.-.Google.Chrome.2026-06-18.02-46-02.mp4AfterReact.Scheduler.component.-.MUI.X.-.Google.Chrome.2026-06-18.02-55-56.mp4 |
rita-codes
added
type: bug
rita-codes
left a comment
rita-codes
left a comment
There was a problem hiding this comment.
Nice fix 👏 Keying the highlight on occurrence.key instead of the shared base id is the right call, and the rename is consistent across all the real consumers/
Two minor, non-blocking notes:
- EventTimelinePremium.test.tsx — the regression test asserts exactly one chip has data-editing, but not that it's the one that was clicked. With a single match it's almost certainly correct, but asserting the identity would guard against a future "highlights the wrong occurrence" bug.
- EventDialog.test.tsx — the renamed "should expose the active occurrence key on the store" test is a more honest name than the old one, but neither version actually exercises the clear-on-close path (
onClose→setEditedOccurrenceKey(null)). That's a pre-existing gap, not something this PR introduces, just flagging it since the close handler is part of this surface.
Neither is a blocker for this PR, though.
Thank you so much for taking care of this! 🙇♀️ 🥇
|
Thank you so much, @rita-codes! 🙏 I really appreciate the thoughtful review, both suggestions made the tests meaningfully stronger. I have addressed them in the follow-up commit. Thanks again for catching these, and for the kind words. 🙌 |
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
…mui#22873) Co-authored-by: Rita <[email protected]> Co-authored-by: Rita Iglesias Gandara <[email protected]> Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
2 participants
Closes #22839
Summary
When an event's edit dialog is open, its chip gets the
data-editing"editing" surface color. For a recurring event, opening the dialog on a single occurrence highlighted every occurrence of the series across the grid instead of only the one that was clicked.Root cause
The "editing" highlight was keyed by the event
id. All occurrences of a recurring event share the same baseid, so the equality check in theisEditedEventselector matched every occurrence at once. Each occurrence already carries a unique, stableoccurrence.key(${eventId}::${dateKey}for recurring occurrences,String(eventId)for single events), which is what should identify the active occurrence.Changes
The edit highlight is now keyed on the occurrence
keyinstead of the eventid, consistently across every consumer:editedEventIdstate andsetEditedEventIdare noweditedOccurrenceKey/setEditedOccurrenceKey(typedstring | null).isEditedEventis nowisEditedOccurrenceand compares occurrence keys.useEventtakes anoccurrenceKeyparameter;useDraggableEventpasses theoccurrenceKeyit already receives.EventItemand theEventDialogopen/close handlers now useoccurrence.key.This keeps single (non-recurring) events working unchanged, since their occurrence key equals their stringified id, while distinguishing the individual occurrences of a recurring series.
Testing
pnpm --filter "@mui/x-scheduler" run typescript,pnpm eslint, andpnpm test:unit --project "x-scheduler*" --runall pass (1633 unit tests).Steps to reproduce
Recurring events are expanded into multiple occurrences only when the premium recurring plugin is attached, so use a premium component:
EventCalendarPremium(orEventTimelinePremium) with a daily recurring event over a multi-day view.Changelog
Fixed an issue in the Scheduler where editing one occurrence of a recurring event highlighted all of its occurrences instead of only the edited one.