EDeduardolundgren·Dec 20, 2016
Cancellable Promises are a reality in our software stack for years in Liferay and related open source projects. JavaScript is a flexible language and this is what makes it what it is, fits into different realities and skill levels. Optionally, you can use Object.defineProperty() to define how your object behaves, if it's configurable, enumerable, writable and so on. You can Object.freeze() to freeze an object. Having a Promise that the consumer can define whether or not it can be cancelled makes sense in general. There are lots of use-cases that the consumer can safely decide if canceling a promise or chaining of promises is problematic or not, e.g. ajax calls, async life-cycle of a UI component.
There are many good arguments about cancellation tokens vs promise.cancel() on ES Discuss https://esdiscuss.org/topic/cancellation-architectural
Read the rest
-obser.... One argument that is not accurate is that "cancellation is heterogeneous it can be misleading to think about canceling a single activity". In most systems, it's implemented expecting that async operations can be cancelled, intentionally or not (network problems for example). There is no single answer for this problem, it can be wrong and dangerous, or it can be safe and predictable, that all depends on how the consumer utilizes it.
Domenic mentioned in the proposal https://github.com/tc39/proposal-cancelable-promises/issues/... that most of Googlers on TC39 are against cancellable promises, on the other hand Google Closure Library has a very robust implementation brought from labs in 2014 by Nanaze https://github.com/google/closure-library/commit/74b27adf7. It's heavily used on large real world async applications, such as Gmail, G+, Docs. It shows clearly that there is a real space for cancelling promises without being dangerous.