The Promise.all implementation that made me think differently

Josh Miles
3 min readNov 5, 2016

--

Following on from the previous discussion about Promises here, I would like to go further and talk about Promise.all and what example blew my mind when it came to thinking about Promises and functions. This blog post will be more of a “Wow I didn’t know you could do that” it may WoW some or make others comment about how obvious it was in the first place, either way I want to tell someone about it because it is pretty sweet. Let us begin! (If you already know about the Promise.all function, feel free to skip to the second last paragraph to read what really blew my mind within a specific implementation)

Promise.all the basics and Uncouth

The Promise.all function takes an array of Promises and allows each to execute before continuing into its own then statement (clause?). My original implementation was to just build a Promise generator and throw each Promise into an array which I used the Promise.all function on. This worked out great however there was something I could have done with so much more grace.

Where I found the Promise.all usage

After I had implemented the above example I went on the look out for a better implementation of the Promise.all function, not actively just when I get to a Git repo and noticed it using the Promise library I would see how they implemented it to see if it was an improvement on my implementation. When looking for some sweet Star Wars example JSON data I found in a repo called Swapi-graphQL library I came across a Promise.all statement on line 277(Assuming no one edits the file) of the following file, that is what I would like to talk about.

How it does what it does

So what this function (for those who skipped, follow the above link(line 277)) does isn’t what I would like to look into right now, it is how it does it. The first thing I noticed about it being different is that it doesn’t have an array as an input, well kinda, it has a modified version of the array types, it maps over the types array and instead of doing what I found typical map function (line 16 of the gist above (That is what I found typical at least)) it just inserted an already declared function as input to the function. There was no need to say “Take each element in type and use it as an input for this function I just put in”, just the function. That just made way too much sense for me, and they did it again! They took what was the output of that function, mapped around it and put it into another function which built Promises. The way I understand it is like a manufacturing line which has specific stages of the product worked on, cloned (thrown out?) and worked on further. The end product came out to be an array of Promises they did not create directly, but as a consequence of the functions that came before. This is what blew my mind so much I wrote two blog articles about it, I hope this may do the same for others!

If you got this far, thanks! Please tell me what you didn’t like about it and I will be sure to look into further improvements into future articles about what is currently making me excited in the programming space!

--

--