What is the correct terminology for javascript promises

Solution 1:

Terminology can be hard.
Let's take from the Promises/A+ specification and the respective ES6 section that there are 3 states:

  • pending - the promise does not have taken a value yet, it's future is still uncertain.
  • fulfilled - the promise successfully got a result value "assigned"
  • rejected - the promise is given a reason why no result could be acquired, typically an error.

The term settled is a hyperonym for fulfilled and rejected, meaning either - the opposite of pending.

The dynamic verbs fulfill and reject describe changing the state from pending into either the fulfilled or rejected. These transitions are called fulfillment or rejection of the promise.

Those were easy. Now, resolve is a different beast. It sometimes is used synonymous to "fulfill", but it would better be understood as settling the promise's fate to either fulfilled or rejected. The resolution (seldom: settlement) of a promise means that it leaves the pending state. But not even that is accurate - the problem is the recursive nature of the Promise Resolution Procedure:

  • resolving a promise with a "plain" value means fulfilling it
  • resolving a promise with a promise (or thenable) means adopting its state:

    • resolving with a fulfilled promise is a fulfillment
    • resolving with a rejected promise is a rejection
    • resolving with a pending promise means waiting for its resolution

Yes, if a promise is resolved it might not even be known whether it's going to be fulfilled or rejected. But it means the fate is no longer undetermined, as it's bound to the promise that we resolved with (notice that you can resolve a promise only once).

Ignoring this special case, a resolved promise usually means a settled promise.

Or, to cite the ECMAScript 6 Specification:

A promise is resolved if it is settled or if it has been “locked in” to match the state of another promise. Attempting to resolve or reject a resolved promise has no effect. A promise is unresolved if it is not resolved. An unresolved promise is always in the pending state. A resolved promise may be pending, fulfilled or rejected.


and what the heck is defer?

Deferring a result means that you return an (asynchronous) promise for the result, and not the result directly (synchronously). And also return a deferred rejection instead of throwing synchronously.

Notice that "defer" is also used in some libraries (Q) as the method name to construct a Deferred object - see this answer on The differences between Deferred, Promise and Future for a good explanation.
Oh, and never trust variable names: defer might as well be an abbreviated "deferredObject".

Solution 2:

The three promise states are listed in section 2.1 of the Promises/A+ specification.

From the specification:

enter image description here

So here are each of the terms you asked about:

Pending is the initial promise state. The operation represented by the promise has not yet been filfilled or rejected.

Fulfilled is another of the three promise states. It means that the promise has been resolved and now has its resolved value. The operation represented by the promise has been completed successfully.

Rejected is another of the three promise states. It means that the promise has been rejected and now has its rejected reason. The operation represented by the promise failed to obtain a value and thus has a reason for failing to do so (typically an error code or error object, but it can be anything).

Settled is a term that means the promise is either fulfilled or rejected (e.g. it's not pending any more), but it is not a separate state just a descriptive term to indicate it is no longer pending.

Resolved is a term that is often used to mean the same as fulfilled, but the two are not exactly the same. A promise can be resolved with a value which leads to fulfillment or it can be resolved with a rejected promise (which leads to rejection of this promise) or it can be resolved with a pending promise (which means it will now be waiting on the eventual state of some other promise).

It's hard to say exactly what you mean by defer. Promises are often classified as deferred objects in that they are an object that represents an action and result that is deferred to the future (it will occur in the future). In some promises implementations, there are actually two types of objects, a deferred object and a promise object. The deferred object is a superset of the promise object. Both can observe when the action is resolved or rejected with .then() handlers. But, only the deferred object can actually change the state to resolved or rejected.

In jQuery, you can create a deferred object with $.Deferred(). In other implementations such as ES6 promises, you just have promise objects with a constructor callback that has reject and resolve functions. The world is presumably moving toward what ES6 will have.

jQuery example that uses a deferred object:

function delay(t) {
    var defer = $.Deferred();
    setTimeout(function() {
        defer.resolve();
    }, t);
    return defer.promise()
 }

 delay(200).then(function() {
     // run my delayed function now
     doMyThing();
 });

ES6 promise example:

 function delay(t) {
     return new Promise(function(resolve, reject) {
         setTimeout(function() {
             resolve();
         }, t);
     });
 }

 delay(200).then(function() {
     // run my delayed function now
     doMyThing();
 });

Solution 3:

Domenic Denicola's "States and Fates" is a good, pithy summary.

States:

  • a promise is fulfilled if promise.then(f) will call f "as soon as possible"
  • a promise is rejected if promise.then(undefined, r) will call r "as soon as possible"
  • a promise is pending if it is neither fulfilled nor rejected.

Fates:

  • a promise is resolved if trying to resolve or reject it has no effect, i.e. the promise has been "locked in" to either follow another promise, or has been fulfilled or rejected
  • a promise is unresolved if it is not resolved, i.e. if trying to resolve or reject it will have an impact on the promise.

Follow the link for details 'relating states and fates'.