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?
Yes.1
It is useless and should be omitted.
It's a blunder. Or the author didn't understand promises.
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'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:
In general, don't do
then(function(a) { return a; })