-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[DataGrid] Fix menu accessible #1105
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
Conversation
packages/grid/_modules_/grid/components/columnHeaders/ColumnHeaderMenuIcon.tsx
Show resolved
Hide resolved
| <Paper> | ||
| <ClickAwayListener onClickAway={onClickAway}>{children}</ClickAwayListener> | ||
| <ClickAwayListener onClickAway={onClickAway}> | ||
| <div>{children}</div> |
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 that it should aways be a MenuList as a first child (can be coming from {children}). Why is it not working in HEAD?
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 weird, it works for the export and the density but it doesn't for the column menu, by not working I mean it throws a warning in the console.
The error is that the passed children need to be able to hold a ref. This fixes the issue for all cases we currently have and I can't see any regressions.
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.
Ok, I had a look. Any weird behavior is an invitation for exploration :). The GridColumnMenu component isn't forwarding its ref, not the extra props to the MenuList component. It could be solved easily but, there a bunch of extra props (the GridBaseComponentProps) and it's not versatile.
Instead, I have pushed a commit to reorganize the composition order. Grow doesn't host any div, it needs to apply props to its children, same for ClickAwayListener. We save one DOM node.
In the process, I have found an improvement opportunity in the core, ClickAwayListener could forward its props to the children, it doesn't.
packages/grid/_modules_/grid/components/menu/columnMenu/GridColumnMenu.tsx
Show resolved
Hide resolved
packages/grid/_modules_/grid/components/columnHeaders/ColumnHeaderMenuIcon.tsx
Outdated
Show resolved
Hide resolved
…aderMenuIcon.tsx Co-authored-by: Olivier Tassinari <[email protected]>
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.
Things I have seen, we aren't too far:
- There are two approved suggestions that were only partially applied in the changes.
- As far as I know, Tab should prevent default, there is a native behavior (it scrolls the page before the focus moves back to where it should be) we want to disable. On the other hand, Escape has no native behavior hence we don't need to prevent default. It seems to be how the Menu in the core behaves. It makes me think of mui/material-ui#13470 (comment)
- The focus isn't moving to the first item in the list. Related to mui/material-ui#17571.
- I don't understand what we do with
useId. Did you look at what the hook is doing and the requirement for the id to work correctly? In the current usage, using the hook or not changes nothing.
| <Paper> | ||
| <ClickAwayListener onClickAway={onClickAway}>{children}</ClickAwayListener> | ||
| <ClickAwayListener onClickAway={onClickAway}> | ||
| <div>{children}</div> |
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.
Ok, I had a look. Any weird behavior is an invitation for exploration :). The GridColumnMenu component isn't forwarding its ref, not the extra props to the MenuList component. It could be solved easily but, there a bunch of extra props (the GridBaseComponentProps) and it's not versatile.
Instead, I have pushed a commit to reorganize the composition order. Grow doesn't host any div, it needs to apply props to its children, same for ClickAwayListener. We save one DOM node.
In the process, I have found an improvement opportunity in the core, ClickAwayListener could forward its props to the children, it doesn't.
packages/grid/_modules_/grid/components/menu/columnMenu/GridColumnMenu.tsx
Outdated
Show resolved
Hide resolved
…lumnMenu.tsx Co-authored-by: Olivier Tassinari <[email protected]>
Co-authored-by: Olivier Tassinari <[email protected]>
Alright, I pushed the changes requested. A couple of things, I'll keep |
packages/grid/_modules_/grid/components/toolbar/GridDensitySelector.tsx
Outdated
Show resolved
Hide resolved
…taGrid-column-menu-a11y
| * @param labelledby | ||
| */ | ||
| showColumnMenu: (field: string) => void; | ||
| showColumnMenu: (field: string, id: string, labelledby: string) => void; |
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 do we need id and labelledBy to show the column menu? And how can consumers get them?
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 need them so that the labelledby and the controlledby are hooked up correctly. I had to do it like this because they that the menu and the button are set up that is the only option. In terms of how users can get them -> there are in the state while the menu is opened.
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.
ShowColumnMenu should only show the menu when one click on the 3 dots icon next to the column title.
Is that still the case?
there are in the state while the menu is opened.
Well showColumnMenu opens the menu so how can we know the labelledBy before we call the showColumnMenu. Chicken and egg 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.
I mean the existing functionality still works the same. Also, why do we need to know the ID beforehand it is for hooking up the accessibility, there are no functionalities or styles attached to it?
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.
@dtassone can I merge this, it would be nice to include the fix in the upcoming release 🙃
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.
how do you render the grid with the menu open. Imagine if the user want to put a custom component...
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.
How is it harmful?
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 don't think that would be an issue, they can still open it right, it's just that the id and the labelledBy won't be set
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.
How is it harmful?
It could prevent us to improve the internal: e.g. this very discussion. I don't understand the use cases for a developer to programmatically open a column menu from outside the normal end-user flows. Wouldn't it be better to say a temporary NO and wait for a developer to come up with a valid use case?
they can still open it right, it's just that the id and the labelledBy won't be set
So the a11y would be broken?
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 don't think that would be an issue, they can still open it right, it's just that the
idand thelabelledBywon't be set
why not make them optional?
Also why calling it id? Something like menuElementId or whatever a bit more specific so it's more understandable
Fixes #881
Fixes #882