Discuss
  • await and promise

await and promise

# Mark Volkmann (11 years ago)

I looked at the "async" keyword examples in Traceur for the first time today. Cool stuff!

IIUC, when a function is annotated with the async keyword, it can use "await" and the "done" function is magically defined.

An interesting corollary to that idea would be to introduce a "promise" keyword that can be used to annotate a function. It would magically define the functions "resolve" and "reject". It would allow a function like this:

function foo() {
  return new Promise((resolve, reject) => {
    // some code that eventually calls resolve or reject
  });
}

to be written like this:

promise function foo() {
  // some code that eventually calls resolve or reject
}

Is this a crazy idea? Perhaps if this was available, it would be very rare to actually write "new Promise(" in code.

# Erik Arvidsson (11 years ago)

The done function is injected by the Traceur test runner for async tests. It is standard mocha stuff.

# Mark Volkmann (11 years ago)

I have seen that in Mocha tests, but this code looked different to me. I'm looking at google/traceur-compiler/blob/master/test/feature/AsyncFunctions/AlphaRenaming.js . I thought to use done in a Mocha test you have to have a parameter named "done" in the test function. I suppose I was wrong about that.

# Domenic Denicola (11 years ago)

new Promise( should be seen as a bridge, used only for interfacing with asynchronicity that does not use promises. (Such as Nodebacks, setTimeout, or older DOM interfaces.) Otherwise you can just return the promise and chain off of it, or await it. (There are some other use cases, such as writing promise combinators, but they are fairly advanced; "library code" and not "application code.")

As such I don't think it's fruitful to introduce new syntax to help these cases. It's fine for them to have the extra few characters and indentation level. The focus should instead be on replacing such older interfaces with promise-returning ones.