Promise-returning delay function

Andrea Giammarchi andrea.giammarchi at
Tue Oct 28 01:42:07 PDT 2014

canceling should **not** pass through any errorback chain... Canceling is like an explicit abort on xhr ... Not an error, not a fulfillment, it's a third state: cancelled 

-----Original Message-----
From: "C. Scott Ananian" <ecmascript at>
Sent: ‎27/‎10/‎2014 19:39
To: "Andrea Giammarchi" <andrea.giammarchi at>
Cc: "Tab Atkins Jr." <jackalmage at>; "Mark S. Miller" <erights at>; "Domenic Denicola" <domenic at>; "Mark Miller" <erights at>; "es-discuss list" <es-discuss at>
Subject: Re: Promise-returning delay function

There's already a way to cancel a Promise -- use its `reject` function.  eg.

var reject;
Promise.delay(100/*ms*/).then(function() { reject(new Error('took too
long')); });
return new Promise(function(resolve, _reject) {
  reject = _reject;

There's no need to rethink or redesign anything.

for a nice example, borrowed from `bluebird`.

On Mon, Oct 27, 2014 at 3:20 PM, Andrea Giammarchi
<andrea.giammarchi at> wrote:
> I thought promises were introduced to simply the "whenever it happens"
> pattern ... using a delay seems a pretty pointless feature to me and
> setTimeout worked so far (15 years?) pretty well and it is cancelable.
> Regardless delay though, canceling, beast or not, should be considered
> before all these changes will make it "impossible" to implement, IMO
> On Mon, Oct 27, 2014 at 2:52 PM, Tab Atkins Jr. <jackalmage at>
> wrote:
>> On Mon, Oct 27, 2014 at 3:21 AM, Andrea Giammarchi
>> <andrea.giammarchi at> wrote:
>> > Not sure if discussed already but I believe `.cancel()` or
>> > `.forgetAboutIt()` mechanism should be proposed before introducing any
>> > `.delay()`
>> >
>> > Promises often put developers in unmanaged roads where things keep being
>> > "forgotten" and/or impossible to drop without ending up in the next
>> > chain,
>> > undesired, or the error stack, even less desired.
>> >
>> > What I mean is that if `setTimeout` is a desired pattern to replicate
>> > through `.delay(ms)`, but I really don't understand why that would be a
>> > desired pattern at all, `clearTimeout` functionality should be
>> > considered as
>> > well.
>> >
>> > A generic `.cancel()` would be most likely the easier approach but it
>> > should
>> > be implemented upfront.
>> Cancelable promises are a completely different beast; it's not just a
>> matter of adding a new method to Promise.prototype, it's changing the
>> data structure pretty fundamentally.  Suddenly you have a new
>> value-affecting capability, but it's exposed outside of the
>> constructor.  You need to be able to react to a cancellation, so you
>> can actually cancel the work being done, and possibly resolve the
>> promise to some default value (or error).
>> A promise that auto-resolves after a timeout, on the other hand, is a
>> straightforward utility function of obvious usefulness, and requires
>> no additional work:
>> Promise.delay = function(ms) {
>>   return new Promise(function(r) { setTimeout(r, ms); });
>> }
>> (Not tested, but this should be approximately right.)
>> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list