Pinky Swear… I Promise

Mod 3 at Flatiron and the firehose to the face only seems to be gaining steam. Trying to recover from such whiplash is a slow process. My instructors promise that in time and with lots of practice things will become clear. I am waiting…. See what I did there :). So the slow and steady journey through Flatiron bootcamp and JavaScript continues as I search for parallels that bridge the gap between the digital and real world.

In JavaScript the “promise” has proven to be such a bridge. Up until this point in bootcamp most of the applications and processes we have built were fairly light in load and responsibility. With the introduction of JS and the single page application a new hurdle arises. Javascript is synchronous code with a thread of execution that runs from top to bottom and left to right. In domain models with multiple view pages breaking up work load and processing is a more manageable task but in the world of single page applications load time and time to process requests is money. The longer elements of application or the application itself takes to load the less likely a user will stick around. One tool Javascript came up with to juggle the workload associated with a single page applications is the promise. The JavaScript promise is very similar to a promise we would encounter in real life. A JavaScript promise has 3 states -fulfilled, rejected, and pending.

In real life we see the same 3 states and actually communicate in promises far more often than we might think. Going to my favorite bodega for a delicious chicken cutlet sandwich I place the order “On a roll, no cheese, no tomato, with lettuce, mayo, and hot-sauce.” My local homie behind the counter makes a promise to return the chicken sandwich just as I ordered. My promise is now pending while the sandwich is being made until it is fulfilled/settled with all the correct instructions or rejected for having cheese or tomato on top.

Couldn’t find a photo without tomato :(

In the real world I have the ability to shower praise or anger upon someone making my precious bodega sandwich but in JS a returned promise is directly linked to two key words to handle the returned promise. .then and .catch.

.then returning fulfill = my correct sandwich order 😎
.catch returning reject = incorrect order with tomato on top 🤢

The above promises are very simple in execution and will therefore return a result in the order they were called. However the most common examples of promises we have seen throughout Mod 3 are related to fetch network requests. A fetch request is the syntax used in JavaScript to run our database GET, POST, PATCH, and DELETE network requests. Therefor depending on the specifics of the fetch being called (changing my user name / uploading a 8 minuted 4k video to facebook) the returned promise could be much more complicated in scope and in time required to execute. Because of the potential complexities and time suck a fetch network request could require, promises are used to keep your app running even if the fetch request is taking a while.

According to the trusty MDN “A Promise is an object representing the eventual completion or failure of an asynchronous operation.” To use our bodega/application example even though my homie has made a promise to complete my specific sandwich order the bodega itself is still able to sell chips, beer, and toilet paper to other customers in the store. The homie behind the counter is even able to take additional sandwich orders that will be completed after my cutlet is done! Asynchronous code and promises are JavaScripts attempts to keep your application running even if certain processes on the page (customer fighting with cashier over price of an old banana) take a lot of time. Your app like my bodega can multitask with the power of promises and asynchronous code.

Another great attribute of promises is that they are chain-able and the returned results of one promise are then passed on to the next promise in the chain. The most frequent example of this are the two .then promises returned from our fetch get request.

The first .then return of the response promise object
The second .then CHAINED returned data from inside body of first response

The fetch request returns our first promise object which we call .then on (r => r.json()). That call returns a new promise2 object , our response, which we chain with an additional .then on (toyData => renderAllToys(toyData)). The second .then gives us access to the body: ReadableStream which holds the toyData returned from the database. Chaining promises also allows us to structure promises in a synchronous way, where a list of promises run in line with each other and the promise2 cannot begin until promise1 has been returned. Also a single .catch can be used to and will handle any errors that are thrown if one of the previous promises are rejected

(process) cant be (saved) until it has completed running

In conclusion promises provide a variety of solutions for problems in Javascript. To recap one solution is that promises allow JavaScript to run asynchronously allowing a given app to multitask so that certain elements on a page do have time to complete for the rest of the page to load. Additionally promises can be organized in synchronous way in Javascript with chaining so that a programmer can have precise flow control over when a promise is made and how it is fulfilled or rejected. A few other tools are available for structuring promises in JavaScript. Promises can be put into an array and the .all can be called on the promise array. This will execute every promise in the array at the exact same time and return them in the order of their completion. The .race function can also be called on and array of promises and it will return the first promise that is completed in the array.


Budding Software Engineer trying to find the tie that binds 🤔