- From: Domenic Denicola via GitHub <sysbot+gh@w3.org>
- Date: Sat, 29 Sep 2018 00:48:32 +0000
- To: public-web-nfc@w3.org
Strong +1 to using AbortController. As @kenchris has said, it is not related to network operations, and it's just how you cancel async operations on the platform. I can understand how it can seem complex in isolation. But as with promises, streams, etc., reusing the same primitive everywhere has multiplicative effects throughout the platform. In particular, there's a common pattern of using a single AbortSignal for a bunch of ongoing operations, and then aborting them (with the corresponding AbortController) when e.g. the user presses cancel, or a single-page-app navigation occurs, or similar. So the minor extra complexity for an individual API leads to a large reduction in complexity when used with multiple APIs together. Right now AbortController is only used in Fetch and Web Locks to my knowledge. But we're soon going to be using it in Streams, a promise-returning version of setTimeout (https://github.com/whatwg/html/issues/617), and probably other upcoming APIs like writable files. Being able to cancel all these things together using a single tool is the dream, just like today you can use a single tool (promises) for async operations. > In some cases we cannot guarantee cancellation. What happens then? A call to `abort()` is a _request_ to abort. How you react to it depends on your spec. We could have given it a verbose name like `requestAbort()` but we went for brevity. -- GitHub Notification of comment by domenic Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/147#issuecomment-425601613 using your GitHub account
Received on Saturday, 29 September 2018 00:48:34 UTC