You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
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.The text was updated successfully, but these errors were encountered: