Compare with functions operating on EventTarget

[domenic]

Consider the following:

function on(et, name) {
  return { et, name };
}

function map({ et, name }, fn) {
  const newET = new EventTarget();
  et.addEventListener(name, e => {
    if (!newET.dispatchEvent(fn(e))) {
      et.preventDefault();
    }
  });
  return { et: newET, name };
}

// etc.

(Obviously not productionized code.)

This gives many of the same benefits as the current proposal (referring to the TC39 slides with the bullet points listing its advantages), in a way that integrates well with the platform.

[domenic]

Well, as discussed in TC39, this is bidirectional, since it integrates with the platform. Whereas the presentation seems to indicate this proposal is unidirectional, which has serious problems when attempting to integrate with the platform.

[domenic]

I've worked on this idea a bit more; see https://angry-wound.glitch.me/. It's still not production code (no tests!), and probably has some missing gaps, e.g. I didn't test stopPropagation()/stopImmediatePropagation()/etc., although it's held up pretty well against the things I did throw at it. But it gives an idea of what's possible.

/cc @annevk since this is what we were discussing verbally. If you look at the code, it does indeed seem there would be benefits from some platform tweaks, e.g. the AutoUnwrappingEvent is pretty hacky (maybe we should just allow dispatching any and do something similar behind the scenes), and the way that map creates the new Event from the old one and copies over relevant stuff could maybe be cleaner.

I think this gives a good basis for comparison as it automatically has platform integration and capabilities, to the extent I coded it correctly. It's a much lighter way of getting the better syntax for EventTarget, and the first-class objects representing events, that builds on top of the primitives that are already in the platform.