AFAIK bluebird did: https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise
But I agree once you've made Promises more complex than events ( xhr in this case ) nobody wins :-/ Although, specially for fetch or anything network related, there **must** be a way to bloody cancel that! ....right? On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith <[email protected]> wrote: > The discussion on that github issue surrounding promise subclassing makes > my head spin, especially when it comes to working out how cancelation is > supposed to flow through a graph of promise dependencies. We should be > wary of adding complexity to the core. > > The simple way to view the situation is to say that promises are simply > transparent containers for asynchronous values. Control capabilities should > therefore be represented by a separate abstraction. This will help keep > complexity at the edges. > > Has any library experimented with the cancelation token approach yet? > On Feb 27, 2015 1:46 AM, "Anne van Kesteren" <[email protected]> wrote: > >> As a heads up, there's some debate around the fetch() API how exactly >> request termination should work and how that affects promises: >> >> https://github.com/slightlyoff/ServiceWorker/issues/625 >> >> The WebRTC WG has also been discussing canceling in the context of >> terminating a request for permission from the user. I think they >> decided to postpone for now until there's a bit more progress on what >> cancelable promises means, but I would not expect everyone to wait >> forever. >> >> >> -- >> https://annevankesteren.nl/ >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
