Promise chaining (2 ed.)
Published: 2021-12-08 15:29:55

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 <sup>[1]</sup>.

**Table 1**

![Resolve vs. linguistic Settle](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ifihqlopm1glcbni22ie.png)
 
> **NOTE** : herein "settled" is not a state itself , rather a linguistic convention used for indicating change of state <sup>[2]</sup>. 

---

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]:

![Promise chaining flowchart](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/20v24vjeqzt3rzbt7q3h.png)
 
Let's examine a real life example a bit (shown below) :

**Example 1** :

{% codepen https://codepen.io/projektorius96/pen/Exmpoxx %}

<u>List of articles on more of practical examples</u> :

- [Nodejs.dev/learn](https://nodejs.dev/learn/understanding-javascript-promises)
- [Scotch.io](https://www.better.dev/callbacks-promises-and-async)
- [Javascript.info](https://javascript.info/promise-basics)

<br>

> **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 .

---

<u>I could present examples of N-tuple , but the **Rule of Thumb** algorithm is</u> :

1.  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 :

2.  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" :..

3.  ...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)`  <sup>[2]</sup>. 

---

**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 !

---

<u>References</u>

- <sup>[1]</sup>[262.ECMA](https://262.ecma-international.org/6.0/#sec-promise-objects)
- <sup>[2]</sup>[Domenic on GitHub](https://github.com/domenic/promises-unwrapping/blob/master/docs/states-and-fates.md)
- [web.dev – Promises](https://web.dev/promises/)