3

ES6 native promises do not allow you to synchronously check if they're resolved/pending/failed or to extract their value. I sometimes need this functionality and thus I have to code it manually.

Is this considered an anti-pattern? Is this why this feature was left out of the standard?

This is a situation where I think this sort of feature comes in handy:

// the render method of a React component
// it will get triggered by other events other than the promise state change
render() {
  if (promise.resolved) {
    // render the result
  } else if (promise.rejected) {
    // render an error/reason
  } else {
    // render a loading message
  }
}
adrianton3
  • 253

3 Answers3

1

The main problem I'm aware of with synchronous inspection is that it's completely unnecessary, unless your code relies on the promise resolving or rejecting within a certain number of ticks, which is exactly the sort of thing you should not rely on.

For instance, although I know nothing about React, I'm pretty sure your example could be changed into something like this:

this.text = "";

var promise = ...;
promise.then(function(result) {
    this.text = "Success: " + JSON.stringify(result);
}).catch(function(error) {
    this.text = "Error: " + JSON.stringify(error);
});

...

render() {
  // render the current value of this.text
}

You could even argue this version is better decoupled because now the render method has no idea that the value of this.text depends on that one specific promise. You could now easily make this.text depend on the results of several different promises chained together without causing a combinatorial explosion of synchronously inspecting if statements.

The only other argument for synchronous inspection which I'm aware of is that "it is known in certain code paths that a promise is guaranteed to be fulfilled at that point - it would then be extremely inconvenient to use .then to get at the promise's value as the callback is always called asynchronously." I would rather use .then() even in these cases, because a promise is not really guaranteed to be fulfilled until you're in its .then handler (or .spread handler or whatever). Assuming otherwise just creates an obvious way for my program to break in the future, no matter how airtight my argument might be today. If the handler being called on the next tick is a serious problem, then you're already depending on how many ticks certain operations do or don't take to resolve/reject, which is something you need to fix properly rather than work around.

Ixrec
  • 27,711
0

The purpose of a promise or future is to allow the promise to pursue calculations while you go and do something else ("in another thread"). Once you're done doing your other thing and come back to the promise to interrogate it for a value, the expectation is that you will then wait for the value (having completed "doing your other thing").

If you want to take action immediately when a promise has completed its task, I think you're better off having the "promise" notify you when it has completed. Use an event, in other words.

Robert Harvey
  • 200,592
0

I wouldn't call it an anti-pattern, I'd just call it silly (in most cases).

You are presumably using premises because you're dealing with some asynchronous work. That said, you should just assume that its status is pending until it says otherwise.

And with that said, you will presumably also have a section of code that deals with the promise events/callbacks. You'll set a default state (pending), and you'll subscribe to the success and failure events. And, if this if truly an asynchronous activity, code inspecting the promise synchronously is probably duplicative of code responding to the succeed/fail events. And if it's truly an asynchronous activity, that duplicative, asynchronous code will probably never even be executed.

svidgen
  • 15,252