<Promise>.status

💡 Ideas
1

I don't know why we can't synchronously read the status of a promise. I would imagine it would be very useful in a bunch of scenarios.

Right now this is what has to be done

function state(p) {
  const t = {};
  return Promise.race([p, t])
    .then(v => (v === t) ? "pending" : "fulfilled", () => "rejected");
}

and

state(promise).then(state => console.log(state));

or

(async () => {
  const state = await state(promise);
  console.log(state);
})();

Instead, why not just this?

console.log(promise.status);

Tnx, any thoughts?

2

The status is absolutely known internally. It's purposeful that we don't expose it directly (synchronously) - we don't want to make it easy to create functions that could act either sync and async based on the state of a passed-in promise. (This is sometimes called "invoking Zalgo", because it makes it hard to reason about the code's behavior.) We instead want functions to be sync or async all the time, based on how they're defined syntactically.

(Exposing a method that essentially just does what you wrote - returning an immediately-resolved promise giving the state of another promise - would be fine, tho.)

2 Likes
3

Also for debugging, most environments will show the internal status of a promise with console.log.

1 Like
4

On one hand it'd be nice for caching, but on the other, you can generally get away with just memoizing the promise if present, fetching if absent. In practice, I rarely have a desire for querying promise status directly, only indirectly in ways that can either be done better with resolvers or done better with just checking for the presence of a promise.