Is .then(function(a){ return a; }) a No-Op for Promises?

In the realm of promises, the question of whether .then(function(a){ return a; }) is a no-operation has arisen. Let's shed light on this curious query:

Yes, it is typically a no-op.

The code in question receives the return value of the previous promise in the chain via the function passed to .then(). However, if that function merely returns the input a, it effectively bypasses any processing or transformation of the promise's result. This makes it a harmless but unnecessary extra step in the promise pipeline.

Why was it written that way?

It's likely a typo or a relic from earlier misconceptions about promises. When promises were introduced, some developers erroneously believed that .then() needed to return a promise to continue the chain. As a result, they added this superfluous .then() call to ensure that the returned value always remained a promise, even if it was identical to the input.

Difference between Returning .then() and Omitting It

While semantically equivalent, there are subtle differences between returning .then() and omitting it:

• New promise instance: .then() creates a new promise instance, while omitting it reuses the original. However, this distinction is usually irrelevant.
• Thenable-ness check: With .then(), the returned value is checked to determine if it's a promise or not. Omitting .then() skips this check.

Edge Cases

In rare situations, .then(function(a){ return a; }) may have unusual behaviors:

• If the returned value suddenly becomes a promise after fulfillment, .then() will await it.
• It returns a distinct promise object, which could be useful for sharing avoidance. However, this is a niche use case.

Conclusion

In general, .then(function(a){ return a; }) is a no-op that does not add any value to a promise chain. It should be omitted unless there is a compelling reason to use it, such as avoiding shared promises or handling obscure thenable-related behaviors.