A promise that resolves after a delay.
I think this is a reasonable API, but ES is not the spec for it. ES does not have a proper concept of an event loop, and definitely not a proper concept of time. Note that setTimeout is not defined in ES, but instead in HTML: html.spec.whatwg.org/#dom-windowtimers-settimeout
It might be worth proposing this at whatwg/html/issues; the form would probably be a new global function.
However, the biggest problem with such proposals is that they lack a way to clear the timeout. That is waiting for cancelable promises to arrive, which I am working on but I anticipate being contentious due to many differing opinions on the best way to do them.
So my best guess is that if you did propose this to HTML people would shout it down on the basis of not being able to cancel the timeout, and you'd have to wait until we figure out cancelable promises. But it's probably worth trying anyway.
Chiming in just to underline that setTimeout and setInterval accepts extra arguments since about ever so that the following is eventually all you need.
new Promise(r => setTimeout(r, 1000));
new Promise(r => setTimeout(r, 1000, "some value"));
Best
Here's a quick plug for my prfun
library (cscott/prfun)
which implements this as Promise.delay(1000)
.
API at: cscott/prfun#promisedelaydynamic-value-int-ms--promise
You can also do return somepromise.delay(100)
which resolves to the same
value as samepromise
, just 100 ms later.
as pointed out offlist, the second line of my previous snippet was to shortcut the following:
new Promise(resolve => setTimeout(() => resolve("some value"), 1000));
assuming "some value"
was static. In case it's not the `new Promise(r =>
setTimeout(r, 1000)).then(()=>"some value");` is the way I'd go.
Best
Easy to write yourself:
function wait(ms) {
return function(v) {
return new Promise(resolve => setTimeout(() => resolve(v), ms));
};
}
Now you can do
Promise.resolve(42) . then(wait(1000)) . then( /* cb */);
and the 42 will get passed through the callback.
On 2/3/16 11:39 PM, Bob Myers wrote:
Promise.resolve(42) . then(wait(1000)) . then( /* cb */);
With ES6 I prefer the straightforward:
var wait = ms => new Promise(resolve => setTimeout(resolve, ms));
Promise.resolve(42) . then(() => wait(1000)).then(() => { /* cb */ });
Too simple to standardize IMHO.
.: Jan-Ivar :.
I'd agree that we don't need Promise.p.wait
, but I think eventually, ES
is going to need a spec for an event loop. Or at least an interoperable
spec agnostic of runtime should be created somewhere, like the eventual
module loader.
I think it would be super useful to be able to do something like:
Promise.after(1000).then( /* cb */ );
and have the promise resolve after 1000 milliseconds.
The promise would just resolve with the same value (in this case 1000) but could easily delay resolving another value like so:
Promise.after(1000).then(() => "other value");
instead of currently having to use a setTimeout:
new Promise(resolve => setTimeout(() => resolve("some value"), 1000));
I believe
Promise.after
would be so much more readable and useful.I am not sure if the name
after
is the best name,wait
,when
,sleep
are possible names or maybe there is a better name I haven't even thought of.