Mistakes we make using JavaScript Promises

Post by tehlike » Fri, Jul 05, 2019, 3:58 AM UTC

gatherhunterer wrote: post #14

hayksaakian wrote: post #11

Hopefully with async/await we can all put this behind us. In my own projects, async/await has made improved readbility and reduced errors.

I have found cases in which async/await won’t cut it quite as cleanly as “return new Promise”. AWS Cognito’s API has functions that take an object parameter with properties onSuccess and onFailure. If these functions are being called with programmatically created values within promises you can use “await new Promise” but that means declaring an additional async/await function (and therefore a promise) that resolves w…

Post by ng12 » Fri, Jul 05, 2019, 4:23 AM UTC

paulhodge wrote: post #17

hayksaakian wrote: post #11

Hopefully with async/await we can all put this behind us. In my own projects, async/await has made improved readbility and reduced errors.

async/await helps a lot, but there are still a few common errors with them... 1) Not calling promises in parallel. Easy to do because it's impossible to run them in parallel with just "await", need to use Promise.all() or something. 2) Forgetting to write "await". If you try to use the return value then now you have a Promise object instead of the actual value. But the worst is when the code doesn't use the return va…

   const [foo, bar] = await [async1(), async2()]

Post by ailideex » Fri, Jul 05, 2019, 4:45 AM UTC

ng12 wrote: post #23

paulhodge wrote: post #17

Earlier quoted context omitted.

async/await helps a lot, but there are still a few common errors with them... 1) Not calling promises in parallel. Easy to do because it's impossible to run them in parallel with just "await", need to use Promise.all() or something. 2) Forgetting to write "await". If you try to use the return value then now you have a Promise object instead of the actual value. But the worst is when the code doesn't use the return va…

For the first I wonder if we could solve this with array syntax: const [foo, bar] = await [async1(), async2()]

Post by fooey » Fri, Jul 05, 2019, 4:50 AM UTC

franciscop wrote: post #6

This "solution" given here has a syntax error since you don't have access to `user` within the second then() callback: get("http://data.com/user") .then(user => get("http://data.com/location" + user.id)) .then(location => createEntry(user, location)) .then(response => { // handle response }).catch(err => { // handle failure }); Instead, back before async/await made things easier this nested pattern was used (notice t…

    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
      });

Post by gatherhunterer » Fri, Jul 05, 2019, 4:51 AM UTC

james-mcelwain wrote: post #20

gatherhunterer wrote: post #14

Earlier quoted context omitted.

I have found cases in which async/await won’t cut it quite as cleanly as “return new Promise”. AWS Cognito’s API has functions that take an object parameter with properties onSuccess and onFailure. If these functions are being called with programmatically created values within promises you can use “await new Promise” but that means declaring an additional async/await function (and therefore a promise) that resolves w…

I'm not sure I fully understand. Interoperability is as simple as wrapping the non-standard API, no? This way you have a standard calling style in your code. It's not a weakness of async/await that some libraries don't have promise friendly APIs.