Discuss
  • Add new function waitFor

Add new function waitFor

# Eugene Melnikov (7 years ago)

It’d be great to see native implementation of waitFor function. This function is used a lot in test frameworks and sometimes it’s necessary to wait something via polling. The syntax should be await waitFor(function/primitives, timeout). Once function in first argument return anything except false, null or undefined next line of code will be executed. Second argument means period of time in ms to run function from first argument. Returned value of waitFor will be forwarded from executed function. In case first argument if primitive the first argument will be returned after delay specified in second argument. So it will be easy to make simple delay async waitFor(true, 1000) instead of await new Promise(r => setTimeout(r, 1000)).

# Naveen Chawla (7 years ago)

Wouldn't it be more useful to have an async delay(milliseconds) function, which simply takes a number (as an alternative to setTimeout), instead of having to pass in a function whose code is executed and then the code after it??? I have suggested that here before, but it happens to be a browser spec feature thing, not a core language thing (at least not yet) - since setTimeout itself is not yet in the core language, as far as I know

# Michał Wadas (7 years ago)

I wish we can have annex like "if host environment supports scheduling tasks to run after certain time, it have to expose Promise.delay method working in following way:".

But it's unlikely to happen because TC39 opposes describing communication with outside world in spec.

# Isiah Meadows (7 years ago)

Just FYI, I did talk a while back to one of the TC39 people previously about the viability of encoding at least the low-level microtask execution stuff into the spec, and they explained that for both practical and theological reasons, there really was no way of doing it that wouldn't require substantial changes to the HTML spec as well as issues with other embedding use cases. (Node would actually be the least affected in this area.)

As for things like setTimeout/etc., ECMAScript is designed for way more than just browsers - it even runs on Arduino boards. Some runtimes that are geared towards embedded stuff deliberately don't even implement any form of dynamic evaluation, like Kinoma XS6 (ES6 runtime which also does not retain source code for Function.prototype.toString for ES-defined functions), and in those cases, you might only have a single core available in the hardware, making async timers, especially shorter ones, very unreliable and power-hungry to use.

Isiah Meadows me at isiahmeadows.com

Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com

# Michał Wadas (7 years ago)

For me it boils down to "implementations which already don't follow spec exactly won't be able to implement such new part of specification"...

Dynamic code generation with access to existing scope (sloppy mode direct eval) already puts strong constraints on spec-compliant implementation. Is it even considered issue?

# Mark Miller (7 years ago)

On Fri, Nov 17, 2017 at 1:50 PM, Michał Wadas <michalwadas at gmail.com> wrote:

For me it boils down to "implementations which already don't follow spec exactly won't be able to implement such new part of specification"...

Dynamic code generation with access to existing scope (sloppy mode direct eval) already puts strong constraints on spec-compliant implementation. Is it even considered issue?

Technically, in order to accommodate CSP, the EcmaScript spec already allows an implementation to refuse to dynamically evaluate code via evaluators, i.e., the eval function, the various function constructors, and the import expression.