-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[DataGrid] Lower filter debounce delay #9712
Conversation
Netlify deploy previewNetlify deploy preview: https://deploy-preview-9712--material-ui-x.netlify.app/ Updated pagesNo updates. These are the results for the performance tests:
|
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.
Thanks, @romgrk!
Quick filter feels much better with lower debounce 👍
packages/grid/x-data-grid/src/components/panel/filterPanel/GridFilterInputValue.tsx
Show resolved
Hide resolved
packages/grid/x-data-grid/src/components/panel/filterPanel/GridFilterPanel.tsx
Show resolved
Hide resolved
React.useEffect(() => { | ||
const itemValue = item.value ?? ''; | ||
setFilterValueState(String(itemValue)); | ||
}, [item.value]); |
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 believe this effect was covering the use case with a controlled filter model, where the filter model could change while the user has the filter panel open.
Without this effect, the filter input will be out of sync with the actual filter model:
With effect: https://codesandbox.io/s/gracious-khayyam-2xqw3n?file=/demo.tsx
Without effect: https://codesandbox.io/s/dreamy-glitter-h8h4yj?file=/demo.tsx
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've adapted the effect to respond to the model changes specifically, what do you think?
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'll apply to the other equivalent components if it LGTY.
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 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.
Ooh good catch, there's so many parts to this thing ^^
I've pushed a fix for that.
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.
Thanks, works as expected now!
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.
@romgrk It had another aspect which I missed catching 😄
Since the rendering of GridFilterInputValue
is being done from GridHeaderFilterCell
, the item change is incorrectly reflected.
I am thinking of disabling this optimization (fromInput
) for the headerFilters, let me know if you have better ideas.
packages/grid/x-data-grid/src/components/panel/filterPanel/GridFilterPanel.tsx
Show resolved
Hide resolved
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
packages/grid/x-data-grid/src/components/panel/filterPanel/GridFilterInputValue.tsx
Outdated
Show resolved
Hide resolved
packages/grid/x-data-grid/src/components/panel/filterPanel/GridFilterPanel.tsx
Show resolved
Hide resolved
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.
LGTM, the filter response for both the quick filter and normal filter is almost instant now.
Feels much faster 🚀
Nice, this feels more responsive. Can we create a new issue for the rest of #9657? The input lags behind now, similar to #9657 (comment). I imagine it why we can't use 50ms, and we have to stick to 150ms for now, and why we are using a debounce rather than a throttle. Or we could reopen it, as this PR gets us one step closer to do better than AG Grid. |
if (this.currentId !== 0) { | ||
clearTimeout(this.currentId); | ||
this.currentId = 0; | ||
} |
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.
Would it be equality fast but less JavaScript code with?
if (this.currentId !== 0) { | |
clearTimeout(this.currentId); | |
this.currentId = 0; | |
} | |
clearTimeout(this.currentId); |
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.
It's a small cost but in some places it matters.
Details here: mui/material-ui#37512
I have a few of these utils that should be migrated to core at some point.
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.
It's a small cost but in some places it matters. Details here: mui/material-ui#37512
quasarframework/quasar#15203 seem to have faced something similar. Fair enough.
I have a few of these utils that should be migrated to core at some point.
useLazyRef
: it could be great to comment on it to link Lazy useRef instance variables facebook/react#14490 I guess it's why it's here. Preferred when doing something a bit heavy to initialize the ref. Done in b9018a4useTimeout
: yeah, I see how this could be used in quite more places in Core.
if (this.currentId !== 0) { | ||
clearTimeout(this.currentId); | ||
this.currentId = 0; | ||
} |
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.
It's a small cost but in some places it matters. Details here: mui/material-ui#37512
quasarframework/quasar#15203 seem to have faced something similar. Fair enough.
I have a few of these utils that should be migrated to core at some point.
useLazyRef
: it could be great to comment on it to link Lazy useRef instance variables facebook/react#14490 I guess it's why it's here. Preferred when doing something a bit heavy to initialize the ref. Done in b9018a4useTimeout
: yeah, I see how this could be used in quite more places in Core.
export function useTimeout() { | ||
const timeout = useLazyRef(Timeout.create).current; | ||
|
||
useOnMount(timeout.disposeEffect); |
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.
Why not?
useOnMount(timeout.disposeEffect); | |
React.useEffect(timeout.disposeEffect, []); |
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.
useOnMount
has a clear semantic. It also doesn't re-allocate the []
object on every render, so less work for the GC. Very small cost again, but these add up and end up creating more frequent and longer GC pauses if we allocate objects for no reason.
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 a bit worried that it's not a problem worth an abstraction (1. It could be hard for team members to learn to use it. 2. When reviewing the code, it's someone new reviewers need to learn 3. I wouldn't be surprised if it will be missed, and even once known, the old habits will persist).
But I won't push against it, why not give it a try 👍
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.
We had that discussion when I added useOnMount
in some older PR, but since I've seen other members of the team adopt it, so I think it's beneficial. React hooks are a bit raw, having a small set of primitives added on top of them isn't a bad idea, imho.
A follow-up on #9712 (comment).
Closes #9657
Closes #9157
Turn
SUBMIT_FILTER_STROKE_TIME
into a prop and lower it to 50ms by default, and lower the QF equivalent.