Javascript: Pitfall Of A Callback Function
Promises are probably something that you have heard about while learning javascript. A beginner who is learning javascript may wonder, if we have a callback function to handle asynchronous requests, then why do we need Promises?
The purpose of this article is to understand what challenges callback functions present and why javascript promises are necessary ……
It is important to understand the callback functions before understanding the challenges that they pose. Read this article before continuing if you are not sure what callback functions are.
The callback function poses two major problems :
1. Callback Hell
2. Inversion of control
Let's understand each of the problems with the help of an example. Consider that we are given a task to build an eCommerce website. Starting from addToCart till showing a thank you page on successful order placement.
The following steps are to be followed in order to place an order. Assuming that for each step, we have APIs and let's chain them up so that the next step is executed after the completion of the previous step.
Step 1: add products to the cart
Step 2: go to the checkout page
Step 3: create an order ( updating order details to the database )
Step 4: charge credit card ( assuming the user has already added his credit card details )
Step 5: Display the thankyou page
You can see that callbacks are nested within other callbacks, making the code difficult to read and maintain. This kind of code is called callback hell and is sometimes also referred to as the pyramid of doom. This is one of the major pitfalls of callback functions. But callback hell has nothing to do with the nesting/indentation. It’s a far deeper problem than that. Because our brain is not used to such complexity, it is difficult to understand the async flow in such callback code.
Understanding the problem of inversion of control
Imagine you had written the above code and everything worked and you had deployed it to production. A few months later, your customer support team reports that one customer was charged five times for the same product. You discover it through some logs that chargeCreditCard() was called five times rather than once for some reason. Imagine that createOrder() is some third-party utility and that someone changed some code in the createOrder() API resulting in five calls to chargeCreditCard() API. In this case, third-party utility function createOrder() is given control over calling the chargeCreditCard() API. This problem is called the inversion of control of a callback function.
Avoiding trust issues is possible by inventing some ad-hoc logic. This would result in harder to maintain code that is insufficiently protected from these hazards until you have bugs. Hence we need a generalized solution to resolve this trust issue and javascript promises to do exactly this…….
Feel free to leave a comment below if you have any doubts or suggestions.
