- 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