You can already mitigate it with `await undefined` or similar. On Wed, Nov 30, 2016, 12:16 Jeremy Martin <[email protected]> wrote:
> When mixing callback logic with async functions, it's up to the programmer > to choose the callback semantics that they want. > > Forcing execution of the async function into a future task prohibits logic > that requires immediate invocation of a callback, whereas the existing > semantics allow for both immediate and future invocation. At any rate, I > assume this ship has sailed. This is a pretty foundational change to make > in a Stage 4 proposal. > I wouldn't quite argue that. Delaying the initial run by a tick won't be much of a change, IMHO. Most async functions don't require synchronous action because that's not what they're designed for. It's also generally bad practice to rely on promise scheduling order anyways. I do agree with you that it is a bad idea, even irrespective of the feature's status, for the above reason of things like `ev.preventDefault()`. > On Tue, Nov 29, 2016 at 11:15 AM, Paolo Amadini <[email protected] > > wrote: > > As I understand it, as currently specified, the first part of an async > function, before the first await statement, is executed synchronously. > > This is subject to subtle bugs when used with callbacks, which may be > common with DOM event handlers. Take the following code example: > > ```js > let someCondition = false; > > async function onClick(event) { > if (someCondition) { > await Promise.resolve(); // Or any other async function. > } > event.stopPropagation(); > } > > let called = false; > onClick({ stopPropagation: () => called = true }).catch(console.error); > console.log("Called:", called); > ``` > > The callback is called synchronously or not based on someCondition. > > The behavior would be more consistent if the first part of the function > was scheduled at the next microtask, in other words it would be like > having an implicit `await Promise.resolve();` at the beginning of every > async function. > > This would not allow async functions to invoke callbacks for DOM events > at all, without wrapping them in a normal function. Using an async > function as an event handler directly wouldn't be a good practice > anyways, because if the async function throws an exception it would > lead to an unhandled rejection, as if the `.catch()` in the example above > was missing. > > Is the current scheduling a deliberate choice? > > I'm asking because async functions have just been implemented in the > Mozilla JS engine, and it would be good to know that this is what we > want before async functions get widespread use in our codebase. > > Cheers, > Paolo > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Jeremy Martin > 661.312.3853 > http://devsmash.com > @jmar777 > _______________________________________________ > 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
