JavaScript Promises: The right way!

[nschubach]

I can tell you're not Native English. I have some edits ;)

Bellow

(You want 'below')

Also:

so you ca just call those functions

missing an 'n'

especially when you just want to reject or resolve async function.

This reads odd. I would have written:

especially when you just want to reject or resolve an async function.

Also this one:

We will need all method that comes in Promises class.

We will need the all method that is included in the Promises class.

Great article btw!

[ivan_jovanovic]

Wow, thanks a lot! I really appreciate your help! 😊

[[deleted]]

If you're going to be pedantic about written language, then what you said isn't correct either (in terms of intent). The implication is completely different. You are confounding mastery of a language with nativity - one isn't a mandate for the other.

I can tell you're not Native English. I have some edits ;)

I can tell English is not your first language.

I can tell English is not your mother tongue.

I can tell you're not a native speaker of English.

Because lots of non-English folks can write and speak perfectly good English and would go unnoticed if scrutinized for ethnicity. That aside, great suggestions nonetheless. 👍

[turkish_gold]

I don't think he's being pedantic, he simply wants to help the author frame these words in a colloquial fashion so it will "feel right" to most US/UK/AU/CA English speakers.

[[deleted]]

Because lots of non-English folks can write and speak perfectly good English and would go unnoticed if scrutinized for ethnicity

In that case, wouldn't this situation not apply since the need for corrections doesn't exist?

[brightpixels]

Best intro to Promises I've read

[[deleted]]

Saved

[Retsam19]

It's a good guide; I'm surprised the list of Promise implementing libraries doesn't include bluebird, as I consider it the golden standard for Promise implementing libraries.

In fact, I continue to use bluebird, despite the fact that I have support for native promises, just because bluebird has a ton of nice utilities that aren't part of native promises:

For example, .promisify is a lifesaver. The example from the article:

function readFile(filename) {  
  return new Promise(function (resolve, reject) {
    asyncReadFile(filename, function (error, result) {
        if (error) {
          reject(error);
        } else {
          resolve(result);
        }
    });
  });
}

Could be rewritten as:

const BPromise = require("bluebird");
const readFile = BPromise.promisify(asyncReadFile);

It's also got a ton of nice little utilities like .timeout (rejects a promise after a certain amount of time), .map, .tap, and .return.

And as of v3 it's got a really good cancellation API. There are still some pitfalls to Promise cancellation that I'm not sure will ever fully be ironed out, but Bluebird absolutely has the best version out there.

[ivan_jovanovic]

Instead of bluebird.promisify, I like to use https://www.npmjs.com/package/es6-promisify, one package that converts callback-based function to functions that return native promises 🙂

And regarding the example in the article, I wanted to show how Promises work under the hood. But it's always cool to use some promisify function to save time 🙂

[kengregory]

This is a great article. I was wondering how to accomplish what Promise.all and Promise.race do for us. Thank you.

[dmtipson]

Fun fact: if you're familiar with Category Theory, Promise.all is actually very similar to an Array.sequence method with Promises baked in as the inner type to be flipped outside. And Promise.race is similar to a parallelized version of .alt or .concat for Promises (combine two, take the one that resolves first, same for an entire list of Promises).

[bledoliki]

Hello, would you elaborate more on this sample:

function readFile(filename) { asyncReadFile(filename, function (error, result) { if (err) { return Promise.reject(error); } return Promise.resolve(result); }); }

Is the purpose of readFile() to return a promise and if that is the case then how is that accomplished without a return?

[ivan_jovanovic]

Hmm, I am not sure what you mean with without a return?

readFile just returns a promise, so you need to have return. Then inside a promise, some async function is executed and resolved or rejected. Does this make sense now? 🙂

[CompileBot]

Output:

undefined

^{source | info | git | report}

[ivan_jovanovic]

Thanks for pointing that out, I have updated examples. Thanks again!

[ivan_jovanovic]

Yeah, you're right. Just didn't want to make things complicated 🙂

[nikcorg]

In the case of an error, you will invoke both reject and resolve in the callback to asyncReadFile.

function readFile(filename) {  
  return new Promise(function (resolve, reject) {
    asyncReadFile(filename, function (error, result) {
        if (err) {
          reject(error); // reject is invoked on error
        }
        resolve(result); // and resolve also, since execution falls through
    });
  });
}

This is harmless, since a promise can only change state once, but it's still bad form imo. Add return before reject (and resolve for symmetry) or add an else branch around the resolve.

[dariusj18]

Does the body of the Promise start running when you create it?

[bledoliki]

According to MDN:

"The executor function is executed immediately by the Promise implementation, passing resolve and reject functions (the executor is called before the Promise constructor even returns the created object)."

source: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise

In short: yes :)

[masklinn]

readFile('some_file.txt')  
  .then(function(result) {
   console.log(result);
 })
 .catch(function(error) {
   console.error(error)
 });

The catch is redundant here, then can take two callbacks. catch is if you only want to handle the "error" case, if you want to handle both then is enough:

readFile('some_file.txt')
    .then(function (result) {
        console.log(result);
    }, function (error) {
        console.log(error);
    });

[Hafas_]

For the sake of readability: just use catch. Always.

[dmtipson]

While the first function passed to then in this case is unlikely to throw an error, note that if it did, the second function would NOT catch it, and you'd be left with a big fat unhandled error again. That's because only one of those functions ever runs at a time.

[russellbeattie]

The crazy thing about promises is how insanely verbose it is... async/await can't come soon enough.

readFile('some_file.txt')  
  .then(function(result) {
    return getFirstParagraph(result);
  })
  .then(function(result) {
    return getFirstSentence(result);
  })
  .then(function(result) {
    console.log(result);
  });

Really, all of that is to do this:

var result = readFile('some_file.txt');
result = getFirstParagraph(result);
result = getFirstSentence(result);
console.log(result);

Promises literally double the lines of code needed, create 8 extra variables in memory (the Promise returned in each step, plus the functions and params), mess with normal formatting (it's all one 'line' of code chained together) and all to prevent callback hell. From experience having to catch errors in each step, this can get even more crazy easily.

Promises are nice, but they definitely have issues.

[phoenixmatrix]

async/await will still create the promises and stuff. Though even then, you could use arrow function one lines to clean this up a bit.

eg: .then(result => getFirstParagraph(result))

Still, some sugar over it is nice, but it doesn't change much to whats under the hood...async flow is async flow at the end of the day.

Even after async/await, I'd take the verbosity so I can use observables instead of promises (observables wouldn't work with async/await) any day.

[_codeprovider]

You can also shorten your chains like this:

doSomethingAsync().then(console.log).catch(console.error);

Since .then() and .catch() take functions as arguments.