We know that every new Promise() returns an object with three possible states, where as only one of the states the Promise is able to resolve to : depending on the situation , it would resolve to the state, i.e. either of : <pending> / <fulfilled> / <rejected> . Initially every Promise comes with the state ([[PromiseStatus]]) of <pending> and value of undefined ([[PromiseValue]]) . The following of :[[PromiseStatus]] and [[PromiseValue]] are internals (closures) of Promise you are not allowed to access
A resolved promise may be *pending, fulfilled or rejected [1].
Table 1
NOTE : herein "settled" is not a state itself , rather a linguistic convention used for indicating change of state [2].
With reference to the Table 1 & Flowchart 1 , pending is nor resolved, nor settled, where as *pending of pending (Promise of another Promise) and the subsequent N-tuple (if any) is resolved, but not settled (it means resolved with another Promise). Keep in mind : there is a difference in between of the very initial unresolved Promise with value of undefined and resolved Promise with value as another Promise (undefined exchanged into another Promise) . In other words : *"resolved" technically means anything rather than undefined (another promise or some real-life non-promise value) .
Flowchart 1 – Promise chaining [self-made by app.diagrams.net]:
Let's examine a real life example a bit (shown below) :
Example 1 :
List of articles on more of practical examples :
NOTE : in terms of Example 1 , specifically for file system module , developers mostly rely on promisified fs module of
require('fs/promises')with techniques of async / await applied upon that simplifies one's day for sure .
I could present examples of N-tuple , but the Rule of Thumb algorithm is :
Check if this is the very first .then() used on INITIAL Promise. If answer is "YES", while the code logic itself was written correctly, it should not return Promise of Promise as shown in Flowchart No. 1 , conversely it should return INITIAL PROMISE meant exactly for specific reference (if Promise chaining split into parts as presented within **Example 1**) , be resolved to non-pending state by gaining some real-life value expected for inbound
(resolved & settled). However if answer is "NO", read the following :If you came from above as answer of "NO" it presumably would return N-tuple *Promise of Promise . In such case there is no more of term "INITIAL PROMISE" . Luckily it will resolve, which is a good thing . The bad thing it would resolve to *pending of pending with value of undefined
(resolved-UNsettled); There is one "BUT" :.....If it would turned out, the 2nd 3rd, N-tuple .then*s() are used in the following Promise chain you're examining right now, double check if before last .then() returns **its own INITIAL* PROMISE, in such case you can expect as expected, i.e. it would be resolved to non-pending state by gaining some real-life value expected for inbound just as in step 1 . This means intermediate Promise of Promise have fate of being resolved & defined
(resolved & settled)[2].
To conclude: it depends whether the following .then() returns Promise-like or non-Promise-like value. Depending on this, the following Promise chain would behave differently and that's all about how states are handled and what values would be return respectively .
If any typos found and (or) suggestions could be made, please leave it in the comment section below . Thank you and see you in the next one !
References
Top comments (0)