7

I'm reading this tutorial about Bookshelf. Bookshelf uses Bluebird promises. There's quite a few examples that look something like this:

var getEvents = function(participantId) {  
  return new models.Participant()
    .query({where: {id: participantId}})
    .fetch({withRelated: ['events'], require: true})
    .then(function(model) {
      return model;
    });
};

I'm still not comfortable with promises, but from what I've learned so far this seems odd. My question is, is the above function exactly the same as returning fetch() directly and leaving off the final then():

var getEvents = function(participantId) {  
  return new models.Participant()
    .query({where: {id: participantId}})
    .fetch({withRelated: ['events'], require: true});
};

That is, it still does the same thing, returns the same promise, can be called in the same way, etc?

From what I understand, the parameter to the function passed to then gets the return value of the previous promise in the chain. So, it seems to me like .then(function (a) { return a; }) in general is just a no-op. Right?

If they aren't the same, what's the difference? What's going on and why did the author write it that way?

Jason C
  • 38,729
  • 14
  • 126
  • 182
  • 4
    `.then(function(model) { return model; });` is useless and can (and should) be dropped. – dfsq Dec 11 '16 at 17:51
  • this make sense if `fetch` handler can provide a few parameters. After this - promise would resolve just with one. – Grundy Dec 11 '16 at 17:52
  • 2
    author added last `then` to show that in this step you can manipulate `model` – stasovlas Dec 11 '16 at 17:52
  • 2
    One common reason for the extra `.then()` is so you can log the result there or set a breakpoint on it to inspect it. That should probably be removed before general release, but that's sometimes why it's there. Or, the author thought they might want to process the result a bit before returning it and then didn't end up dong that. Or this was just done for educational purposes to illustrate better what the return result was. – jfriend00 Dec 11 '16 at 18:28

2 Answers2

16

It seems to me like .then(function (a) { return a; }) is just a no-op. Right?

Yes.1

It is useless and should be omitted.

What's going on and why did the author write it that way?

It's a blunder. Or the author didn't understand promises.

1: If they aren't the same, what's the difference?

As always, there are some edge cases. Really weird ones. That no-one should use (without extensive commenting):
a) it returns a new promise instance, a distinct object, to avoid sharing. However, .then() would as well.
b) a is tested again for its thenable-ness. If it suddenly became a promise since the fulfillment, it now will be awaited. This would be awful of course.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
8

Bergi's answer is right, but just to demonstrate a case where it's not a no-op here is a contrived example where it's not a no-op:

o = {};
Promise.resolve(o).then(o => o.then = () => {}); // make thenable
Promise.resolve(o).then(console.log); // logs the object
Promise.resolve(o).then(x => x).then(console.log); // doesn't log the object

In general, don't do then(function(a) { return a; })

Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • 2
    I've seen this actually happen once in really poorly engineered code. I won't forget it easily. – Benjamin Gruenbaum Dec 11 '16 at 18:03
  • I tried the exact steps, `Promise.resolve(o).then(console.log);` returns `Promise {}` instead of logging object, next step does the same – T J Apr 22 '21 at 13:13