Re: [whatwg/dom] Expose an `aborted` promise on AbortSignal? (#946)

> it's using GC observation to help other things get GCed, not to do important program logic. So I'm not too worried there.

That's a good point.

> Another angle is, how does this contrast with weak listeners? My impression (but not a very confident one) is that this proposal actually has two parts: weak listeners, plus sugar to bundle together the aborted check and the weak listener attachment. That is, it could be written as

That is exactly the sort of implementation I've had in mind - I initially investigated weak listeners for `.follow` but [the (internal) weak listeners PR](https://github.com/nodejs/node/pull/36607#issuecomment-773392581) will have to land.

Note that having such an `aborted` provides _significantly fewer_ capabilities to users than exposing weak event listeners in general. Exposing the lower-level building block is indeed more powerful but also more dangerous.

There is precedent of things holding other things weakly in the spec (for example mutation observers [have a weak reference](https://dom.spec.whatwg.org/#garbage-collection) to the node they are observing). This use case might just be a generalisation of that one.

I'm happy to follow up the (internal) weak listeners PR in Node.js with a `addWeakListener` util helper but:
 - I'm not sure if it's a good idea. intuitively it's very easy to misuse but I have no evidence for that.
 - I'd rather do this through the standards path, same reason this issue exists.

The idea is to provide a safe API for users to use to listen to the signal becoming aborted.

-- 
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/issues/946#issuecomment-773598165