-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[data grid] Avoid subscribing to renderContext
state in grid root for better scroll performance
#15986
Merged
MBilalShafi
merged 15 commits into
mui:master
from
lauri865:fix-rowspanning-performance
Dec 26, 2024
Merged
[data grid] Avoid subscribing to renderContext
state in grid root for better scroll performance
#15986
Changes from all commits
Commits
Show all changes
15 commits
Select commit
Hold shift + click to select a range
c9386b5
avoid `renderContext` selector hooks in root + better isolation for `…
lauri865 baea9b1
prettier
lauri865 1137212
fix row spanning with pagination
lauri865 703a7e6
add events for sorting and filtering for rowSpanning
lauri865 8b09405
fix reactivity
lauri865 e91ffbc
fix prop
lauri865 6fa1476
missing dep
lauri865 27b8270
cleanup
lauri865 1c3ba1d
Merge branch 'master' into fix-rowspanning-performance
lauri865 cb3cc3d
refactor rowspanning logic
lauri865 ec53717
remove unused import
lauri865 ee331f9
fix test
lauri865 f164dd4
ci
lauri865 de625c0
Merge branch 'master' into fix-rowspanning-performance
lauri865 401f0fa
fixes
lauri865 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of change is dangerous in my opinion. If we mix state from
useGridSelector
with state from theapiRef
directly, we are mixing state from different render/update cycles. We should not use this pattern to fix performance issues.If we need to fix re-render issues, we should specialize selectors. For example, the selector could be targetted for
renderContext.lastRowIndex
specifically instead of the wholerenderContext
object, that would prevent re-renders while avoiding bugs.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's another PR I opened that takes care of the other useGridSelectors as well, which to me is the correct solution here. For reasons I described in the other PR. #16001
Plus using useGridSelectors in non-rendering hooks makes you write state syncing logic declaratively, which leads to useEffects calling useCallbacks whenever useCallback deps change and other spaghetti that's difficult to debug/trace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to removing code if we can prove that it won't introduce bugs, but mixing state from different update cycles is pretty important to avoid. For example, if part of the state comes from before a filter has been applied, and another part of the state comes from the latest
apiRef.current.state
after a filter has been applied, we'd be using state slices that aren't coherent with each other.Using
apiRef
directly consistently would avoid the issue, though I'd be curious to see how reactive bindings are working.I'm still catching up with notifications I missed during the holidays but I'll review #16001 in the next days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completely agree, but you're more likely to do that with by accident with using
useGridSelector
on root level than not (=mixing stale state from rendering phase with up-to-date state from events/apiRef methods that themselves can hide a state selector in their implementation). Direct state selectors are more commonplace in the code base as it stands today – either directly or indirectly throughapiRef
methods. UsinguseGridSelector
-s on root-level seems to be a more recent trend in the code base.Compare the before and after of
useGridRowSpanning
hook. In which implementation can you answer the question more clearly – under what conditions is the row spanning state reset?I'm not trying to throw shade to anyone's code in particular. This is not an isolated example, and I could have easily written the same thing myself if I just started out from using
useGridSelector
instead hooking into the existing events. It's inevitable if you mix two paradigms, you end up writing duct tape to keep them in sync. That duct tape in React isuseEffect
, which becomes an implicit event that is run under certain conditions. Under which exactly can become quite difficult to understand the more direct and indirect dependencies we end up having, and the less isolated the code is to a particular component.If you take a step back – no hook in the
useDataGridComponent
tree is directly responsible for rendering anything – they are not an explicit part of a rendering cycle of any particular component. However, the use ofuseGridSelector
forces those into a declarative paradigm from the outset, while actually serving an imperative function in the context of the data grid.Just to be clear, even if the motivation around this PR was to take care of a performance regression, the rationale around the other PR (#16001) is not performance per se, it's not me pushing my idea(s/ologies), it's not removing code. But it is to suggest a convention that enables writing more isolated features and easier to follow logic within those features – a foundation that would have prevented this regression in the first place. And it's a pretty simple one.
useGridSelector
GridRow
,GridCell
,GridBody
, etc.)useGridSelector
on root level is as a direct dependency of auseEffect
, however that's seldom done and necessary, and usually a sign of a missing explicit event asuseEffect
itself will become that event implicitly, but may be invoked much more frequently than necessary.FWIW, it doesn't seem to be a new convention either from my understanding of the code base. The older versions of the code base either explicitly or implicitly followed this very convention, at least to a much higher degree. Breaking seems to be a more recent trend.
Open to be proven wrong as always – show me an example where
useGridSelector
in the affected code is provably necessary. I will do my best to showcase why that may actually not be the case, and come up with an alternative on my end.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your points make a lot of sense. The reactivity architecture via
useGridSelector()
has mostly been my effort, following the point #1 of this discussion, and I initially established the guideline of "always useuseGridSelector
" as a way to provide a simple & clear rule for the rest of the team to follow. This in particular allows to easily refactor code between components & root-level hooks, which I've been doing a lot for the somewhat recent performance improvements.Yes that's a major source of bugs and it's been on my radar for some time. Our state management goes through various cycles of updates/renders before settling on a coherent state because we use the async
useEffect
to sync up parts of the state, whereas we should be using something that can synchronously settle on a valid state. For example, if therows
prop is updated, there are various rounds of (async) updates before the filtered, sorted, and grouped rows slices of state are updated to match the newrows
prop.I'm not sure yet what's the best way to solve the issue. Going all in into selectors could be a solution, because selectors can lazily sync with the latest state value, though they keep their state in a memoized memory cell that doesn't live on the
state
object so that's less debuggable. Alternatively, we could create some event-based system that updates the state synchronously when another part of the state changes, this would not be lazy but it would be more debuggable.I'm ok with that convention but it places a burden on the maintainers to be strict about observing those invariants, whereas creating specialized selectors would provide correctness without having to think about the context before using state data. Let me ping the team to see what's the consensus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice discussion points. A couple of cents from my side.
Yes, this should be avoided as much as possible, I supported the change in #15986 specific to the
renderContext
as this particular state update is a bit unusual, I suspected the performance lag in Safari is due to wrapping of the state update inReactDOM.flushSync
, extracting the value in the event listener seemed like a proper reactive handle for this case. Also supported by the fact that yielded a better scroll performance. The testing I did didn't exhibit any regressions so I moved forward to merge, we could revert if we find one.An alternate approach for this event (
handleScrolling
) could be to either extract the other state (dimensions
) in the function too or use the argument (params.renderContext
) passed to the event handler. 1 would avoid mixing ofuseGridSelector
andapiRef
slices, while 2 would remove state out-of-sync without extracting the selector slice. (But only for this instance, we'd need to do similar things for other (useGridRowSpanning
)).If we manage to make that happen cleanly, it'll definitely make it harder for inactive features to impact the performance or unnecessarily re-render/re-compute some parts of the application, improving the overall performance, however, I'd be careful to avoid breaking an expected reactivity with this change.
I assume there are some use cases where it's inevitable to avoid
useGridSelector
in root hooks, like when they are used asuseEffect
dependencies. We'd need to provide an escape hatch to make that happen.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the first question to ask if the event is missing is whether a new event should be added. If a state change triggers another piece of state to change as a side-effect,
useEffect/useLayoutEffect
are always worse options to write that logic in React than an event, as things will now happen in different render passes.useEffect
is an escape hatch from declarative rendering paradigm in react. In theory, the only appropriate use foruseEffect
in feature hooks (in relation to the internal state management) should be to sync props with the internal state. Of course there are other appropriate cases like subscribing to DOM events, etc.I didn't see any obvious examples where I thought
useGridSelector
would be necessary in feature hooks, outside ofuseGridDimensions
anduseGridRowsMeta
(although that could be fixed with more work as well, but since it's a core hook rather than feature hook, it's less of a concern to me; readability is much worse though withuseGridSelector
).I'm curious to see if you have any examples though that would prove the inverse. The only theoretical case for
useGridSelector
I can think of – an event that mutates internal state needs to access the rendered value of the state (=old state). The only other case I can think of is that a feature hook needs to send the grid to re-render when no component depends on that state – but that smells of side-effects, and likely has a much nicer solution. If such cases would exist, they would likely be broken by react compiler in the future as well. But I haven't found any such cases yet, and this change would have highlighted them as well:#15666 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, almost forgot. An alternative escape hatch to
useGridSelector/useEffect
could beuseGridSelectorChange
. Instead of creating/updating state, it would call a callback if the resulting selector value changes.But I haven't seen a place where I would use it yet, except for
useGridDimensions
/useGridRowsMeta
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, the old state = the current state (before the new one is applied), so a regular selector should work here. Does this make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant a case, e.g.:
onKeyDown
DOM event firesfocusCell
state is changed (but updated state is not rendered until the next keyframe)onCellKeyDown
internal event is firedonCellKeyDown
consumer in a feature hook (=different hook than the one that manages focus state) needs to know the currently renderedfocusCell
It's all purely theoretical though – I was just stretching my imagination to come up with a case where
useGridSelector
would be a necessary choice over straight selectors in callbacks (as I proposed), and hence tried to poke holes in my other PR. For avoidance of doubt, I haven't seen any practical example in the code where this is an actual use case.