-
-
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
[DataGrid] Fix header filters showing clear button while empty #15829
Conversation
Deploy preview: https://deploy-preview-15829--material-ui-x.netlify.app/ Updated pages: |
packages/x-data-grid/src/components/panel/filterPanel/GridFilterInputValue.tsx
Outdated
Show resolved
Hide resolved
@@ -62,17 +75,17 @@ function GridFilterInputValue(props: GridTypeFilterInputValueProps) { | |||
|
|||
React.useEffect(() => { | |||
const itemPlusTag = item as ItemPlusTag; | |||
if (itemPlusTag.fromInput !== id || item.value === undefined) { | |||
setFilterValueState(String(item.value ?? '')); | |||
if (itemPlusTag.fromInput !== id || item.value == null) { |
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.
using ==
to also consider null
values
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'd rather explicitly use x === null || x === undefined
rather than rely on the ==
operator, which I think we should not use in any situation.
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 for the review, but x == null
is only loosely equal to undefined
, no matter what is in item.value
. If it is not null
or undefined
, it always returns false. Or are there any other downsides of using ==
opertaor?
This makes another change that should not be there. |
92de0c8
to
4304555
Compare
@k-rajat19 thanks for the effort so far |
6d984a7
to
8363581
Compare
@@ -167,13 +167,9 @@ const GridHeaderFilterCell = React.forwardRef<HTMLDivElement, GridHeaderFilterCe | |||
|
|||
const applyFilterChanges = React.useCallback( | |||
(updatedItem: GridFilterItem) => { | |||
if (item.value && updatedItem.value === undefined) { |
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.
@mui/xgrid I have removed deletion of the filter item to avoid
#15829 (comment)
do you see any issue with this?
Question for @KenanYusuf
With this change, deleting the value with the keyboard keeps the operator, but clicking on the clear (X) button resets everything
Should this be aligned or it is fine like this?
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.
Should this be aligned or it is fine like this?
Definitely shouldn't reset the operator with keyboard deletion. I'm not certain it should reset upon clicking the clear button either... seems a little unexpected to me 🤔
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 have updated it for the clear button as well
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.
@mui/xgrid I have removed deletion of the filter item to avoid
#15829 (comment)do you see any issue with this?
Doing this changed the behavior of how the filter model updation works.
Here's the console.log
output for the arguments passed to onFilterModelChange
for the following actions.
- Add a filter
- Press the clear X button
Current version | Updated version (this PR) |
---|---|
Notice the filter item still being in the filterModel
, it is a breaking behavior. If we want to make this a default behavior, should we do it for other column types too? (date, singleSelect, etc.)
I'd prefer not to keep the item in the filterModel
which is cleared/doesn't have a valid value.
Wdyt?
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 for pointing it out
I assumed that the clear button was there in the first place to remove the item from the model.
The issue is that the end user does not know that this is the goal of it and sees an empty input with a clear button still present.
should we then preserve the operator in the UI only?
It can update if the filter item operator gets changed programatically
Otherwise, it will keep its last value and once you start typing again, it will add a new item with both value and the last operator
Wdyt?
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.
should we then preserve the operator in the UI only?
IMO, it comes down to the type of interaction the user did.
For removing text letter by letter with Backspace/Delete, the operator preserved makes sense.
However, upon clearing the filter completely (X button), I would expect the filter to be deleted (including the operator).
Consider an example interaction done by a user X.
He searches for names that start from 'John' (startsFrom
operator has a connection with the value)
If he made a typo, he'd backspace and retype, but if the search has been completed and another search has to be done, he'd clear the filter (X button) intending to remove the operator too.
The next filter would most likely need another operator, let's say contains. So in my opinion, resetting the filter makes sense in that case.
Does this make sense to you?
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.
That example does make sense @MBilalShafi, but the opposite scenario is also valid, where users are not expecting the operator to reset. The results would be confusing if they re-searched and had not noticed the operator reset. I think it's a design issue, because it doesn't look like the X is associated to the filter operator. I'll bear it in mind as I'm currently experimenting on an updated design for the header filters for v8.
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.
the opposite scenario is also valid, where users are not expecting the operator to reset.
The positioning of "X" icon right next to the text and before the operator icon makes this argument solid, indeed! Some users might associate it with only the text and be surprised on the operator reset.
I'm fine with preserving the operator in UI until we come up with a better UI design. 👍
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 will update the code so that the UI keeps the state and adds both the operator and the value once the user adds the value to the header filter
For the empty value, item will be deleted from the model
Update:
To avoid adding additional complexity for syncing the state between the UI and the model, I have reverted the code to the state where backspacing does not clear the operator, but clicking on the X button does.
At first, I thought that having a filter item in the model that does not have the value would be strange but then I saw that it happens anyway if you change the operator before typing in any value.
Also it is better to not have a separate UI state since the header filters have to react to the changes made in the filter toolbar
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.
Nitpick: Remove applyFilterChanges
and pass apiRef.current.upsertFilterItem
directly.
8363581
to
3063a4e
Compare
ba06c2b
to
35c539d
Compare
@@ -660,7 +660,6 @@ | |||
{ "name": "renderEditSingleSelectCell", "kind": "Variable" }, | |||
{ "name": "renderRowReorderCell", "kind": "Variable" }, | |||
{ "name": "RowPropsOverrides", "kind": "Interface" }, | |||
{ "name": "sanitizeFilterItemValue", "kind": "Variable" }, |
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 have removed this because I have noticed that it was unnecessarily exported here
It will not be back-ported to v7
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
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
packages/x-data-grid/src/components/panel/filterPanel/GridFilterInputValue.tsx
Show resolved
Hide resolved
@@ -167,13 +167,9 @@ const GridHeaderFilterCell = React.forwardRef<HTMLDivElement, GridHeaderFilterCe | |||
|
|||
const applyFilterChanges = React.useCallback( | |||
(updatedItem: GridFilterItem) => { | |||
if (item.value && updatedItem.value === undefined) { |
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.
Nitpick: Remove applyFilterChanges
and pass apiRef.current.upsertFilterItem
directly.
bb1b286
to
1d992fa
Compare
Cherry-pick PRs will be created targeting branches: v7.x |
Closes #15778
https://deploy-preview-15829--material-ui-x.netlify.app/x/react-data-grid/filtering/header-filters/
Changelog
Breaking changes
sanitizeFilterItemValue()
utility is not exported anymore.