When should we define a function as async
A function needs to be defined async if you intend to possibly use the
await keyword inside it.
If a function is returning Promise, it MUST be async If a function
depends on an async function, it **MUST be async A further question could be, if one function only contains some simple then calls to promise, should it become an async function and use await in all possible cases to eliminate then calls?
No, it's possible to have legitimate use cases where this is not the case, for example:
async function foo() { ...} // queries an API
async function bar() { ... } // queries an API
function fooBar() {
return Promise.all([foo(), bar()]);
}
It's a contrived simplified example but the point is you might have
functions that work on promises that should not themselves be async.
For example, in your updateUser function, you can remove async and
await and get the same value (as you observed in growUp1).
To clarify, there is no semantic distinction in your examples between an async function and a regular function that returns a promise - it's just syntax sugar - just like generators and regular functions that return iterables.
This is possibly a code style related question, I studied a little deeper so this is how I currently learned:
If you want a special Promise (subclass or extended), you should not use async function since it casts the return value to a standard Promise
If you want to return a promise and attach callbacks to it (not returning promise that spawns by then), you should not use async
function foo() { var waiting = fetchResource(); // Since this code you should not use async functions waiting.then(logMessage); return waiting; } After all above cases, it is still OK to use none async functions that returns Promise, but it’s quite hard to determines if one method is actual async (with Promise) or sync (immediately return values), so I may preferr to mark all async function async for better read experience
Never write return await xxx;, it seems useless either xxx is a promise or not
Anyway this is not an issue about spec itself, it’s more like an open discussion, thanks for reply :)
Best
Gray Zhang
在 2015年6月3日 下午4:18:14, Gruenaum Benjamin (benjamingr at gmail.com) 写到:
A function needs to be defined async if you intend to possibly use the await keyword inside it.
If a function is returning Promise, it MUST be async If a function depends on an async function, it **MUST be async A further question could be, if one function only contains some simple then calls to promise, should it become an async function and use await in all possible cases to eliminate then calls?
No, it's possible to have legitimate use cases where this is not the case, for example:
async function foo() { ...} // queries an API
async function bar() { ... } // queries an API
function fooBar() {
return Promise.all([foo(), bar()]);
}
It's a contrived simplified example but the point is you might have functions that work on promises that should not themselves be async.
For example, in your updateUser function, you can remove async and await and get the same value (as you observed in growUp1).
To clarify, there is no semantic distinction in your examples between an async function and a regular function that returns a promise - it's just syntax sugar - just like generators and regular functions that return iterables.
es-discuss mailing list
es-discuss at mozilla.org
mail.mozilla.org/listinfo/es
If you want a special Promise (subclass or extended), you should not use
async function since it casts the return value to a standard Promise
Right, there was a proposal that let you override how await works ( jhusain/compositional-functions) but I don't think it's currently actively persued (Jafar, feel free to correct me here).
If you want to return a promise and attach callbacks to it (not returning
promise that spawns by then), you should not use async
This is also correct.
it’s quite hard to determines if one method is actual async (with
Promise) or sync (immediately return values), so I may preferr to mark all async function async for better read experience
I don't think the distinction is correct. For the consumer - it is irrelevant if a function is async or just returns a promise. If you're writing an API and your function sometimes return promises it is best to make them always return promises - more generally if a function is sometimes asynchronous (with callbacks too) it should always be asynchronous.
Never write return await xxx;, it seems useless either xxx is a promise
or not
Yes, unless of course you're also doing other things inside the function.
Anyway this is not an issue about spec itself, it’s more like an open
discussion, thanks for reply :)
Correct - I'm in no position to tell you what you can and cannot do but in the future I think it is best to ask these questions in Stack Overflow, IRC and on discussion groups. If you have issues about style, usage or anything else that is not the spec it is best to keep them off esdiscuss which is quite a noisy list anyway :)
Feel free to send me an email (rather than the whole list) if you have
other issues with async that are not spec related.
I asked it on StackOverflow but they say it is not best fit for SO, so I tried to get some help here
If one of my function:
Returns a promise
Do not need to await any other functions Do not create promise itself, it just return a promise returned by another function Do not call then or catch on promises so it does not involve further async flows Should this function be async?
For example:
async function updateUser(user) { return await fetch('/some/url', {body: JSON.stringify(data)}); }
function growUp1(user) { user.age++; return updateUser(user); }
async function growUp2(user) { user.age++; return await updateUser(user); } I think the growUp1 is more simple and have neater code with better performance after babel transformation (since less async generators are involved), and growUp2 is more robust when updateUser switches between async and sync.
Should we possibly enforce:
If a function is returning Promise, it MUST be async If a function depends on an async function, it **MUST be async A further question could be, if one function only contains some simple then calls to promise, should it become an async function and use await in all possible cases to eliminate then calls?
Best
Gray Zhang
I asked it on StackOverflow but they say it is not best fit for SO, so I tried to get some help here If one of my function: Returns a promise Do not need to await any other functions Do not create promise itself, it just return a promise returned by another function Do not call then or catch on promises so it does not involve further async flows Should this function be async? For example: async function updateUser(user) { return await fetch('/some/url', {body: JSON.stringify(data)}); } function growUp1(user) { user.age++; return updateUser(user); } async function growUp2(user) { user.age++; return await updateUser(user); } I think the growUp1 is more simple and have neater code with better performance after babel transformation (since less async generators are involved), and growUp2 is more robust when updateUser switches between async and sync. Should we possibly enforce: If a function is returning Promise, it MUST be async If a function depends on an async function, it **MUST be async A further question could be, if one function only contains some simple then calls to promise, should it become an async function and use await in all possible cases to eliminate then calls? Best regards Gray Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150603/30025b99/attachment.html>