All of us have used promises in one way or the other. More often than not, we consume promises created and exposed by something else (Browser Web Apis being an example), rather than produce promises. When we consume promises, we don’t have a say in (and possibly don’t care about) how or when the promise is resolved, we only care about the fact that once it is resolved, we will get some kind of a signal and we can run our code. The resolution or rejection is always handled by the producer of the promise, we can only listen to the promise status changes, and there is no way for us to change this status explicitly. Usually, this is all we need when consuming promises, we can hook on to the success/error status, and do whatever we need to do. We can, of course, consume the promise and produce a further promise which can have a different status than the consumed promise. As an example, inside the promise.then() block, when the current promise resolves with a particular value, we can throw an error, to reject the new promise that is created by .then, and for all practical uses and purposes it would still seem that the result of the original task is rejection. In this case, we implicitly create a promise (the runtime creates a promise for us to return from then) and decide its status.

#javascript #react