Mocking target for sendEvent()

[kitsonk]

Enhancement

We should make sure that for sendEvent() that even though the target is always a real DOM node, that it might be necessary to mock the event.target that gets dispatched. Therefore we should ensure that it can be passed (and be present) via the eventInit for the sendEvent() arguments so that the following would work in all environments:

sendEvent(target, 'click', {
    eventInit: {
        target: { /* mock target */ }
    }
});

[kitsonk]

This is a real challenge for IE11. Whenever an event is dispatched, it overwrites the target, even if the mocked target property is defined as read-only and non-configurable in the event object.

There are two solutions:

• The harness keeps a map of all event listeners passed via the virtual DOM and when it detects an event with a mocked property, it tries to resolve the event listener from the rendered virtual DOM. It then calls the event listener directly. I would still only recommend doing this in cases where there is a mocked target in order to properly support things like event bubbling, propagation, cancelling, etc.
• The harness simply does nothing, but the tester either skips the test on IE11 or branches appropriately. We could add a has() flag to make this detection easy.

I prefer the latter, mostly because I see it being somewhat of a problem only sending the event in one special way on one special platform, and while it is feasible to keep the map due to the eventHandlerInterceptor that is part of the virtual DOM system, to have a proper situation, at least the concept of bubbling might need to be included (e.g. the real target doesn't actually have a listener on it, and we would have to ascend target.parent until we found a node that had a listener in the map).

@Ant @matt-gadd @bitpshr thoughts?

[bitpshr]

So any test that uses a mocked event target would need to be explicitly skipped on IE11? I worry a bit about imposing this behavior on consumers, but the idea of having to potentially ascend the target.parent chain until the correct listener node is found seems wrong.

[kitsonk]

So any test that uses a mocked event target would need to be explicitly skipped on IE11?

Yes, but hopefully those would be in the minority. In most cases it is best to observe the behaviour on the target after the listener has fired. I think we need to understand better the use cases where it feels valid to mock the target.

There are two big challenges right now where widgets have to touch the DOM (and then really care about the contents of DOM events). Those are animations and focus management. We need to abstract widgets away from those so these sorts of things aren't problematic.

[agubler]

@kitsonk is there anyway you could "wrap" the handlers with a harness function and then inject the mock event at the point of execution? (throwing away the event that is provided from the actual action)

[kitsonk]

Retiring this in lieu of #23. We can re-open later on if the need is there.