Repository navigation
[scheduler] Return a primitive key from the Calendar lazy-loading selector - #22791
Merged
rita-codes merged 6 commits intoJun 16, 2026
Merged
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Deploy previewhttps://deploy-preview-22791--material-ui-x.netlify.app/ Bundle size
Check out the code infra dashboard for more information about this PR. |
github-actions
Bot
added
the
PR: out-of-date
Contributor
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Anexus5919
force-pushed
the
fix/calendar-lazy-loading-primitive-key
branch
from
June 13, 2026 09:33
4a07264 to
ef509bd
Compare
github-actions
Bot
removed
the
PR: out-of-date
Contributor
Author
Resolved. |
Contributor
Author
|
@rita-codes @zannager Kindly have a review on this pr. Thanks! |
rita-codes
added
the
type: enhancement
rita-codes
approved these changes
Jun 16, 2026
rita-codes
left a comment
rita-codes
left a comment
Member
There was a problem hiding this comment.
Looks good to me! Thanks for taking care of this 🙇♀️
mbrookes
pushed a commit
to mbrookes/mui-x
that referenced
this pull request
Jun 27, 2026
…ector (mui#22791) Co-authored-by: Rita <47579513+rita-codes@users.noreply.github.com>
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
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.
Closes #22763
Summary
The premium Calendar lazy-loading plugin's store-effect selector returned a fresh object literal on every call. Because
SchedulerStore.registerStoreEffectcompares selector results with reference equality (!==), a brand new object is never equal to the previous one, so the effect callback ran on every store notification (selection, hover, drag-placeholder moves), not just when the visible day range changed.It was never a fetch storm, since the effect guarded internally on
visibleDaysKey, but it churned work on a hot path: during a drag the store updates on every pointer move, so each frame rebuilt the joined key string, allocated a new object, and re-invoked the effect (which itself recomputedvisibleDaysSelectora second time). The Timeline plugin already does this correctly by returning a primitive string.Changes
The selector now returns a primitive, mirroring the Timeline plugin:
nullwhen no view is registered or there are no visible days.visibleDaysKeystring.With a primitive return value,
!==compares by value, so the effect only runs when the range actually changes. The unusedisLoadingfield is dropped from the selected value.Behavior preserved
visibleDays.length === 0guard is kept asnextKey === null, so a view unmount (viewConfigresets tonull) cannot schedule a fetch that would read an empty day list and throw ondays[0].value.previous.viewConfig == nullinstant-load flag becomespreviousKey === null, which is true exactly when no view was registered before (construction or after unmount). This requires returningnullrather than an empty string for the empty case, otherwise'' === nullwould be false and the first load would silently fall back to the debounced path.A note on the issue's secondary claim
The issue also suggested this fixes a case where the Calendar's first lazy-load "goes through the debounce instead of loading immediately." I could not reproduce that on
master:viewConfigisnullat construction, soprevious.viewConfig == nullis already true on the first real transition and the initial load is already instant. I verified this with a throwaway test before making any change. This PR therefore preserves the existing instant load rather than fixing a pre-existing bug, and adds a regression test so the instant load stays protected.Testing
x-scheduler-internals-premiumsuite passes (444/444),tscclean, eslint and prettier clean.Changelog
Reduced wasted work on a hot path in the premium Event Calendar lazy loading: the lazy-loading effect no longer re-runs on unrelated store updates (selection, hover, drag), only when the visible date range changes.