- From: Keith Cirkel <notifications@github.com>
- Date: Wed, 15 Feb 2023 06:34:01 -0800
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/1162/1431465720@github.com>
> 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