Best practices for promises?

[PandaWhisperer]

First of all, great job on this guide, I agree with it almost 100%. All of this should really be common knowledge, but I sure as hell didn't know most of these things when I started, so kudos for writing it all down.

Now, since promises have been standardized and a lot of people have started using them, it would be nice to have a section on how to keep promise-based code readable. For instance, when chaining multiple promises together, there are at least two alternative ways to do it:

Option 1: anonymous functions

return doSomething(foo).then(function(result) {
  // ...
}).then(function(result2) {
  // ...
}).then(function(result3) {
  // ...
}).catch(function(error) {
  // ...
}).finally(function() {
  // ...
});

Option 2: named functions

function doThis(result) {
  // ...
}
function doThat(result) {
  // ...
}
function handleError(error) {
  // ...
}
function done() {
  // ...
}

return doSomething(foo)
  .then(doThis)
  .then(doThat)
  .catch(handleError)
  .finally(done);

The second way, while being somewhat more verbose, seems to be preferable, as the chain of tasks that the promise result travels through becomes more obvious.

I did an internal poll of our developers, and so far, option 2 seems to be ahead, although I have not heard from everyone yet. How does AirBnB deal with this, and what are your opinions?

[hshoff]

Hi @PandaWhisperer, thanks for opening this Issue. Promises are a great place to have conventions in place for clarity.

I'm going to leave this open for a bit to give time for the community to participate in the discussion.

Will follow up on this after a week or so.

[netpoetica]

Option 2 is definitely more popular in node where we've got module.exports and don't have to worry about those functions leaking globally. I do this on the front-end as well and a lot of people do, but a lot of times, new programmers or non-JS programming who are writing JS, use anonymous functions - and a lot of them write the same exact anonymous functions a dozen times. I.e:

return doSomething(foo).then(function(result) {
  $('#mything').html(result);
}).then(function(result2) {
  $('#mything2').html(result);
}).catch(function(error) {
  console.log("There was an error!", error);
});

return doSomethingElse(foo).then(function(result) {
  $('#mything').html(result);
}).then(function(result2) {
  $('#mything2').html(result);
}).catch(function(error) {
  console.log("There was an error!", error);
});

This is a really minimal example, but what I'm getting at is that we should push to recommend option 2 for best practices, particularly calling out at least these two major values I can think of:

• ability to reuse named functions, saving memory and centralizing locations that will need to change
• named functions provide much more useful stack traces in error messages

Good work on this!! I'm looking forward to seeing what people have to say about it. It could also be useful to recommend promise implementations based on various criteria:

• most popular libs
• most lightweight
• most package manager support

[PandaWhisperer]

Here's another situation I just stumbled upon while working with some Promise-based code:

getPromise().then(function(result) {
    if (!checkResult(result)) {
       throw new Error("invalid result!");
    } else {
       return doSomething(result);
    }
}).catch(handleError);

Obviously, this code is a bit contrived, but bear with me here, the point should become obvious in a second. The above code is completely equivalent to this:

getPromise().then(function(result) {
    if (!checkResult(result)) {
       return Promise.reject(new Error("invalid result!"));
    } else {
       return Promise.resolve(process(result));
    }
}).catch(handleError);

Of course, .then(), by design, ALWAYS returns a promise, so making this explicit does not add anything. You'd think that would make it obvious which version is preferable – but the fact that the code I have in front of me right now uses the 2nd version shows otherwise.

[dyoder]

I'm not a fan of using named functions if the only reason is for the names to show up in stack traces. Part of the appeal of promises (and, more generally, functional programming) is to compose complex behaviors from simple ones, and anonymous functions are an important part of making that easier to do.

Of course, if we have a complex behavior that can be reused, that's a different story. But for, say, up to 3 lines of code (a completely arbitrary threshold), anonymous functions are fine.

The issue of handling typical error callbacks, though, suggests those functions should be lifted by your promise library. That is, I don't think you should typically need to map errors to reject and results to resolve.

If you're not using some standard callback form (for which lifting functions would be available), one question is: why not? And another is: does your particular callback style come up often enough to write your own standard lifting function.

[getvega]

I definitely +1 @dyoder on that. Sure it helps debugging but named functions require the developer to 1/ find a good name 2/ keep that name consistent over time with the rest of the code base.

In ES6 in some cases it will become even more elegant / simple :

getPromise().then((response) => response.body)

Instead of

getPromise().then(function readBody(response) {
     return response.body;
})

[getvega]

About best practices, seems like you all put the .then on the same line instead of a new line...

What do you think of

getPromise()
    .then(function(response) {
         return response.body;
    })
    .then(function(body) {
         return body.user;
    });

It seems a bit more compliant with leading dots in https://github.com/airbnb/javascript#whitespace

[JoshuaJones]

Definitely leaning more to have .then on a new line per @getvega's last comment, and it does line up with the guides direction for long chains.

Looks a lot more readable.

[calmdev]

I came here looking for indentation guidelines for promises and found this issue. I use the same indentation style as suggested by @getvega and agree with @JoshuaJones on it's readability. As for the original issue, as other have pointed out, it'd be a mix of the two options rather than just one or the other. The es6 fat arrows are nice for readability when you want to use closures, but there is also the benefit of the named functions for the stuff you want to reuse in other places. @PandaWhisperer makes good points too when catching rejections.

[thomasvanlankveld]

In general, I would like to promise practices to be as close to the use of async/await as possible. (currently stage 3)

Errors

@PandaWhisperer's error thing code is a good example, the first one avoiding Promise.reject and Promise.resolve is closer to what this would look like with async/await:

try {
  const result = await getPromise();
  if (!checkResult(result)) throw new Error("invalid result!");
  doSomething(result);
} catch (errr) {
  handleError(errr);
}

Anonymous vs named

Concerning @PandaWhisperer's original question: I think whether to use anonymous or named functions should really be up to the developer, based on his situation; As it is with synchronous code (should I extract this to be a subroutine or not?). Consider his exampled refactored into async/await:

try {
  const result = await doSomething(foo);
  const result2 = // ...
  const result3 = // ...
  // ...
} catch (errr) {
  // ...
} finally {
  // ...
}

Whether result2 is best obtained with a function doThis or with one or more lines of code really depends on the situation.

I'm not saying that because it depends on the situation with async/await, it also does for promises. I would actually prefer promises to be written with a set of well-named functions over them being written with a set of anonymous ones, but that's my personal preference; not what I would want in a style guide.

Line breaks

I like @getvega's suggestion to always put .then on a new line. This seems consistent with the chaining style.

Arrow functions

I especially like @getvega's arrow function suggestion. Applying this to his second example:

getPromise()
    .then(response => response.body)
    .then(body => body.user);

Makes it easy to see we could even turn this into:

getPromise().then(res => res.body.user);

Badabing!

[PandaWhisperer]

Wow. This issue is more than a year old. Has the guide been updated with regards to promises? Just did a quick check and it seems that while it has been updated for ES6, promises still aren't mentioned anywhere.

FWIW these days I generally prefer the async/await style, but using generator functions and yield.

[ljharb]

Duplicate of #597 as well.

We will be updating the guide to discuss Promises and async/await as soon as possible. Generators + yield would be an antipattern in whatever we write up, fwiw, as generators are synchronous.

[PandaWhisperer]

Generators + yield would be an antipattern in whatever we write up, fwiw, as generators are synchronous.

How is that relevant? Yes, a generator runs synchronously, but only until it is eventually suspended when waiting for the promise to resolve. The promise still works asynchronously.

async/await are ES7 only, while generators and yield can be used today.