Ben Halpern

Posted on Sep 29, 2018

Visual Studio Code can now convert your long chains of Promise.then()'s into async/await automagically

#vscode #webdev #javascript #news

VSCode is continuing to evolve in pretty fascinating ways.

I'm curious about whether I'd actually make use of something like this, but I definitely find it interesting if it gets out of the way when not being used.

Top comments (23)

Sung M. Kim • Sep 30 '18 • Edited

I'm curious about whether I'd actually make use of something like this

async/await sometimes looks less readable than promise.then counter-part.

So one can use it when async/await version makes it more readable 😎.

Razvan Ilin • Sep 30 '18

I agree with this completely. I tried refactoring my code to async/await because it was the new thing, but I ended up sticking with promises because the code was much cleaner

WORMSS • Oct 3 '18

It's very useful when you have if's especially if you have conditional diamond forks.

Ben Halpern • Sep 30 '18

Yes, agreed.

Mahmoud ElNaggar • Apr 19 '19

I completely agree .. I can orchestrate the chains of thens in a Promise however it makes it more readable for me

Dmitriy Belyaev • Sep 29 '18

Few releases later VSCode will learn how to make coffee ☕

Nicky Hajal • Sep 30 '18

If I recall correctly, the changelog also mentioned this was thanks to a summer intern on the VSCode team. Pretty cool!

Ben Halpern • Sep 30 '18

Wow, that’s fantastic!

Jonathan Sexton • Mar 5 '19

That's a really cool aspect of this, go summer intern!

Mihail Malo • Sep 30 '18

Cool, and there are definitely valid use cases for this, but I am scared the people who are too enthusiastic about async/await will abuse this and the amount of PRs that change

const getPosts = () =>
  firebase
    .firestore()
    .collection('posts')
    .orderBy('timestamp')
    .get()
    .then(querySnapshot => querySnapshot.map(doc => doc.data()))

export default {
  name: 'Home',
  data: () => ({
    posts: []
  }),
  async asyncData() {
    return { posts: await getPosts() }
  }
}

into

export default {
  name: "Home",
  data: () => ({
    posts: []
  }),
  async asyncData() {
    let posts = []
    await firebase
      .firestore()
      .collection("posts")
      .orderBy("timestamp")
      .get()
      .then(querySnapshot => {
        querySnapshot.forEach(doc => {
          posts.push(doc.data())
        })
      })
    return { posts: posts }
  }
}

Julien Eric • Oct 6 '18

Why would it leave a then hanging off of an async call?

Mihail Malo • Oct 6 '18 • Edited

Which one are you talking about?

You mean the abuser would write the following?

export default {
  name: "Home",
  data: () => ({
    posts: []
  }),
  async asyncData() {
    let posts = []
    const querySnapshot = await firebase
      .firestore()
      .collection("posts")
      .orderBy("timestamp")
      .get()
    querySnapshot.forEach(doc => {
      posts.push(doc.data())
    })
    return { posts: posts }
  }
}

Ben Halpern • Sep 29 '18

Credit: @umaar , of course.

Umar Hansa • May 22 '20

Hey Ben, I'd be down for an AMA as @nickytonline suggested (thanks Nick for the kind words about the course 😊️)

Ben Halpern • May 22 '20

Sounds good to me 😄

Nick Taylor • Sep 30 '18

You should ask @umaar if he'd be up for an AMA. He's a dev tools guru. I signed up for his moderndevtools.com last year and it's🔥💯

Ahmad Awais ⚡️ • Sep 29 '18

VSCode is awesome! 👌

Gene • Sep 30 '18

// Unrelated
I've read a lot of good things about axios, but never from a DEV community member yet. I wish to read one soon! Especially why fetch is better than axios instead of why axios is better than fetch like what most articles I've read says so.

shawnlan • Oct 1 '18

We have to be careful and understand how async/await works. The converted code doesn't behave exactly the same in the twitter example. Before conversion the function returns a promise that resolves with undefined, and console.log(err) is called. After conversion, the function returns a promise that rejects, and console.log(err) is not called. We would assume the converted code should behave the same; thus it's a bug IMO.