Re: [whatwg/dom] Allow subclassing of AbortController / AbortSignal (Issue #1162)

> I think the only reason `new WatchSignal` throws is because `new AbortSignal` throws. Generally you can subclass web platform objects.

I've continued to experiment and did manage to successfully get them subclassing, but it's a bit of a pain to get working, and doesn't allow for class fields or constructor initialisation logic in the signal so workarounds are needed: 

```js
class WatchSignal extends AbortSignal {
  // constructor wont work so let's have a one-time-call init method
  #initialized = false
  init() {
    if (this.#initialized) return
    this.#initialized = true
    this.doStuff()
  }

  get watching() {
    return !this.aborted
  }
}

class WatchController extends AbortController {
  constructor() {
    super()
    // Here is the magic line:
    Object.setPrototypeOf(this.signal, WatchSignal.prototype)
    this.signal.init()
  } 
}

const wc = new WatchController()
console.assert( wc.signal.watching )
```

> And then perhaps `AbortSignal.abort()` and `AbortSignal.timeout()` need to be able to return a subclass when used on one. I think JavaScript has some capability for that as well, but I believe that feature is not much liked.

`[Symbol.species]` but I think that is [recommended against and being proposed for removal](https://github.com/tc39/proposal-rm-builtin-subclassing).



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

Message ID: <whatwg/dom/issues/1162/1431465720@github.com>

Received on Wednesday, 15 February 2023 14:34:14 UTC