Event capturing

For the most part it is fine to skip the 3rd argument of addEventListener but some event types do not bubble - which creates a dilemma when using event delegation (for example, to avoid passing callbacks down the component tree).

I’ve created some very simple demos here:

• Vanilla JS http://codepen.io/anon/pen/PzXvVE
• React v15.3.0 http://codepen.io/anon/pen/QEPWNx
• Preact v5.7.0 http://codepen.io/anon/pen/YWrzWG

All synthetic events in React bubble (or at least appear to do so) so this can create some incompatibilities when switching to Preact.

UPDATE: React explicitly supports capturing by appending Capture to the attribute, E.G. onClick would become onClickCapture https://facebook.github.io/react/docs/events.html#supported-events and certain events are set to capture automatically (inc. focus and blur).

I’m not fully aware of the ramifications that changing this line would be. Perhaps it may be preferable to check the event type against a capturing whitelist.

I’m happy to help implement any changes, even if it’s just a note in the docs 😄

[developit]

I think that makes more sense - I was worried about swapping to capturing phase for things like click, because there are definitely people invoking stopPropagation() on those types of events, expecting them not to bubble (up). The events in the whitelist you linked to aren’t bubbling events anyway, so I think it’d be alright to silently switch those over to useCapture.

Another option (maybe less pleasant) would be to manually bubble the non-bubbling events - Preact already hooks all events, and we could do something like this? (though I worry this is venturing into virtual eventing territory)

let whitelist = ['change', 'input', 'etc'];

function eventProxy(e, node) {
  e = options.event && options.event(e) || e;
  node = node || this;
  let fn = node._listeners[e.type];
  if ((!fn || fn(e)!==false) && !e.propagationStopped) {
    eventProxy(e, node.parentNode);
  }
  return ret;
}

[i-like-robots]

I’ve asked around and had some input as to why this may be a bad idea in some cases, and why a whitelist may be preferable.

If all listeners are triggered at the capture phase then calling preventDefault() within the callback of an inner node listener will not stop it from reaching an outer node listener. 😢

However, it can be sensible (preferable?) to use capture for some events, like those previously mentioned… and perhaps a few more.

(Thanks to @matthew-andrews for refresher course!)