Add unit tests for concurrent mode event dispatching

[sebmarkbage]

This adds a test for concurrent mode event dispatching.

The way we deal with discrete events (click, mouseup, mousedown, touchup, touchdown, submit, etc) is that the result from one event must fully flush before we invoke the event listener of the second one. They are always serial. Note that they're not synchronous. They won't block continuous events like rAFs, mousemoves, etc.

We implement this using the custom event system. The first thing that happens in the delegated event listener is that we check if there are any pending discrete priority work (formerly known as "interactive events") and if there is, we flush it synchronously. Only when that is done do we search the new tree to dispatch event listeners.

If we just attached event listeners directly on the nodes, we would have no opportunity to update these before they happen.

[sebmarkbage]

For removed event listeners, it is a bit easier since we have one before hand and in it we can check if we should just ignore it.

This case is trickier because we go from not having a listener to later having one. So to implement this we need to have a listener attached before we need it.

[sebmarkbage]

Now that I think about it, we probably have a small bug here today since we lazily attach certain event listeners to the root the first time they're used. If a different discrete event happens, then we attach a new discrete event for the first time, then we'd see this bug today. I think the only fix is to add all of them to the document eagerly.

[trueadm]

Are you saying that there is a bug in the existing code today? If so, why isn't the test failing currently? Shouldn't we try to fix this bug in current ReactDOM, so we can have a regression test for Fire?

[acdlite]

Need one more test for the "counter" example: each discrete event must commit in sequence. So if you click on an increment button five times, the final result should always be five.

<button onClick={() => setState(count + 1)}>Increment</button>

[sebmarkbage]

The counter event is relevant in terms that it needs to get a new event listener attached in the internals but it can be implemented by having the event listener itself go through an indirection that reads the current most props. So event delegation or not doesn’t matter as much.

Another case which we might want to consider is the case where the second target element is not in the position it would’ve been or doesn’t even exist yet. In that case we might want to hit test in the event delegation and redispatch the event to the new target. Eg a button that switches to another button at the same position. The second click should be invoked on the new button that doesn’t exist at the time of the click.

[trueadm]

@sebmarkbage Thanks for creating these tests – it adds a lot of missing context for me. :)

[gaearon]

We should probably get this merged sooner rather than later?

[Kachulio1]

@gaearon We should get it right, though, so I'm okay with waiting.

[gaearon]

I'll file a follow-up issue with @acdlite's comment

[philipp-spiess]

This is great! Thank you for writing this up.