thanks for this great library, it's much appreciated 🙏
I came across a use case recently, where I had to deal with groups of requests and also needed to abort requests on the "group level". Looking at the Fetch API, I found that the easiest way to achieve this is by passing the signal of a single AbortController instance to all requests of such a group.
Currently, this library creates a dedicated AbortController instance per request, which made the scenario mentioned above a bit difficult to implement. I adapted the library for my use case, by adding an optional :abort-signal to the :fetch map. This allows the user to opt out of the internal request abort handling and to bring their own AbortController.
I thought this feature might come in handy for others as well, so here we go :)
Pros:
More flexibility for the user concerning request aborting
Multiple requests can be handled by a single AbortController
Convenience feature for highly asynchronous use cases: when trying to dispatch a request using a signal that was already aborted, the request is never dispatched.
Cons:
It might be confusing for users when there are two mutually exclusive ways to abort requests.
Hi,
thanks for this great library, it's much appreciated 🙏
I came across a use case recently, where I had to deal with groups of requests and also needed to abort requests on the "group level". Looking at the Fetch API, I found that the easiest way to achieve this is by passing the signal of a single AbortController instance to all requests of such a group.
Currently, this library creates a dedicated AbortController instance per request, which made the scenario mentioned above a bit difficult to implement. I adapted the library for my use case, by adding an optional
:abort-signalto the:fetchmap. This allows the user to opt out of the internal request abort handling and to bring their own AbortController.I thought this feature might come in handy for others as well, so here we go :)
Pros:
Cons: