5 ms·

I admit, i struggled with promises, within promises, within promises. Synchronous, I understood and just worked for me.

lexicality 2y ago
Not that it matters because you don't care and no one uses promises any more but it does really sadden me how much nested promise code I've found over the years. eg this function sad(input) { return new Promise((resolve, reject) => foo(input).then((data) => { bar(data).then((data2) => { baz(data2).then(resolve, reject) }) }) ); } could quite as easily have been written like this: function happy(input) { return foo(input) .then((data) => bar(data)) .then((data2) => baz(data2)) } But no one seemed to be aware that you can return a promise in the `.then()` callback and have it chain neatly...
- datashaman 2y ago
  async functions return promises. everyone uses promises.
  - lexicality 2y ago
    you are technically correct, but I think you know what I meant
- MrJohz 2y ago
  One of the rules I teach people when they're starting using promises is never ever to write `new Promise(...)`. That's not because it's bad - it's a useful tool if you're connecting event or callback-based systems to the world of promises and async/await. But a lot of people who are just getting started with promises seem to take a while to get used to chaining, and often resort to using the `new Promise` constructor to get promises to appear in the places they expect. So giving them a blanket rule ("never use `new Promise`") forces them to figure out a different approach. It's become a lot easier since the introduction of async/await, where chaining isn't so important, but there are still always times when you need to understand that underneath the syntax sugar, there's still promises happening, and so I'm still finding the rule useful.
- endofreach 2y ago
  > no one uses promises any more I haven't used node in years, so i wonder: What is used instead?
  - lexicality 2y ago
    async/await, which uses promises under the hood, but you typically won't interact with the raw promise objects
    - endofreach 2y ago
      Ok thank you for clarifying. then i misread the original comment.

Not that it matters because you don't care and no one uses promises any more but it does really sadden me how much nested promise code I've found over the years. eg this function sad(input) { return new Promise((resolve, reject) => foo(input).then((data) => { bar(data).then((data2) => { baz(data2).then(resolve, reject) }) }) ); } could quite as easily have been written like this: function happy(input) { return foo(input) .then((data) => bar(data)) .then((data2) => baz(data2)) } But no one seemed to be aware that you can return a promise in the `.then()` callback and have it chain neatly...

datashaman 2y ago
async functions return promises. everyone uses promises.
- lexicality 2y ago
  you are technically correct, but I think you know what I meant
MrJohz 2y ago
One of the rules I teach people when they're starting using promises is never ever to write `new Promise(...)`. That's not because it's bad - it's a useful tool if you're connecting event or callback-based systems to the world of promises and async/await. But a lot of people who are just getting started with promises seem to take a while to get used to chaining, and often resort to using the `new Promise` constructor to get promises to appear in the places they expect. So giving them a blanket rule ("never use `new Promise`") forces them to figure out a different approach. It's become a lot easier since the introduction of async/await, where chaining isn't so important, but there are still always times when you need to understand that underneath the syntax sugar, there's still promises happening, and so I'm still finding the rule useful.
endofreach 2y ago
> no one uses promises any more I haven't used node in years, so i wonder: What is used instead?
- lexicality 2y ago
  async/await, which uses promises under the hood, but you typically won't interact with the raw promise objects
  - endofreach 2y ago
    Ok thank you for clarifying. then i misread the original comment.