w3c / w3c/ServiceWorker

Allow users to extend ExtendableEvent, anywhere

Open
#1,290 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Bikeshed
Stars
3.6k
Forks
324
Avg merge
14d 22h
Merged PRs (30d)
1

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked async-event-target.js and the ExtendableEvent and waitUntil behavior described in the issue. Define the generic scope and completion-signaling semantics, including whether EventTarget or dispatchEvent() must change; done means the interface and its integration are specified clearly enough for implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
api, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.