Re: When should we define a function as async
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 ( https://github.com/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. Cheers. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: When should we define a function as async
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 regards
Gray Zhang
在 2015年6月3日 下午4:18:14, Gruenaum Benjamin (benjami...@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:
```js
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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 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:
```js
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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
When should we define a function as async
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
