Promises Promises
JavaScript promises, or ratherPromisesare objects that function as placeholders for values that are not necessarily known at the given moment a line of code is executed. They are proxies for a value, that isn’t necessarily known or defined at that moment. They allow us to build handlers that asynchronously wait for an action’s eventual value should it fail or succeed.
To use a financial analogy, a JS promise is like a check or bearer bond. It’s not actually a sum of cash in hand, but at some point in the future, they can be processed and redeemed as such. In fact if you wait a while at an open bank, and you’ll receive some sort of return even if it takes a while to get it counted, or even if the check bounces. If we look at MDN, we can see how this analogy highlights the three states a promise can have:
- pending: initial state, neither fulfilled nor rejected.
- fulfilled: meaning that the operation was completed successfully.
- rejected: meaning that the operation failed.
Pending, reflects you literally waiting to get the check paid to you in cash. Further, fulfilled means the promise was processed successfully and you have some valuables added to your name. Where-as the check bouncing, or being revealed to be invalid is akin to a promise being rejected.
The real benefit is in that promises let us chain on additional actions that can be executed after the value is settled. Take a look at this handy diagram:
Additionally promises “eager,” as Eric Elliott describes. This anthropomorphization of a block of code simply means that by using an instance of a promise object, our tasks can get to work immediately using the promise as a placeholder, while the actual value of is computed elsewhere. Eric does an excellent deep dive on the history of promises in JavaScript, so give him a read.