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.

Sign up for GitHub

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

Jump to bottom

[material-ui][Modal] Fix event handlers overriding behaviour #43757

Merged
merged 5 commits into from
Sep 17, 2024
Merged

[material-ui][Modal] Fix event handlers overriding behaviour #43757

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e116263
fix event handlers overriding behaviour
sai6855 Sep 14, 2024
662042f
Merge branch 'master' into modal-event-handlers
sai6855 Sep 14, 2024
a667017
trigger
sai6855 Sep 14, 2024
d6dc829
Merge branch 'master' into modal-event-handlers
sai6855 Sep 16, 2024
a475aa7
modify test
sai6855 Sep 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion packages/mui-material/src/Modal/Modal.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,6 +156,7 @@ const Modal = React.forwardRef(function Modal(inProps, ref) {
}

const externalForwardedProps = {
...other,
slots: {
root: components.Root,
backdrop: components.Backdrop,
Expand Down Expand Up @@ -218,7 +219,7 @@ const Modal = React.forwardRef(function Modal(inProps, ref) {
* is not meant for humans to interact with directly.
* https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/no-static-element-interactions.md
*/}
<RootSlot {...rootProps} {...other}>
<RootSlot {...rootProps}>
{!hideBackdrop && BackdropComponent ? (
<BackdropSlot {...backdropProps} ref={backdropRef} />
) : null}
Expand Down
16 changes: 16 additions & 0 deletions packages/mui-material/src/Modal/Modal.test.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -880,4 +880,20 @@ describe('<Modal />', () => {
);
}).not.toErrorDev();
});

it('should not override default onKeyDown', async () => {
const handleKeyDown = spy();
const handleClose = spy();

const { user } = render(
<Modal open onKeyDown={handleKeyDown} onClose={handleClose}>
<div tabIndex={-1} />
</Modal>,
);

await user.keyboard('{Escape}');
Copy link
Member

Choose a reason for hiding this comment

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

How long does it take to run this test with this utils vs. firing a keydown event directly?

Copy link
Contributor Author

@sai6855 sai6855 Sep 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Not sure if this is correct way.

await user.keyboard('{Escape}') took around 30ms (+/- 5ms)

image

 fireEvent.keyDown(getByTestId('modal'), {
   key: 'Escape',
 });

took around 4ms (+/- 1ms)

image

Copy link
Member

@oliviertassinari oliviertassinari Sep 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Ok thanks, so about +20ms. If we scale this to our 10,000 tests: https://app.circleci.com/pipelines/github/mui/material-ui/139173/workflows/97427b1f-67e7-406f-aec4-1fdcd5fe84dc/jobs/750329.

It could mean +200s, from 3 minutes to 6 minutes: https://app.circleci.com/pipelines/github/mui/material-ui/139173/workflows/97427b1f-67e7-406f-aec4-1fdcd5fe84dc/jobs/750329. So I think to be really careful with this.

cc @Janpot. We might want to limit https://github.com/testing-library/user-event to only cases where we absolute need it.

Copy link
Member

Choose a reason for hiding this comment

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

I guess we should include clear guidelines on when to use one or the other in test/README.md. From discussions in past PRs it seemed that we were leaning towards using user more in new tests.

Copy link
Member

@Janpot Janpot Sep 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

We can potentially drastically speed up userEvent by setting it up with delay: null.

userEvent.setup({ delay: null })

See https://testing-library.com/docs/user-event/options/#delay

It looks like the semantics will change somewhat though. i.e. it will yield to a macrotask instead of a microtask in between events. I did some preliminary testing and it seems to make up the bulk of the increase in time. The question will be whether this is going to be a problem for us or not.

I'd argue that the current tests don't care at all about the event loop when chaining events, so we're probably good here.

In the meantime I'm also opening testing-library/user-event#1233

It could mean +200s, from 3 minutes to 6 minutes

The biggest part of the runtime increase seems to be non-blocking. With parallelized tests the impact should be much smaller than what you describe here.


expect(handleKeyDown).to.have.property('callCount', 1);
expect(handleClose).to.have.property('callCount', 1);
});
});