-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[TreeView] Change focus management to aria-activedescendant #21695
Conversation
@material-ui/lab: parsed: -0.24% 😍, gzip: -0.11% 😍 |
2863f50
to
4a50f8a
Compare
} | ||
// Is before | ||
// eslint-disable-next-line no-bitwise | ||
if (array[middle].element.compareDocumentPosition(element) & Node.DOCUMENT_POSITION_PRECEDING) { |
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 exists 😮 Is it an issue if elements are portaled?
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.
Hmm, It shouldn't be but I should add a test :P
|
||
expect(getByRole('tree')).to.have.attribute('aria-multiselectable', 'true'); | ||
expect(screen.getByRole('tree')).to.have.attribute('aria-multiselectable', 'true'); |
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.
Maybe we should have left this change for another pull request, it makes reviewing the change more challenging.
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.
Actually, did we settle on this approach? I have seen it mentioned in https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#not-using-screen. cc @mui-org/core-team.
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 removed it from the PR to see if it makes it easier to review.
ec0dd83
to
4018be7
Compare
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.
Stop allowing custom ids on TreeItems
Is this for this PR or another one?
Probably for this one. It's quite badly worded - active descendant requires an id on the TreeItem but currently, users can override this breaking functionality. We need to add a warning or to change nodeId -> id. What are your thoughts about the latter? @eps1lon @oliviertassinari |
I'd prefer to not overload |
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 thought we were getting rid of nodeId
. Not being able to set id
on the underlying DOM node for role="treeitem"
could be quite problematic if people need to reference it in another IDREF attribute (e.g. aria-labelledby
) though I'm not aware of concrete use cases. It's just the first component where people are not able to query it by ID.
Can we put the id
in the nodeMap
and read it from there instead?
setFocusedNodeId(id); | ||
|
||
if (onNodeFocus) { | ||
onNodeFocus(event, id); |
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 not a big fan of passing an event here. Sometimes the target will be the tree e.g. on keyboard events. I don't really think there is an alternative apart from creating some kind of pseudo-event where we only populate target.
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 is fine in my book as long as it's typed as a generic synthetic event i.e. React.SyntheticEvent
. We already have this in place in a couple of other places. It's similar to how React itself doesn't make any guarantee about event.nativeEvent
. #21552 has more context on this issue.
Docs: https://deploy-preview-21695--material-ui.netlify.app/components/tree-view/
Closes #20204
Closes #20097
Allows us to have more flexibility in the future and simplifies TreeItem. Since I was changing a lot of the tests due to the focus change I refactored them all to use
screen
and removed all uses ofcontainer
.Todo: