-
Notifications
You must be signed in to change notification settings - Fork 285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal AbortSignal.prototype.filter(compare) #1280
Comments
With proposals like this it helps to have some information about adoption in libraries, code in the wild, other languages with signals, questions on Stack Overflow, etc. I.e., a bit more data that demonstrates this is worth investing time in. |
I don't think we should unilaterally add error filtering to |
Do you mean adding filter to the Promise prototype? I didn't think AbortSignal inherited anything from promises? Or just copy the details of a Promise filter to AbortSignal later? |
I mean, we have multiple primitives in the platform which forward errors to users. We shouldn't add a filtering method to just one. So yes, something similar to
|
What problem are you trying to solve?
There is now an
AbortSignal.any([a, b, c])
that makes it possible to combine multiple signals, but there is currently no way to split a an AbortSignal. I therefore propose the instance methodAbortSignal.prototype.filter(compare)
, which would return a newAbortSignal
that only triggers if the reason matches some condition. For example:The above example creates a signal that will only trigger if the reason matches that of
AbortSignal.timeout(ms)
. If the reason doesn't match, then the returned signal will never trigger (since abort signals only ever trigger once).What solutions exist today?
It is fairly easy to implement this today as a separate function (to not pollute the prototype):
How would you solve it?
The above function could be placed on the AbortSignal prototype:
Anything else?
No response
The text was updated successfully, but these errors were encountered: