search

shaseley / abort-signal-any

Explainer for AbortSignal.any(), a new DOM API that enables combining AbortSignals
25 stars 1 forks source link

Explicitly address how this will allow for removal of "follow" #1

Open annevk opened 2 years ago

annevk commented 2 years ago

I checked and the two instances in Fetch that use the follow primitive can be replaced by AbortSignal.any(), but it would be good to spell that out.

One instance is in the Request constructor:

  1. Set this’s signal to a new AbortSignal object with this’s relevant Realm.
  2. If signal is not null, then make this’s signal follow signal.

Another instance you already point to, in Request's clone() method:

  1. Make clonedRequestObject’s signal follow this’s signal.

(This probably requires changing https://fetch.spec.whatwg.org/#request-create in some way, to take an AbortSignal. That might also impact Service Workers.)

In particular I think a goal should be to either build on https://dom.spec.whatwg.org/#abortsignal-follow or replace it in its entirety.

shaseley commented 2 years ago

Thanks Anne, +1 to this requirement. Yeah, I was looking into this as I was writing the explainer, along with uses of signal abort. I think either way should work, but I've been leaning towards replacing existing uses of follow with the new primitive since it doesn't modify existing signals (which seems safer [^1]). I added the requirement to the explainer, and I'm planning to start working on draft PRs in conjunction with a prototype and tests soon.

[^1]: E.g. there's a warning in the Streams spec (bottom of this section) not to follow or signal abort the stream’s signal since it would "interfere with the normal use of this signal to respond to the stream being aborted." It's possible signal abort could be made private since I think the couple of specs that use it don’t need to.

annevk commented 2 years ago

It might be worth taking https://github.com/whatwg/fetch/issues/1287 into account here, although I'm not sure how much we want to say about GC.