Re: [whatwg/dom] Define a 'PromiseController' and 'PromiseSignal' interface. (#434)

Thanks, @annevk!

> Are we going to define a non-DOMException for the actual cancellation exception as well then so it could be factored out and move into the language if it ever comes that established?

Sure. The Fetch proposal hand-waves an `AbortError`. Happy to fold that into this patch if you'd like.

> but if more folks want cancellation (some elaboration would be appreciated)

WebAuthn wants `navigator.credentials.get()` to be cancellable. @jyasskin and @equalsJeffH have more context there, I'm just trying to support them.

> we should maybe loop in some other folks for review as well.

Please CC the world. :)

> Overall your PR looks fine, but I think we need some more abstraction for specification-consumers of the signal (that will then cancel/abort the actual operation). 

More non-normative notes about usage and suggested spec text for the examples? Or more something else?

> It's also not immediately obvious how this works where we expose the signal (a mirroring cross-thread instance of sorts I suppose) to the service worker (while the controller is on the main thread) which can then pass it along to new fetches (zero or more) which the controller will also end up affecting.

It seems like that would be a Fetch-specific addition, wouldn't it? It's not clear to me that most APIs would need cross-process updates for a signal's state. I guess we can pull some sort of mirroring primitive up to DOM if that would be helpful, but it seems somewhat specific to Fetch's use case.

-- 
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/dom/pull/434#issuecomment-291893448