Mistakes we make using JavaScript Promises • Hacker News Board

Re: Mistakes we make using JavaScript Promises

#51

Post by seniorsassycat » Fri, Jul 05, 2019, 4:09 PM UTC

matt-attack wrote: post #48

seniorsassycat wrote: post #33

_any_ function that returns a promise should have the `async` modifier - even if `await` isn't used. A function may return a promise or throw an exception. An `async` function may only return a promise. async functions cannot throw exceptions. ``` // This code sucks but you might have to write it if `get` isn't an async function. try { get().catch(_ => /* handle async errors /) } catch { / handle sync errors */ } ```

Interesting about adding async. I actually didn’t know it eliminated the possibility of it throwing an error. What happens if it explicitly throws an error?

An async function that throws and error will return a promise that will reject with the thrown error.

Re: Mistakes we make using JavaScript Promises

#52

Post by tehlike » Fri, Jul 05, 2019, 4:28 PM UTC

CraftThatBlock wrote: post #28

tehlike wrote: post #19

Earlier quoted context omitted.

Some older libraries will still be callback driven, and one important thing is always resolving or rejecting promise.

If it's callback driven, is it a Promise mistake or a callback mistake? I don't think it would apply here

Most of the time first thing i do is to wrap the library call in a promise. Callbacks are really bad after a few nested ones, bht promise doesnt eliminate all the problrms

Re: Mistakes we make using JavaScript Promises

#53

Post by Nullabillity » Fri, Jul 05, 2019, 4:29 PM UTC

pault wrote: post #49

peq wrote: post #34

Earlier quoted context omitted.

It's easy to run tasks in parallel with just "await". Just start your tasks without await, store the promise in a variable, and then use await later when you actually need the value.

That's fine, but you'll still only be able to block on one promise at a time. If you want to wait until all promises have resolved you still have to use Promise. all.

Promises are started eagerly, so

    const xP = getX();
    const yP = getY();
    const x = await xP;
    const y = await yP;

is just as parallel as

    const [x, y] = Promise.all([getX(), getY()]);

Re: Mistakes we make using JavaScript Promises

#54

Post by korla » Fri, Jul 05, 2019, 5:49 PM UTC

hoorayimhelping wrote: post #37

korla wrote: post #32

Earlier quoted context omitted.

How does the resolve function work here? It is passed an object where one property is an object and the other a promise. The next then suddenly receives the resolved location..?

The argument passed to `resolve` gets returned from the resolve function and becomes available to any handler that handles it with `then`. In the above example, the object is being destructured as part of the arguments. The destructuring is probably what's tripping you up. // straightforward, no magic const simpleFunction = function() { return Promise.resolve({ name: 'simpleObject' }); } simpleFunction().then(functio…

No that is not what is tripping me up, or happening. The other answer explained it, some library code was executed aeaiting the location-promise.

Re: Mistakes we make using JavaScript Promises

#55

Post by korla » Fri, Jul 05, 2019, 5:51 PM UTC

thedufer wrote: post #40

korla wrote: post #32

Earlier quoted context omitted.

How does the resolve function work here? It is passed an object where one property is an object and the other a promise. The next then suddenly receives the resolved location..?

It iterates over all key/value pairs. For each value, if it is a promise it waits for it and replaces it with the result, while non-promises are left as-is. This is a fairly common function to have in promise libraries.

That was my point. It’s not obvious to the reader that this is better since it’s a non-standard way of resolving promises. But it looks neat. I’ve never seen it, what library do you have experience with that does it this way?

Re: Mistakes we make using JavaScript Promises

#56

Post by thedufer » Sat, Jul 06, 2019, 3:37 PM UTC

korla wrote: post #55

thedufer wrote: post #40

Earlier quoted context omitted.

It iterates over all key/value pairs. For each value, if it is a promise it waits for it and replaces it with the result, while non-promises are left as-is. This is a fairly common function to have in promise libraries.

That was my point. It’s not obvious to the reader that this is better since it’s a non-standard way of resolving promises. But it looks neat. I’ve never seen it, what library do you have experience with that does it this way?

I've been out of the JavaScript world for years now, but I last used Bluebird which has Promise.props[1] with this behavior.

[1] http://bluebirdjs.com/docs/api/promise.props.html

Re: Mistakes we make using JavaScript Promises

#57

Post by pault » Tue, Jul 09, 2019, 7:49 PM UTC

Nullabillity wrote: post #53

pault wrote: post #49

Earlier quoted context omitted.

That's fine, but you'll still only be able to block on one promise at a time. If you want to wait until all promises have resolved you still have to use Promise. all.

Promises are started eagerly, so const xP = getX(); const yP = getY(); const x = await xP; const y = await yP; is just as parallel as const [x, y] = Promise.all([getX(), getY()]);

Whoops, you're right! I hadn't thought it through.

Re: Mistakes we make using JavaScript Promises

#58

Post by franciscop » Wed, Jul 10, 2019, 4:48 AM UTC

matt-attack wrote: post #46

fooey wrote: post #27

Earlier quoted context omitted.

Instead of subtle nesting, I would have passed through the user as part of the result of the second promise. get('//data.com/user) .then(user => resolve({user, location: get('//data.com/user')})) .then(({user, location}) => createEntry(user, location)) .then(response => { // handle response }).catch(err => { // handle failure }); Async/await is much cleaner now though.

I affably don’t know how anyone considers the .then syntax to be any better than the original callback hell version. Especially if you want your error handlers to be unique and to affect the flow. Sorry but the common shared catch at the end doesn’t usually suffice in the code I write. I find the async/await form he alludes to at the end to be the only form that improves upon the original callback version.

It's not much more clear, but it is a standard, which has many advantages:

- Learn how .then()/.catch() works once and it's the same for all libraries.

- Can test against a common API.

- Can combine operations easily like with Promise.all(), which was very difficult with callbacks.

- Chaining is much better since you can return a promise within a promise, which allows for conditional promises.

- No nesting/right shifting, keeping the structure flatter.

Re: Mistakes we make using JavaScript Promises

#59

Post by matt-attack » Wed, Jul 10, 2019, 7:44 PM UTC

franciscop wrote: post #58

matt-attack wrote: post #46

Earlier quoted context omitted.

I affably don’t know how anyone considers the .then syntax to be any better than the original callback hell version. Especially if you want your error handlers to be unique and to affect the flow. Sorry but the common shared catch at the end doesn’t usually suffice in the code I write. I find the async/await form he alludes to at the end to be the only form that improves upon the original callback version.

It's not much more clear, but it is a standard, which has many advantages: - Learn how .then()/.catch() works once and it's the same for all libraries. - Can test against a common API. - Can combine operations easily like with Promise.all(), which was very difficult with callbacks. - Chaining is much better since you can return a promise within a promise, which allows for conditional promises. - No nesting/right shif…

async/await has all of those same advantages plus more I believe (and I should add I agree with all of them).

Re: Mistakes we make using JavaScript Promises

#60

Post by franciscop » Thu, Jul 18, 2019, 9:50 AM UTC

matt-attack wrote: post #59

franciscop wrote: post #58

Earlier quoted context omitted.

It's not much more clear, but it is a standard, which has many advantages: - Learn how .then()/.catch() works once and it's the same for all libraries. - Can test against a common API. - Can combine operations easily like with Promise.all(), which was very difficult with callbacks. - Chaining is much better since you can return a promise within a promise, which allows for conditional promises. - No nesting/right shif…

async/await has all of those same advantages plus more I believe (and I should add I agree with all of them).

Async/await is syntax sugar on top of .then(); without the standardization of promises with .then(), async/await would have been A LOT harder to get cross projects. Ofc async/await is waaay better than .then(), but you were talking about async/await vs callbacks, and so my points :)