Explore alternative event dispatch/simulation

[kentcdodds]

Based on a twitter conversation with Dan Abramov where he suggests that this dispatch events rather than use TestUtils.Simulate, I think it may be worth looking into. As he mentioned:

Just note dispatchEvent will only work if you enable bubbling and node is in the document

I think adding the container to the document should be fine normally, especially in Jest where the test files run in isolated environments. But I'm a little bit worried that we'd fill up the document with mounted components that never get unmounted. We could encourage people to have a beforeEach that cleans things up, but that'd be annoying and reduce the simplicity. We could simplify it with a import 'react-testing-library/autoclean' or something, but still that's a reduction in simplicity. So I'm not certain how to solve this problem...

It would be cool if we could have a utility that does actual events and also encourage people to just use .click() and .focus() methods native to DOM nodes. So I'd definitely like to explore this.

[kentcdodds]

Alrighty, it looks like the best solution would be to implement this: facebook/react#2043

The latest effort behind it was closed because issues were raised which were never addressed. However, the changes appear fairly minimal and should give anyone who wants to give it a try a head start! Review the discussion in there and open a new PR that addresses those issues.

Anyone want to do that?

[kentcdodds]

After further review (and tweets), it appears that this will be a fairly significant effort and perhaps even require a breaking change in React. So we'll have to wait until React 17. Which is unfortunately, but I think it'd be great if we could make this happen in time to get on the React 17 train (whenever that leaves the station...).

[sompylasar]

It would be cool if we could have a utility that does actual events and also encourage people to just use .click() and .focus() methods native to DOM nodes.

The native click and focus methods do not trigger the DOM side-effects (events) that React and the tested app rely on. Using them contradicts to the core principle of react-testing-library to use the components the same way the users would use them.

Ideally, there has to be a way to simulate real user input followed by its side-effects such as DOM state changes (inputs value/checked/selected, scroll position including overflow, urlbar location, fullscreen API unblock, video play API unblock), DOM events that tell the app about some of these changes, CSS hidden state changes (hover, transition state, animation state) from within the JS platform, but this contradicts to the JS/browser security policy of app sandboxing, thus renders the test automation tools that work from within the JS/browser platform (hi Cypress) helpless about the real user input simulation, leaving them with the hacks like dispatchEvent.

[kentcdodds]

Hi @sompylasar,

Thanks for a good overview of the problem. What solutions do you have for us that make attractive trade-offs?

[sompylasar]

Thanks for a good overview of the problem. What solutions do you have for us that make attractive trade-offs?

Hi @kentcdodds

Unfortunately I don't see a solution from within the browser/JS sandbox. The limited options I see now are:

1. the app testing framework implements functions that emulate the browser behavior as close as possible (all the events, bubbling, internal state changes etc), but that still won't match the actual browser behavior with some events, hover, focus, animation, history, media, and so on as no-one can tamper with the browser internal state (please don't tell me not to test it, Cypress);
2. the app implementation framework like React limits what's possible to do on the browser platform, especially with positioning, scrolling, focus management, and all things listed above for emulation (this tears the creativity of all the CSS and DOM hackers down to zero which may not be practical in real world apps).

[kentcdodds]

Thanks @sompylasar, I'm afraid that neither of those solutions is reasonable for this project so we'll have to try for the next best thing.

[antsmartian]

@kentcdodds Just a dumb question here.. I'm just trying to understand the reason behind this idea. Is there any downside of using TestUtils.Simulate? To me it just actually takes care of Synthetic events which is what React uses internally. Why do we move away from TestUtils.Simulate and use dispatchEvent?

[kentcdodds]

Because Dan said so 🤷‍♂️ as noted in the first comment.

[antsmartian]

@kentcdodds Yup, saw the comment from Dan as well.. But was just wondering, why we need to do so.. Is there any benefit for dispatchEvent or not, I'm not sure. May be we need to ask him in the same twitter thread.

[kentcdodds]

I think we should add something like this to dom-testing-library instead. I was thinking about it for the initial release but didn't have time and didn't want to rush it.

[kentcdodds]

Really awesome progress here: testing-library/dom-testing-library#13 Thanks @jomaxx!!

I'll go ahead and leave this open until that gets released and we update react-testing-library to re-export it.

[kentcdodds]

Thanks to @jomaxx, this was resolved in #48 as well as we can hope for now. It really would be great to get react updated to either remove event delegation entirely or attach event handlers to the root of the react tree rather than the document. For now the solution we have is great though. Thanks!