Re: [whatwg/dom] Add abortSignal.addAbortCallback (PR #1425)

jasnell left a comment (whatwg/dom#1425)

From a language-level perspective, I think it's better if we defined the mechanism as a cancelation/abort protocol in the language... of which `AbortSignal` could be update to be / considered an implementation.

Specifically, I've been imagining something along the lines of...

```
const genericAbortSignal = {
  [Symbol.onabort]() {
    // Register and return the abort handle
    return {
      cancel() { /* Unregister the abort handler */ },
      [Symbol.dispose]() { this.cancel(); }
    };
  },
};

doSomething(genericAbortSignal);

async function doSomething(signal) {
  using abortHandle = signal[Symbol.onabort]();
  abortHandle.onabort = (reason) => { /* ... */ };
  // Do async stuff that can be aborted...
}
```

Then, the actual `AbortSignal` class here could just add `[Symbol.addAbortHandler]` such that it defers to `addEventListener`.

This type of approach would allow any object to become an AbortSignal. It would allow TC39 to define abort semantic without relying on `AbortSignal`, `AbortController`, `Event`, or `EventTarget`.

The requirement of the protocol would be that a call to `Symbol.onabort` must return an object that minimally must expose a `cancel()` method that would unregister the handler from the signal.

`AbortSignal` could easily be adapted to support this:

```js
class AbortSignal extends EventTarget {
  // ...

  [Symbol.onabort]() {
    let callback;
    const self = this;
    const handler = {
      cancel() {
        self.removeEventListener('abort', callback);
      };
    };
    callback = (event) => handler.onabort?.(event.reason);
    this.addEventListener('abort', callback, { once: true });
    return handler;
  }
}
```


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1425#issuecomment-3614722520
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1425/c3614722520@github.com>