Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

> So, wouldn't it make sense for a push handler to get attached to the `response` of a resolved `fetch`, like, say, via `response.addEventListener("push")`

Also, as something of an aside - and I know this ship, to a degree, has sailed, what with ServiceWorkers already being out in the wild and all - but I think this kind of event handler, where having one attached makes it *the canonical insertion point* for handling all the types of an event, *replacing any existing browser plumbing* (as opposed to the way `.addEventListener` has traditionally worked with `event.preventDefault()` being something you'd have to opt *into*), should have been put under a *different name* than `addEventListener`, like `addEventHandler`, to denote that it's not merely *listening* to events, but *actively controlling them*. Would it maybe be possible to introduce that as an *alternative name* for setting these kinds of listeners, and deprecating the use of `addEventListener` for that purpose, the way that pseudo-element selectors in CSS were originally spelled with a single colon (like `:after`), the same way as pseudo-classes (like `:active`), and were later redefined to use a *double* colon (ie `::after`)?

Maybe these `addEventHandler` handlers could even, instead of just being the same kind of function attached via a different name, have changed semantics (which could potentially be reused for other kinds of events in the future) where their return value (either explicitly or implicitly when the handler returns void) *is the event*, which will get passed, *with modifications*, to any *next* event handlers in sequence, as alluded to with

> you could just have the handler not claim and/or return the `push` coming in, and it'd get passed back into the pipe naturally.

?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/447#issuecomment-282353713