Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make EventTarget subclassable #441

Closed
domenic opened this issue Apr 13, 2017 · 8 comments
Closed

Make EventTarget subclassable #441

domenic opened this issue Apr 13, 2017 · 8 comments
Assignees

Comments

@domenic
Copy link
Member

@domenic domenic commented Apr 13, 2017

This isn't very hard. We just give it a useful constructor. Probably by default its "get the parent" always returns null.

I can try to spec something in this area sometime this quarter.

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Apr 13, 2017

Yeah, if we leave "get the parent" out it's easier. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16487 was the previous iteration of this issue.

@andyearnshaw

This comment has been minimized.

Copy link

@andyearnshaw andyearnshaw commented May 15, 2017

What about making addEventListener, removeEventListener and dispatchEvent intentionally generic? This would allow Object.create to be used to create event targets too. All the following could then work:

let event = new CustomEvent('foo');

let target1 = new EventTarget();
target1.dispatchEvent(event);

let target2 = Object.create(EventTarget.prototype);
target2.dispatchEvent(event);

let target3 = new (class A extends EventTarget {});
target3.dispatchEvent(event);

let target4 = Object.assign({}, EventTarget.prototype);
target4.dispatchEvent(event);

The steps to run through for these methods already make them sound very generic. The only thing that seems to imply otherwise is this sentence in the spec:

Each EventTarget has an associated list of event listeners.

This could be removed from the spec, with text added to addEventListener to "create an associated list of event listeners for target" if one does not already exist, with dispatchEvent and removeEventListener having a step to "fetch the associated list for target" and abort if null.

@domenic

This comment has been minimized.

Copy link
Member Author

@domenic domenic commented May 15, 2017

We're very unlikely to do that as no web platform methods are generic right now. Creating that capability would require extensive spec work in Web IDL and extensive implementation work in browsers, for marginal gain. It would also enable authors to create un-idiomatic "event targets" that don't extend EventTarget, which isn't a goal.

@andyearnshaw

This comment has been minimized.

Copy link

@andyearnshaw andyearnshaw commented May 16, 2017

Fair enough.

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Jun 28, 2017

Do we get into trouble with IDL if subclasses are do not have constructors? Or is that fine?

@domenic

This comment has been minimized.

Copy link
Member Author

@domenic domenic commented Jun 28, 2017

You mean, is it a problem that Node is not constructible? No, it should be fine.

@smaug----

This comment has been minimized.

Copy link
Collaborator

@smaug---- smaug---- commented Jul 5, 2017

And script libraries will actually use this kinds of event targets without event target chain?

If that is the case, I support this, and the pr is ok. But I'd like to hear some reasoning for this, why we need this feature?

Do script libraries use event target -like objects in performance critical code? Would using native objects slow them? And if so, would they use native EventTarget?
Possibly a bit chicken-egg issue, implementations might get faster over time, but in current implementations there is the native<->JS layer.

@domenic

This comment has been minimized.

Copy link
Member Author

@domenic domenic commented Jul 5, 2017

And script libraries will actually use this kinds of event targets without event target chain?

Yes. We have a lot of evidence, e.g. people asking for it on StackOverflow (1, 2, 3, 4, see also linked "related questions" in the sidebar of each), or the fact that the browserify events package (which brings Node's hierarchy-less EventEmitter to the browser) is downloaded ~6.5 million times per month.

But I'd like to hear some reasoning for this, why we need this feature?

I see several big advantages over having people ship their own implementation:

  • Less code down the wire, with attendant startup performance and bandwidth benefits
  • Provides a common foundation multiple libraries can depend on; currently if you include several libraries, each of which needs event-firing functionality, you can often get multiple event implementations, which can be confusing for consumers in addition to causing code bloat.
  • Provides pretty nice semantics compared to most library implementations. In particular, without self.reportException(), it's impossible to get the same error-reporting behavior. Most library implementations instead just allow the first throwing listener to block all other listeners, which is not great.

Do script libraries use event target -like objects in performance critical code? Would using native objects slow them? And if so, would they use native EventTarget?

This is a good question I'm not sure I can answer confidently. I can provide anecdotes from my experience as a web developer, which is that events were not that frequent, being used for signaling "changes" in data or "occurrences" from the outside world or similar. I'd guess maybe between 0-10 per second.

@domenic domenic closed this in #467 Jul 7, 2017
domenic added a commit that referenced this issue Jul 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.