DEV Community: Aryak Lahane

The Promise.all( ) Dilemma: When it helps and When it hurts

Aryak Lahane — Sat, 21 Sep 2024 07:11:30 +0000

In modern JavaScript development, handling asynchronous operations is a common task. Whether it’s making API requests, querying databases, or reading files, working with async code is almost unavoidable. One of the common tools developers come across is Promise.all(). However, many of us, myself included, can fall into the trap of trying to use Promise.all() just because it’s there without really understanding whether it’s the best solution for our particular use case.

1. Jumping on the Promise.all() Bandwagon

As a developer, it’s easy to come across new features or tools and assume that they should be implemented everywhere. I found myself in this situation with Promise.all(). Having read about how it runs multiple promises in parallel and waits for all of them to complete before continuing, I was eager to integrate it into my code. Without fully understanding whether it was necessary, I jumped on the bandwagon and applied it wherever I could.

It’s easy to assume that since it’s a powerful tool, it must be better than the simpler alternatives. But as I soon realized, blindly applying Promise.all() without considering the context doesn’t always lead to the most efficient or readable code.

2. The Basics of Asynchronous JavaScript

Before we dive deeper into when Promise.all() is useful, let’s first look at how asynchronous functions work in JavaScript. When you write an async function and use await, JavaScript allows that operation to happen without blocking the rest of your code. This means that you can initiate one operation and move on to others while waiting for the result.

However, if you’re not careful, you might end up making operations unnecessarily dependent on each other when they could be run independently. I found myself in this situation with Promise.all(), thinking it was always a good idea to run all my async functions in parallel.

Example: Sequential Execution of Asynchronous Functions

const fetchData = async () => {
  const data1 = await getChart();   // Request #1
  const data2 = await getDetails(); // Request #2
};

Even though data1 and data2 are fetched one after the other in code, the browser still initiates both requests asynchronously and almost simultaneously. In fact, when I checked the Network tab, I saw both requests start around the same time. This made me realize that JavaScript was already handling things in parallel, and Promise.all() wasn’t necessarily required.

3. When Should You Use Promise.all()?

Despite my initial rush to use Promise.all() everywhere, there are situations where it truly shines. It is especially useful when you need to wait for multiple asynchronous operations to complete before moving forward.

Why Use Promise.all()?

Waiting for All Promises: If the results of multiple asynchronous tasks are dependent on each other, or if you need all of them to complete before proceeding, Promise.all() is ideal.
Error Handling: Promise.all() fails fast — meaning if any promise fails, the entire operation is rejected. This can be useful when you want to ensure everything succeeds together or nothing moves forward.
Combined Results: If you need the results of all promises at once (e.g., combining user data with purchase history), Promise.all() is the perfect solution.

Example: Using Promise.all()

const fetchData = async () => {
  const [data1, data2] = await Promise.all([getChart(), getDetails()]);
  console.log('Both requests completed'); // This runs only when both requests finish
};

In this example, both getChart() and getDetails() run in parallel, and the function waits until both are finished before moving forward. Promise.all() is perfect in situations like this where both requests are related and need to complete together.

4. Why I Didn’t Need Promise.all() in My Case

After applying Promise.all() a few times, I started to notice that it wasn’t always making my code better. In fact, I was overcomplicating things. I had two independent API requests—getChart() and getDetails()—each with its own loading spinner and results, and yet I was bundling them together unnecessarily.

By using Promise.all(), I was forcing the code to wait for both requests to complete before handling either result, even though the requests were independent and didn’t rely on each other. In cases like this, Promise.all() only adds complexity without any real benefit.

5. When Promise.all() Might Be Overkill

Sometimes, Promise.all() is overkill. If your async functions are independent, meaning one doesn’t rely on the other to complete, then there’s no need to bundle them together. They can run in parallel just fine without waiting on each other, and you can handle their results independently. This realization hit me when I saw that JavaScript already handles asynchronous tasks efficiently without needing to group everything together.

When to Avoid Promise.all()

Independent Async Functions: If your requests don’t depend on each other, they can complete at different times, and you can handle their results separately. There’s no need to wait for all of them to finish together.
Individual Loading States: In my case, I had individual loading spinners for each request, but I was unnecessarily holding everything up by waiting for both requests. It’s better to handle each request separately and update the UI as soon as each one finishes.

Example: Independent Requests Without Promise.all()

useEffect(() => {
  getChart();   // Trigger first async request
  getDetails(); // Trigger second async request
}, []);

In this setup, both requests run in parallel without needing Promise.all(). You can show individual loading states and handle each result independently, which is exactly what I needed for my project.

6. Real-World Scenarios for Using or Avoiding Promise.all()

Let’s look at how these concepts apply to real-world scenarios.

Scenario 1: Fetching Related Data (Use Promise.all())

Imagine you’re building a dashboard where you need to show user information and user purchase history together. In this case, you’d want to wait for both pieces of information to load before rendering the UI. Here, Promise.all() is the right choice:

const fetchData = async () => {
  const [userInfo, purchaseHistory] = await Promise.all([
    fetchUserInfo(),
    fetchUserPurchaseHistory()
  ]);
  console.log('Both user info and purchase history loaded');
};

Scenario 2: Independent API Calls (Avoid Promise.all())

Now, let’s say you’re fetching chart data and table data for a dashboard, and these two pieces of information are independent of each other. You might want to show a spinner for the chart and a separate one for the table. In this case, there’s no need to wait for both requests to complete together:

useEffect(() => {
  getChart();   // Fire chart request
  getDetails(); // Fire table request
}, []);

Both requests are independent, and you handle each of them separately, updating the UI as soon as each one completes. Promise.all() isn’t necessary here.

Conclusion: Don’t Jump on the Bandwagon

Promise.all() is a powerful tool, but it’s not always the best solution. I jumped on the bandwagon initially, assuming that using it everywhere would make my code better. However, I quickly learned that in cases where async functions are independent and have their own loading states, Promise.all() can actually make things more complicated.

Key Takeaways:

Use Promise.all() when you need to wait for multiple promises to resolve before proceeding.
Avoid Promise.all() when async tasks are independent, and you can handle them individually without unnecessary waiting.

Ultimately, it’s important to understand when and why to use a feature like Promise.all() instead of just assuming it’s always beneficial. After stepping back and re-evaluating my use case, I found that sticking with independent async calls was the right approach.

Positioning in CSS

Aryak Lahane — Tue, 19 Jul 2022 10:57:40 +0000

We come across many elements during the webpage creation, and each of these elements must be positioned on the webpage. For this, we have a position property in CSS. The position property is used to align the different elements on the HTML page. Position Property plays an important role in making high-quality web pages.

The CSS position property defines the position of an element in a document. The position property when accompanied by other properties such as the top, left, bottom, and right play an important role in designing a webpage

There are five values the position property can take. These are

Static
Relative
Absolute
Fixed
Sticky

Static

Static is the default value for the position property. In static position, elements are positioned according to the normal flow of the page. Left, top, right, bottom and Z-index don't affect an element positioned static.

Syntax:

selector{
position: static;
}

Relative

Relative positioned elements also remain in the normal flow of the page. But unlike static the properties of left, right, top, bottom, and Z-index affect the element positioned relative.

Syntax:

selector{
position: relative;
top: value;
left: value;
right: value;
bottom: value;
z-index: value;
}

Absolute

Absolute positioned elements do not follow the normal flow of the page. They are positioned according to the closest relative positioned parent. The properties of left, right, top, bottom, and Z-index to the element are given in accordance per the parent element containing the element which is absolute positioned.

Syntax:

parent{
position: relative;
}

selector{
position: absolute;
top: value;
left: value;
right: value;
bottom: value;
z-index: value;
}

Fixed

The fixed element does not follow normal document flow and position themselves relative to tag. This element always sticks to the screen. The properties of left, right, top, bottom, and Z-index affect the element positioned fixed.

Syntax:

selector{
position: fixed;
top: value;
left: value;
right: value;
bottom: value;
z-index: value;
}

Sticky

An element positioned sticky is basically the combination of position: fixed and position: relative. The element positioned sticky acts as a element positioned relative till a certain point on the screen. After that point the element starts acting as position fixed.

Remember that getting better at CSS takes consistent practice. So continue to practice and you'll improve.

CSS units & their types !

Aryak Lahane — Wed, 11 May 2022 17:12:00 +0000

Everyone needs to measure something or the other, the measurement units tend to differ according to the type of object that you have to measure, for a smaller object like the length of a pencil we would most probably use a smaller unit such as centimeters. For larger lengths like the distance between your house and your workplace, we may use meters or even kilometers and so on...

Such a system also works when we are designing web pages. For adding visual enhancement to the web pages we need to keep track of how much amount of space an element takes on the screen and adjust those measurements.

For making these measurements on the web pages we use CSS units. There are bunch of CSS units px, rems, ems, etc. But basically, the CSS units are divided into two major groups: Absolute units & Relative units

1. Relative Units

Relative units are as the name suggests relative their parents element's dimensions, the viewport dimensions or the font sizes.

1.1 Parents Dimensions (%)

The percentage(%) symbol is used to give the lengths of an element according to the lengths of their immediate parent's dimension. In the below example we have given width and height of the parent div (tomato background) as 200px and the child div (violet background) the width and height of 50%.

With some math we can find the width and height of the child div would be *50% of 200px i.e. 100px *

1.2 Viewport Dimensions ( vh, vw, vmin, vmax );

The viewport means the screen dimensions that the browser is occupying. The viewport can be equal to the absolute screen dimensions of our monitor screen but that's not always the case when we minimize the browser window or resize the browser window the corresponding viewport dimensions changes.

1.2.1 Vh and Vw

For these units, we need to imagine our viewport is divided into a grid of 100 rows and 100 columns. The height of the viewport is given by 100vh while the width of the viewport is given by 100vw. So each cell in the grid is of height 1vh and width of 1vw.

In the below example the div is given the height of 30vh and width of 30vw. you can play with the dimensions of the window and see the dimensions of the div change.

1.2.2 Vmin and Vmax

These are a pair of relatively lesser-known units. The unit vmin means that the side of the element depends upon the side of the viewport which has the minimum length. That is, if the height of the browser window is less than its width, 1vmin will be equivalent to 1vh. If the width of the browser is less than its height, 1vmin is equivalent to 1vw.

Vmax on the other hand is exactly opposite to vmin. It uses the ratio of the larger side of the viewport.

Understanding vmin and vmax can be a tad bit difficult. It is one of the reasons they aren't used widely in CSS. Moving on.

1.3 Current Font size ( em, rem, ch, ex)

Yup, you heard it right, we can also define the length of the dimensions of an element based on the font sizes. These are one of the popular ways used to define the lengths let's know more about them.

1.3.1 Rem and Em

Em stands for ephemeral unit which is most of the time related to the font size of the current element. Most of the time because if the font size of the current element is not given then em works according to the font size of the parent element.

Rem stands for Root em which means the root font size of the HTML. As default 1rem = 16px as long as we explicitly change it. Rems are preferred for making the web pages responsive as we can make changes everywhere by just changing the font size of the root in a single place.

1.3.2 Ex and Ch

Here comes the troll units. Yup! I said troll units because the length of 1ex is measured by the height of the letter 'X' in the current font size . Similarly the length of 1ch is measured by the width of the number '0' in the current font size.

2 Absolute units

Absolute units are the absolute measurements. They don't depend on any other elements they are standalone units. These are useful when you have to perfect measurements to the elements irrespective of any other conditions.

2.1 Pixels ( px )

Who doesn't love pixels? Pixels are the way the world works. Designs are made in pixels, web pages are rendered in pixels, JavaScript reads images in pixels and hence, because of all the above reasons and more, pixels are the most used units in a variety of fields.

in the below example we have given the container the height and width of 100px. This is what we simply get

2.2 Millimeters, Centimeters, Inches, Points, Picas

These names are all-familiar to us. The real-life units that are used in our day to day lives.

Below are the examples of each of them. Each of them in 5 units of their measurements

You'll be surprised at what you can do with CSS. The styling of the most opulent websites, with sophisticated features and lavish animations, all comes down to CSS. So, don't be afraid to play with CSS and try new things!

What is React ? Why React ?

Aryak Lahane — Tue, 10 May 2022 15:17:32 +0000

React, React, React you may have heard this term thrown around quite a bit in your web-development endeavor. Being a newbie myself I know how simple yet terrifying this word sounds. Being in doubt myself the initial step that we all take was to google it and there comes the monster a heck load of documentation, definitions, tutorials, tips, tricks, and whatnot. A simple question dropped me into a labyrinth of search results just enough to intimidate me to keep my curiosity aside and close the tab.

More than educating me this started to create a sense of fear around React. Why was there not a simple enough answer to my question. What is React? Why is there so much buzz around it?

So without getting into too much of technical stuff in the beginning, lets turn some pages back . Into the past we goo.

Before the JavaScript frameworks era almost all of the web pages on the web used to be built to the all-important trilogy of webpage building: HTML, CSS, and JavaScript. Each file would do its part. HTML was used to give the basic structure to the webpage and the content it held, CSS in turn was used to describe the HTML elements on how they should look and how will they be placed. While JavaScript was used to give functionality to these HTML elements. For even the simplest functioning webpage we needed to create an HTML file, a CSS file, and a JS file, and the tricky part of connecting the HTML elements with that JS functionality.

In the below example you can see that just for creating a simple button to display a msg when its clicked we had to write these three files with the distinct amount of code in each of them.

This was such tedious work for just the simple functionality. but as the complexity of the webpage goes on increasing the complexity of the code and becomes too much to keep account of.

In comes the framework era with various JavaScript frameworks being introduced namely jQuery, AngularJS, VueJS, React, etc. Sticking to React. React was introduced by a software engineer at Facebook in 2011.

Okay! enough of history now let us get to the actual details about React. Using the same example from above. It can be implemented in React in the following way. Don’t try to understand the syntax right now just look at the ease of code and the number of lines required

The advantage here with React is the HTML element (component) along with its JS functionality are all merged into a single JS file. Thus, reducing the work of writing those endless query selectors for every element that you are going to use and keeping a track of those variables associated with each of them.

Now think that we had to repeat the same button and functionality two times, ten times, or maybe a hundred times or even more. Think how ridiculous it would be writing the same code again and again and then the number of variables would be needed to handle that functionality on our old way of vanilla JS. This does not seem practical. Here comes the second advantage of using React component reusability .

We have just used the above example again but we have made 10 buttons here with 10 output messages , just look how easy it is to reuse a React component.

Hush, React is the savior for this case we just had to write the component once, and voila React lets me use it as many times as we want and we can just import the same component anywhere on my website and it would still work as it is told to. Such a relaxing feeling ain’t it !?

Though you know what isn’t that much of a good feeling when we are on a website and we just click on a button to go on some other page on the same website and it takes time to load that page. Like we are already on their website still for going from one page to another we need to wait ain’t fair, is it? Do you know what can help us in this scenario as well?

Yup! you guessed it right React ! with some handy React library we can create single-page websites i.e. pages within the websites load within the blink of an eye. sounds cool right no more waiting time. There is such a bunch load of other libraries that are made or being made to make your coding experience as easy and smooth as possible.

All you need to do right now is take that leap of faith! React is a fun tool to work around the more you work with it the more efficient it would get the more stuff you would know the easier the journey gets! So go ahead and begin your own React journey Chief!