This PR clarifies the addTeardown() API, which is just syntactic sugar over responding accordingly to Subscriber#signal. I'm honestly not 100% sure if we need it, but it does seem like a nice first-class convenience API to get around the pesky is-this-signal-already-aborted check that would have to be made by ever subscriber with a clean-up function, at least until AbortSignal gets an API like whenAborted().
My only concern here is that it might be confusing if we expose both Subscriber#signalandSubscriber#addTeardown(), when you really only need one or the other. If we're going to have this first-class API, I kind of lean towards not exposing Subscriber#signal anymore, and pushing people to use addTeardown() exclusively, but what do you think @benlesh?
This PR clarifies the
addTeardown()API, which is just syntactic sugar over responding accordingly toSubscriber#signal. I'm honestly not 100% sure if we need it, but it does seem like a nice first-class convenience API to get around the pesky is-this-signal-already-aborted check that would have to be made by ever subscriber with a clean-up function, at least untilAbortSignalgets an API likewhenAborted().My only concern here is that it might be confusing if we expose both
Subscriber#signalandSubscriber#addTeardown(), when you really only need one or the other. If we're going to have this first-class API, I kind of lean towards not exposingSubscriber#signalanymore, and pushing people to useaddTeardown()exclusively, but what do you think @benlesh?