151–160 of 227 posts
Earlier quoted context omitted.
Why do you need to put await before res.json?
Someone correct me if I'm wrong here, this is just my hunch - but according to the fetch spec, res.json returns a promise, which are async. I'm assuming so you have the chance to handle errors as a result of malformed JSON.
The moment I started using async await (with babel) combined with the new fetch API so many libraries got obsolete. Getting data is as easy as: async function main () { try { const res = await fetch('https://api.github.com/orgs/facebook'); const json = await res.json(); console.log(json); } catch (e) { // handle error } } So I am quite happy when this lands in modern browsers asap.
What do you use for the new fetch api on node?
Earlier quoted context omitted.
> To correct this a little, the proper way to catch with promises is .catch, not with a try-catch inside a .then - that is an antipattern. Depends whether you can survive and continue from an exception inside the .then to the next step or not.
Promises catch exceptions and automatically reject: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... . I've never seen a promise not do this - do you have an example where this is not the case?
e.g, naive example:
.then(() => {
var foo;
try {
foo = getFoo();
} catch (err) {
foo = 10; //some default value
}
return foo;
}).then( (foo) =>
So you might not want to reject automatically inside then if getFoo raises, but recover and return a default value.
Earlier quoted context omitted.
Would it? IIRC Promise.all will run the two responses in parallel, but will not send the first into the map before both are finished.
Promise.all doesn't "run" anything. Promises "run" the very moment they come into existence. Promise.all simply tells you if and when all of them are settled. It depends on your Promises whether they are doing something outside the single threaded event loop or not for them to be parallel or not.
Yeah, I know that. I don't mean .all schedules them to run (e.g. like doing thread.start()), of course they auto start.
By run I mean that inside the .all implementation syncs with you about their completion ("tells you when all of them are settled").
>It depends on your Promises whether they are doing something outside the single threaded event loop or not for them to be parallel or not.
That's not the point though, which was the parent's assertion about whether the first to resolve will escape .all and go into the .map, which I don't think is the case.
Earlier quoted context omitted.
Can anyone point to a good explanation why this is preferable to cooperative threads (coroutines)? I.e. the above code could easily be written as function main() { try { const res = fetch('https://api.github.com/orgs/facebook'); // yield here const json = res.json(); // yield here console.log(json); } catch (e) { // handle error } } and the runtime would automatically yield this coroutine and let other coroutines run…
Perhaps this is the reason: Is it possible to have a yield inside a called function (i.e., not the generator function itself)? Last time I checked this was not allowed (?) Anyway, if so, I would strongly prefer this over a async/await construct, which is less general.
Call a generator function from a generator function? Sure, you just need to transitively yield its content using `yield* [[expr]]` (which delegates part of the iteration to the `expr` generator)
The moment I started using async await (with babel) combined with the new fetch API so many libraries got obsolete. Getting data is as easy as: async function main () { try { const res = await fetch('https://api.github.com/orgs/facebook'); const json = await res.json(); console.log(json); } catch (e) { // handle error } } So I am quite happy when this lands in modern browsers asap.
Can anyone point to a good explanation why this is preferable to cooperative threads (coroutines)? I.e. the above code could easily be written as function main() { try { const res = fetch('https://api.github.com/orgs/facebook'); // yield here const json = res.json(); // yield here console.log(json); } catch (e) { // handle error } } and the runtime would automatically yield this coroutine and let other coroutines run…
1) Yielding is decoupled from the asynchronous action itself, giving the caller fine-grained control when to yield. For example, with async/await, management of parallel operations is straight-forward:
var promise = fetch('https://foo.com/');
// ... do something useful while the fetch runs ...
var result = yield promise;
var promise1 = fetch('https://foo.com/');
var promise2 = fetch('https://bar.com/');
[result1, result2] = yield Promise.all(promise1, promise2 );
async function f() {
var p = fetch('https://foo.com/');
p = p.then(function(inbetweenResult) {return new Promise(function(resolve) {
oldapi.onresult = resolve;
oldapi.process(inbetweenResult);
})});
return await p;
}
f().then(...)
Earlier quoted context omitted.
Perhaps this is the reason: Is it possible to have a yield inside a called function (i.e., not the generator function itself)? Last time I checked this was not allowed (?) Anyway, if so, I would strongly prefer this over a async/await construct, which is less general.
> Is it possible to have a yield inside a called function (i.e., not the generator function itself)? Call a generator function from a generator function? Sure, you just need to transitively yield its content using `yield* [[expr]]` (which delegates part of the iteration to the `expr` generator)
const res = fetch('https://api.github.com/orgs/facebook'); // yield here
Of course, fetch(), could yield a status specifying whether its calling-ancestors should yield, but this can become unwieldy very quickly, and might require an exception mechanism of its own. Better to just let called functions yield.
Earlier quoted context omitted.
Promises catch exceptions and automatically reject: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... . I've never seen a promise not do this - do you have an example where this is not the case?
As I wrote in depends whether you can survive and continue from an exception inside the .then to the next step or not -- not about how the promise would handle an exception, but whether you want it to handle it or you want to survive and handle it yourself. e.g, naive example: .then(() => { var foo; try { foo = getFoo(); } catch (err) { foo = 10; //some default value } return foo; }).then( (foo) => etc. So you might…
.then(getFoo)
.catch(err => 10) //some default value
.then( (foo) =>Earlier quoted context omitted.
Someone correct me if I'm wrong here, this is just my hunch - but according to the fetch spec, res.json returns a promise, which are async. I'm assuming so you have the chance to handle errors as a result of malformed JSON.
Promises are used for catching errors?
Why is "async" keyword needed? Can't JS engine infer from the use of "await" in a function that this function need to be async? I'm using async/await for a while now, and so many times I've introduced bugs in my code because i forget to put "async" in front of the function, or put "async" in front of wrong function. It's simply annoying to go back and put "async" when in middle of writing a function I realise I need…
I'd agree with you, and I'm keen to learn the real answer. My guess would be that some initial optimizations can occur without having to also parse and analyze the body of a function, potentially having significant performance benefits to reducing the boot time of a program.
So `await (x)` is ambiguous. Making the outer function `async function () {...}` makes await a keyword inside that function, allowing them to move forward with that syntax in a non-breaking way as the parser now knows that there can't be a function named `await` inside any async functions.