Re: [whatwg/dom] Consider adding AbortController.prototype.follow(signal) (#920)

Thanks for chiming in! Indeed, from my experience it's very easy to leak abort event listeners in user code.

In my custom `AbortController` implementation, I have an additional `destroy()` method on `AbortController`. This first fires a `'destroy'` event on its signal, and then removes all `'abort'` and `'destroy'` listeners that were attached on that signal. (I know, this isn't possible with a regular `EventTarget`, so I'm also rolling my own implementation there. 😛).

For my custom `AbortController.follow()` implementation, I add a `'destroy'` listener to **both** the parent signal and the following signal, which removes all listeners that were added to either signal. This ensures that all the "links" between the two signals are removed, so they no longer keep each other alive.

It's messy and tedious, since I need to carefully add a bunch of `destroy()` calls throughout my code whenever I'm "done" with a certain signal. For example, this pattern pops up several times:
```javascript
const tempController = new MyAbortController();
tempController.follow(signal);
try {
  await doSomething(tempController.signal);
} finally {
  // At this point, either the controller became aborted which caused `doSomething` to reject,
  // or `doSomething` resolved/rejected normally. So we can clean up our temporary abort controller.
  tempController.destroy();
}
```

I'd be *very* interested in ways to get rid of this mess. 😁

-- 
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/920#issuecomment-726918447