[DataGridPro] Filtering on the Header followup actions

[MBilalShafi]

This one supersedes #7760 with the action items left over.

• [data grid] Support inAnyOf operator in header filters #9243
• 2. [Chrome only] Visual bug: scroll jump on keyboard navigation.
  • Context [DataGridPro] Filtering on Column Header #7760 (comment)
  • Fix [DataGridPro] Fix column headers alignment #9502
• 3. A visual issue with compact density [data grid] Filter headers need adjustment for density="compact" #13048 :
  
• 4. Adjust icons
  • Context [DataGridPro] Filtering on Header — improve icons #9049
  • Fix [DataGridPro] Improve header filter menu visuals #9181
• 5. Improve floating label animation
  • Context [DataGridPro] Filtering on Column Header #7760 (comment)
  • Fix [DataGridPro] Improve header filter menu visuals #9181
• 6. Restructure filtering docs for better discoverability
  • Fix [docs] Improve discoverability of Filtering section of docs #9074
• 7. Bugs related to cell blur
  • Context [DataGridPro] Filtering on the Header followup actions #9034 (comment)
  • Fix [DataGridPro] Improve header filter menu visuals #9181
• 8. Dark mode border issue
  • Context [DataGridPro] Filtering on the Header followup actions #9034 (comment)
  • Fix [DataGridPro] Improve header filter menu visuals #9181

[oliviertassinari]

6. Another idea. This Pro feature is in the middle of the MIT page: https://deploy-preview-7760--material-ui-x.netlify.app/x/react-data-grid/filtering/#header-filters.

I think that we could break down the page into multiples, moving the Pro feature to its own page, not alienating the community. Plus the docs page is quite big, it would be more focused.

Otherwise, I think to move to the bottom of the page.

[MBilalShafi]

6. I think that we could break down the page into multiples

@oliviertassinari Yep that's a good idea, I've tried to do a similar thing in this PR: #9074

[oliviertassinari]

7. Bugs related to the cell blur logic:

Screen.Recording.2023-05-31.at.16.23.48.mov

https://mui.com/x/react-data-grid/filtering/#header-filters

7.1. The data grid cell isn't blurred at the first click. I have to click twice
7.2. The input is still shrunk after the data grid is fully blurred

8. Enter blur the filter input. I think that we should test this with end-users. I got tricked by this again. I don't know if the filter is applied instantly, my instinct is to press Enter to run the filter but now, when I type again, nothing happens as the input is blurred.
   Last discussion about it in [DataGridPro] Filtering on Column Header #7760 (comment).

[MBilalShafi]

Enter blur the filter input. I think that we should test this with end-users. I got tricked by this again. I don't know if the filter is applied instantly, my instinct is to press Enter to run the filter but now, when I type again, nothing happens as the input is blurred.

This one is interesting, the behavior that filters are applied on debounce and not on enter is something that users already experienced with the regular filter panel, not sure about other users but for me, the loading icon that appears during typing is a nice visual feedback that depicts the filters are being applied in the background, but yes we can test this with users and see what most of the users think about it 👍

If we change the behavior to apply the filter on Enter though, there's a nice way to stop differentiating between the cell and input field. When the user starts typing, the arrow keys are passed to the input, on pressing Enter, the filters are applied, and the focus is still on the input (cursor is blinking), but the arrow keys are now passed to the keyboard navigation (which again can pass to the input when user starts typing something). But I am not sure if this will look natural to the users 🤔 I'll try to do a demo to validate the idea.

[romgrk]

It feels a bit off to me that the separator between headers & header filters has more visual weight than the one between header filters & cells. I feel like if there is a bolder separator, it should be between the whole header section and the cells.

[MBilalShafi]

@romgrk Thank you for pointing it out, the border color was not properly adjusting with the dark mode, fixed it in this commit.

[romgrk]

I must also say that I don't like Material Design inputs too much for this use case, from a UI/UX POV. First, the "Contains" label is bigger than the column title label. I would expect the opposite. Also the underlined input border right next to the bottom row border looks a bit off, imho. Puts a lot of emphasis/visual-weight on that region. I wonder if we wouldn't be better off by placing the filters inside the column title cell. It would also save some vertical space if we can avoid having 2 separate rows for the headers & filters.

The filters in their focused state have a nice feel, but their unfocused state has the problems described above.

[MBilalShafi]

I wonder if we wouldn't be better off by placing the filters inside the column title cell. It would also save some vertical space if we can avoid having 2 separate rows for the headers & filters.

That's a nice idea, we discussed it multiple times previously and after discussing the pros and cons, we decided to go with the separate header row. For example: #4934 (comment), #4934 (comment)

I agree, in the current implementation, the state with no filter value doesn't look ideal, as there's an empty space on top and a prominent border near the bottom. Probably we can think about iterating the UI part a bit. Sidenote: For now, I merged the PR to deliver the changes done to the users, we can always follow up to re-iterate!