Skip to content
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

[tree view] Cleanup onKeyDown handler #11481

Merged
merged 8 commits into from
Jan 10, 2024

Conversation

flaviendelangle
Copy link
Member

@flaviendelangle flaviendelangle commented Dec 21, 2023

Closes #10577
Closes #10397
Closes #9962

  • Improve the overall readability of the function
  • Support defaultMuiPrevented
  • Do not stop the propagation of the event
  • Only prevent the default behavior when we really use the event for some custom behavior

@flaviendelangle flaviendelangle self-assigned this Dec 21, 2023
@flaviendelangle flaviendelangle force-pushed the refacto-onKeyDown branch 2 times, most recently from c5fe0de to 0f66d83 Compare December 21, 2023 11:24
@mui-bot
Copy link

mui-bot commented Dec 21, 2023

Deploy preview: https://deploy-preview-11481--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against b8a3dfd

@flaviendelangle flaviendelangle added the component: tree view TreeView, TreeItem. This is the name of the generic UI component, not the React module! label Dec 21, 2023
@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Jan 2, 2024
Copy link

github-actions bot commented Jan 2, 2024

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Jan 2, 2024
Copy link
Member

@LukasTy LukasTy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice improvement. 👍
LGTM, but not approving yet before discussing the defaultMuiPrevented topic.

});
fireEvent.keyDown(getByRole('tree'), { key: 'Enter' });

expect(getByTestId('one')).to.have.attribute('aria-selected');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: have you considered using getByRole('treeitem') instead? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept the DX used on the other tests, but I did not think about the alternative tbh

otherHandlers.onKeyDown?.(event);

let flag = false;
const key = event.key;
if (event.defaultMuiPrevented) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think that this feature will be transparent enough for the users? 🤔
Have you considered checking event.defaultPrevented instead?
It seems that in cases, where this behavior is supported, we do explicitly document it. 🤔
If we go with defaultMuiPrevented, do we agree that it should be explicitly documented?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

defaultMuiPrevented is a pattern that a several recent core components uses and the grid as well.
I think the reasoning behind it is to be able to distinguish browser behavior and MUI behavior. To let people say "hey I want the browser behavior, but not the MUI one".

With that being said, I can't find any doc about it except in this tech file: https://github.com/mui/material-ui/blob/master/packages/mui-base/CONTRIBUTING.md
Once the pattern is widely used in the MUI codebase, it should probably have a dedicated doc section somewhere.
And the Tree View onKeyDown event is probably common enough to justify a doc examples as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe @michaldudak has more context here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK Material UI uses this pattern in several places, and I adopted it in Base UI as well (it was necessary to have an option to prevent just the library code from executing).
I agree about the docs lacking in this area. I'm making a note to update them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@flaviendelangle If you think that not providing an explicit documentation section about this possibility in the current state of all products documentation is fine, I'm not blocking the PR merging, but IMHO, such a section wouldn't hurt. 😉

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering if this shouldn't be addressed at the API page level.
To have the onKeyDown prop listed here with a description that sends to a MUI-wide page explaining how to use defaultMuiPrevented.

If we want to do it on the product pages, we could create a new "Interaction" pages on both SimpleTreeView and RichTreeView and add a section "Customize the keyboard behaviors".
Or we wait for the "Accessibility" page and we put it there since it will be the page that explains the keyboard behavior in depth.

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good points. 👍
The first suggestion sounds the best, but AFAIK, it's more or less a future solution.
I'm not against just waiting a bit until there is a common page that we can link to. 🤔

Adding this info to the Accessibility page is also an option, but I'd argue that it is not the best place for such content. 🤔
We could link to the above-mentioned page there. 💡

I'm not the biggest fan of the Interaction page suggestion if it would only include this information, but IMHO it's a better alternative than the Accessibility page. 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could re-purpose the Accessibility page to be more a Keyboard usage page (this name is terrible though).

Tbh I did not add this doc section because I did not find a good place to put it 😆

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll merge without a doc, we can discuss later what we want to do 👍

Copy link
Contributor

@noraleonte noraleonte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice improvement! 🎉 The changes make sense and overall looks a lot cleaner 👍

otherHandlers.onKeyDown?.(event);

let flag = false;
const key = event.key;
if (event.defaultMuiPrevented) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@flaviendelangle If you think that not providing an explicit documentation section about this possibility in the current state of all products documentation is fine, I'm not blocking the PR merging, but IMHO, such a section wouldn't hurt. 😉

@flaviendelangle flaviendelangle merged commit 0946a1b into mui:next Jan 10, 2024
17 checks passed
@flaviendelangle flaviendelangle deleted the refacto-onKeyDown branch January 10, 2024 08:00
@ilbrando
Copy link

It appears to me that the prop defaultMuiPrevented is not part of the typings for onKeyDown. Am I right about this, or am I missing something? Intellisence gives me this: DOMAttributes<HTMLUListElement>.onKeyDown?: KeyboardEventHandler<HTMLUListElement> | undefined

@flaviendelangle
Copy link
Member Author

Our key down handler is called by the item component since #12226)
I will update the typing of TreeItem2Props and TreeItemProps to respect the event handlers that support defaultMuiPrevented.
I will comment also #9962 with the updated example because the current one no longer works.

@flaviendelangle
Copy link
Member Author

#13152

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: tree view TreeView, TreeItem. This is the name of the generic UI component, not the React module!
Projects
None yet
6 participants