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

Allow users to extend ExtendableEvent, anywhere #1290

Open
rektide opened this issue Mar 19, 2018 · 1 comment
Open

Allow users to extend ExtendableEvent, anywhere #1290

rektide opened this issue Mar 19, 2018 · 1 comment

Comments

@rektide
Copy link

rektide commented Mar 19, 2018

Hello.

As a JavaScript developer, I have, for my own use & without realizing it, recreated something very akin to the ExtendableEvent interface: an event that listeners can delay termination on, an event that has a lifetime that resolves. This is a pretty abstract concept, and it's one that I think that ExtendableEvent was created to fulfill for a specific use case that it ought to instead provide generically for all users of the web platform. I would like to see this viable ServiceWorker interface reificed into a generic class, and hoisted out of ServiceWorker, and available in all JavaScript scopes (such as the page, or other workers). Just as EventTarget was made capable of being extended in JavaScript, I would like to see ExtendableEvent be made into a class that other classes can extend off of.

Notably missing from the current interface is any way to signal the completion of the lifetime extending waitUntil() promises. I'm not sure how flexible an [Foo]Event constructor can be, but perhaps something akin to how Fetch constructor was made to accept an [Abort]Controller could be used to signal. In general I like the idea of trying to replicate as closely as possible the Controller/Signal pattern Fetch sets forth. However, it does seems odd to signal completion (or one could say resolution) of an event by firing another event, so I'm less than fully committed to trying to follow that mold exactly, or maybe it's enough.

In my own async-event-target library (linked above) I was focusing more on the bigger scope, of an EventTarget that exhibits dispatch resolution across a lifetime, rather than focusing just on the event. To that effect, I made dispatchEvent() be able to return a promise that signalled completion. Given that the promise is a truthy value, seemed like a passable path forward, but it's definitely optional for this work. I think it would make sense to bring in ExtendableEvent alone, but it may be more useful and make more sense if EventTarget is itself also extended.

@clshortfuse
Copy link

clshortfuse commented Feb 23, 2023

@jakearchibald Appears it was on the agenda in October 2018, but I don't see any notes on it. It's been a couple years and I believe it's pretty stable now.

Piggybacking off a feature request I filed in whatwg/dom#1167 this could be useful for us devs. I'm currently using a polyfill for NodeJS and browser environments because right now it's scoped to Service Worker.

The only change I would like to see is a .detail property like CustomEvent. Not sure how to work around instanceof ExtendableEvent vs instanceof CustomEvent though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants