DEV Community: Umang Mittal

The feature flags

Umang Mittal — Sun, 21 Sep 2025 06:06:32 +0000

Imagine launching a new feature to your entire user base, only to discover a critical bug that brings your application to a halt. The frantic rollback, the lost trust, the late-night fixes – it's a developer's nightmare. But what if there was a way to deploy new code confidently, test features in production with a small segment of users, or even turn features on and off at will, without redeploying your application?

Enter Feature Flags (also known as Feature Toggles or Feature Switches). In this post, we'll dive deep into what feature flags are, how they work, and how you can leverage them to build more resilient, user-centric web applications. Get ready to transform your deployment strategy!

The way the feature flag works is just be returning true or false and based on this condition your code will show new UI or the older UI.

That means you need to have the older + new logic in the code. Something like below:

const featureFlagClient = initFeatureFlagsClient();

const newUIEnabled = await featureFlagClient.get(
  "new-feature",
  false, // default fallback
  {
     context: { 
          //Any user details for which you want to pass to determine the 
     }
  }
);

if (newUIEnabled) {
  renderNewUI();
} else {
  renderOldUI();
}

So now, you have a ON/OFF switch to control the visibility of new UI. Even after it was deployed, it won't be available to anyone. Once you set the flag to true, then only the users will be able to see the shiny new UI that you just created.

Pros of using feature flags:

ON/OFF switch: You can just control the flow without the deployments and it also gives you a configuration you can change anytime
Safety Net: You can roll a new feature incrementally and rollback instantly that gives you a safety net if something goes wrong.
Beta Access: This enables you to roll feature for a certain individuals who signed up for using new UI in BETA mode.
No Deployments: If you want to enable or disable this new UI, you don't need to deploy the new build or revert any commit. All clean and good.

But not everything that shine is gold, if you use feature flags without giving it a much thought, you will find yourself in a technical debt very fast.

Things you should consider before

Complexity * Complexity: Yes, if you use feature flags blindly and think of it as one solution for most of the problems, you are adding a very thick layer of complexity in your codebase. Now, you have to maintain both the old and new features, as both can be used and anytime and nobody knows which ones are using in which cases.
Nested complexity: What if you used a feature flag inside of old and new UI features that are already under one feature flag. You are basically adding a complex nested flag based structure that won't go far enough.
Technical Debt: If you use feature flags for a deployment and never removed the feature flag after the users are successfully migrated to the new UI, then it will become a debt that either needs to paid and the more flags you have, the more interest that debt collects.

So, feature flags are a great way to roll out/test features on production without making them available for public, but only if you know what you are doing and you do it the right way.

Things to consider

While making the decision whether to implement feature flags or not, keep these things in your mind:

Ask if you really need it: Ask yourself whether you really really need the feature flag? If yes, keep reading: else exit;
Clean the clutter: If you are implementing a feature flag, make sure to assign a task to remove this feature flag if not needed afterward.
Document the requirement: And keep it documented, what is the need for this flag, the scope of this flag, when it introduced.

As we wrap up our exploration of feature flags, it's clear they are far more than just a temporary switch. They represent a fundamental shift in how we approach software development and deployment. By embracing feature flags, you're not just gaining the ability to turn features on and off; you are also reducing the stress and risk associated with every new release.

Implementing feature flags effectively requires careful planning and clear communication within your team. But the benefits—faster innovation, happier users, and more confident deployments—are well worth the effort.

So, next time you're planning a new feature, consider the power of the flag. It might just be the most impactful decision you make for your web application's future.

I hope this blog post made you learn something new or just pressed F5 on your knowledge system. Thanks for reading.

Umang Mittal signing off!

From Junior to Pro: Mastering Code Design with S.O.L.I.D.

Umang Mittal — Sun, 21 Sep 2025 05:58:23 +0000

In the world of software development, we often talk about building "good" code. But what does "good" really mean? Is it code that runs fast? Code that has no bugs? Or is it something more? "Good" code, at its core, is code that is easy to understand, maintain, and extend. It's code that doesn't crumble under the pressure of new features or unexpected changes.

This is where the SOLID principles come in. More than just a set of rules, they are a philosophy for building software that is flexible, resilient, and ready for the future. Over the next few minutes, we'll dive into each of the five SOLID principles—Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—and see how they can transform the way you write code. Get ready to move beyond the theory and discover how these principles can save you from late-night debugging sessions and make you a more confident, capable developer.

Let's take a look at them one by one.

S - Single Responsibility

Your class/function only has one RESPONSIBILITY and only ONE REASON TO CHANGE.

Suppose we are having a NotificationService class, the job of this class is to send Notification to user.

// ❌ BAD: This class has two responsibilities
class NotificationService {
  sendMessage(user, message) {
    // 1. Responsibility: Formatting the message
    const formattedMessage = `Hello ${user.name}, Message: ${message}`;

    // 2. Responsibility: Sending the notification
    console.log(`Sending: ${formattedMessage} to user: ${user.name}`);
    //Actual message sending code goes here...
  }
}

Here this function/class has two main responsibilities: Formatting the message + Sending the formatted message to user.

If we have to modify the formatting of the message to say "Hi" instead of "Hello", we have to modify the NotificationService class.

// ✅ GOOD: Each class has one clear job
class MessageFormatter {
  formatMessage(user, message) {
    return `Hello ${user.name}, Message: ${message}`;
  }
}

class NotificationService {
  constructor(formatter) {
    this.messageFormatter = formatter;
  }

  sendMessage(user, message) {
    const formattedMessage = this.messageFormatter.formatMessage(user, message);

    console.log(`Sending: ${formattedMessage} to user: ${user.name}`);
    //Actual message sending code goes here...
  }
}

Now, if you have to change formatting of the message, our NotificationService class needs not to be modified. Only MessageFormatter class will be modified. And if something needs to be updated in sending logic, only that class gets the update is the NotificationService minimizing bugs and achieving the "S" in SOLID.

The DIFFERENCE?
If you update the formatting logic, there could be a possibility that a new bug get introduced in sending logic (accidentally), which will break your entire message sending logic.
In Short, the blast radius is huge.
On the other hand, making changes in MessageFormatter means you are not dealing with any sending logic, even if a bug got introduced, the only risk is that the formatting of the message is done incorrectly, but the other functionality(message sending logic) still works great. You've contained the risk of change to only the formatting itself.
[What if other services are using the same NotificationService?]
In short, the blast radius is tiny.

O - Open/closed principle

Your class/function should be open for extension, but closed for modifications.

Simply put, you should be able to add new feature without changing the existing code. This prevents bugs in the code that already works.

Suppose we are having a NotificationService class, the job of this class is to send Notification to user.

// ❌ BAD: We have to modify this class for every new notification type
class NotificationService {
  sendMessage(type, message) {
    switch (type) {
      case "email":
        console.log(`Sending Email: ${message}`);
        break;
      case "sms":
        console.log(`Sending SMS: ${message}`);
        break;
      // 😱 We'd have to add a new 'case' for Push notifications here!
    }
  }
}

Suppose, we want to add a push notification to our sending logic, we need to modify the NotificationService class, which was already working fine + battle tested for bugs.
By modifying the logic inside the class/function, you are introducing a risk of accidentally creating bugs.
What if you forgot to add break statement in your new case block?
What if you changed some scoped variable in your logic?
For sending email, you need emailAddress, for sms you need phone number, for push notification you need device id, you are making the class bloated which is also
breaking the SRP(Single Responsibility) principle.

// ✅ GOOD: We can add new notifiers without touching existing code
class EmailNotifier {
  send(message) {
    console.log(`Sending Email: ${message}`);
  }
}

class SmsNotifier {
  send(message) {
    console.log(`Sending SMS: ${message}`);
  }
}

// ✨ NEW: Add a PushNotifier without changing NotificationService!
class PushNotifier {
  send(message) {
    console.log(`Sending Push Notification: ${message}`);
  }
}

// The main service is now "closed" for modification but "open" to new notifiers
class NotificationService {
  send(notifier, message) {
    notifier.send(message);
  }
}

Now, adding PushNotifier or any other type requires zero changes to the NotificationService.

The DIFFERENCE?
Updating the logic for adding the push notification functionality could potentially introduced new bugs + risks and could break the already working functionality for sms and email.
After the changes, adding new notification type service in our codebase is now easy and less error prone. No risk of disturbing the older services even if something breaks in the push notification as only those will stop working.

L - Liskov Substitution

The concept of this rule is very simple but yet it is hard to maintain.

Every child class should be substitutable with their parent class.

All child classes should extend the functionalities of the parent class not narrow down them.

Suppose you have a Notification class which takes in email and sends the message to the recipient. Enter a new GuestNotification class which also sends notification to the guest clients but only via push notification, because we do not have email addresses of the guests. So, we throw error in send function.

When we try to call the send function on this new class, our code breaks as we don't have the functionality to send message to guests.

// ❌ BAD: The subtype breaks the parent's contract
class Notification {
  constructor(recipient) {
    this.recipient = recipient;
  }

  send(message) {
    console.log(`Sending "${message}" to ${this.recipient}`);
  }
}

class EmailNotification extends Notification {}

class GuestNotification extends Notification {
  constructor() {
    // Guests don't have a recipient email, so we break the rule
    super(""); // This is already awkward
  }

  send(message) {
    // And now we can't fulfill the parent's primary function
    throw new Error("Guests cannot receive notifications.");
  }
}

function sendWelcomeMessage(notification) {
  notification.send("Welcome!"); // This will crash for GuestNotification!
}

sendWelcomeMessage(new EmailNotification("dev@example.com")); // Works fine
sendWelcomeMessage(new GuestNotification()); // 💥 CRASH!

To solve this kind of situation, we need to rethink the our design schema.
Perhaps GuestNotification shouldn't be a Notification at all, or we need a different abstraction.

// ✅ GOOD: All subtypes are safely interchangeable
class Notification {
  send(message) {
    throw new Error(
      "Method 'calculateArea()' must be implemented by subclasses."
    );
  }
}

class EmailNotification extends Notification {
  constructor(recipient) {
    super();
    this.recipient = recipient;
  }

  send(message) {
    console.log(`Sending Email "${message}" to ${this.recipient}`);
  }
}

class PushNotification extends Notification {
  constructor(deviceId) {
    super();
    this.deviceId = deviceId;
  }
  send(message) {
    console.log(`Sending Push "${message}" to device ${this.deviceId}`);
  }
}

function sendWelcomeMessage(notification) {
  notification.send("Welcome!"); // Works for ANY notification type
}

sendWelcomeMessage(new EmailNotification("dev@example.com"));
sendWelcomeMessage(new PushNotification("device-123"));

Now, any function expecting a Notification will work perfectly with all its subtypes.
In future, we can also integrate any new Notification Type and inherit the send message function the way that class expects and our Notification class can be used anywhere in the code.

The DIFFERENCE?
Instead os having child subclasses narrowing some methods or functionalities of the parent class, it should extend them. By this, we can make sure, wherever in our code we are using the parent class, we can expect the same functionality no matter the type of child class we receive.

I - Interface Segregation

Keep your interfaces lean and they will keep your code maintainable.

Client or New classes should not be forced to implement the functions or properties they don't use.

Suppose you have an interface of NotficationService for different clients. One clients only uses Push Notification service, and you inherit this with the NotficationService class.

The NotficationService interface is too fat and bulky that it forces the class to implement the methods that they don't use.

// ❌ BAD: This interface is too "fat"
interface INotifier {
  sendEmail(message: string): void;
  sendSms(message: string): void;
  sendPushNotification(message: string): void;
}

// This class only cares about push notifications but is forced to implement all methods
class PushNotifier implements INotifier {
  sendEmail(message: string) {
    // I don't do this! 🤷‍♂️
  }

  sendSms(message: string) {
    // Or this!
  }

  sendPushNotification(message: string) {
    console.log(`Sending Push Notification: ${message}`);
  }
}

To solve this situation, we break the bulky interface into smaller, role-based interfaces. A class can then implement only the interfaces it needs.

// ✅ GOOD: Small, focused interfaces are better
interface IEmailNotifier {
  sendEmail(message: string): void;
}

interface ISmsNotifier {
  sendSms(message: string): void;
}

interface IPushNotifier {
  sendPushNotification(message: string): void;
}

// Now our class implements ONLY what it needs. So clean!
class PushNotifier implements IPushNotifier {
  sendPushNotification(message: string) {
    console.log(`Sending Push Notification: ${message}`);
  }
}

// Another class could handle multiple types if needed
class AllInOneNotifier implements IEmailNotifier, ISmsNotifier {
  sendEmail(message: string) {
    console.log(`Sending Email: ${message}`);
  }
  sendSms(message: string) {
    console.log(`Sending SMS: ${message}`);
  }
}

This approach keeps your code clean, understandable, and prevents you from implementing useless methods.

The DIFFERENCE?
Now you can implement a new Notification Service for a new client that only uses email or both email and sms notification service.

D - Dependency Inversion

The goal of this principle is to decouple the modules.

The high-level modules or classes should not depend on low-level modules or classes, instead both should depend on abstractions (or interfaces).

Suppose you have NotificationService that creates an instance of EmailService. This means that NotificationService is tightly coupled to EmailService. In future, if we want to implement a new SMS service we need to modify the NotificationService class which could potentially lead to bugs related to sending email code which was already working fine and battle-tested.

// ❌ BAD: High-level module depends directly on a low-level module
// Low-level detail
class EmailService {
  send(message) {
    console.log(`Sending Email: ${message}`);
  }
}

// High-level module
class NotificationService {
  constructor() {
    // 😱 Dependency is created and hard-coded inside the class!
    this.emailService = new EmailService();
  }

  notify(message) {
    this.emailService.send(message);
  }
}

Instead of directly creating the instance of EmailService, we will create an interface or abstract layer that defines how the notification sending service should look like. And use this interface for telling our NotificationService to send message. And we do not create instance inside the NotficationService and pass it from the outside.

// ✅ GOOD: Both modules depend on an abstraction
// The Abstraction (the "what")
interface IMessageSender {
  send(message: string): void;
}

// Low-level details (the "how")
class EmailService implements IMessageSender {
  send(message: string) {
    console.log(`Sending Email: ${message}`);
  }
}

class SmsService implements IMessageSender {
  send(message: string) {
    console.log(`Sending SMS: ${message}`);
  }
}

// High-level module depends on the abstraction, not the detail
class NotificationService {
  private sender: IMessageSender;

  // The dependency is "injected" from the outside! ✨
  constructor(sender: IMessageSender) {
    this.sender = sender;
  }

  notify(message: string) {
    this.sender.send(message);
  }
}

// Now we can easily switch dependencies without changing NotificationService!
const emailNotifier = new NotificationService(new EmailService());
const smsNotifier = new NotificationService(new SmsService());

emailNotifier.notify("Hello via Email!");
smsNotifier.notify("Hello via SMS!");

This ensures that our code is ready. Even if a new notification type needs to be introduce, suppose push notification, we can use the interface (abstract layer) to inherit the properties and methods.
And no modifications are needed inside the NotificationService class.

The DIFFERENCE?
Even if you introduce a new notification service, you just need to use the abstraction to create it and even if you have accidentally introduced some bugs, they will only be for push notifications.
The Sms and Email notification service will work as it was working before.

You've now completed your journey through the five SOLID principles. From the Single Responsibility Principle, which teaches us to keep our classes focused, to the Dependency Inversion Principle, which frees us from rigid dependencies, these principles are more than just a theoretical framework. They are a practical toolkit for building software that is more robust, easier to maintain, and ready to adapt to the ever-changing demands of a project.

Adopting SOLID principles may seem like a challenge at first, but the long-term benefits are undeniable. Less technical debt, easier debugging, and the ability to confidently add new features without breaking existing ones are just some of the rewards. So, the next time you write a line of code, ask yourself: Is it SOLID? Your future self—and your team—will thank you for it.

That's it for this one. Thanks for reading and let me know your thoughts in the comments.

Umang Mittal... Signing off!

Crypto Trading project

Umang Mittal — Mon, 23 Jun 2025 03:48:02 +0000

Hey Devs and possibly traders,

In my college, I created a side-project that trades in cryptocurrencies with real money. So, I can make some profits and more importantly save myself from losses while sleeping.
It started like most side projects — I was bored, curious, and had just enough caffeine to believe I could beat the crypto market (spoiler: I couldn't, but it was worth it).

Let's start with the "BACKGROUND" first.

Background

At that time crypto was becoming mainstream and I was also fantisized by the wave of crypto currency. A decentralized network, sharing tokens without any third party, a mined block, and obviously a 10x or sometimes 1000x profits. ($ in eyes emoji).
So, I thought why not start trading in crypto. I created my account on CoinDCX and started trading with my first 500 ruppee.

After some time, I realized I was looking at the charts too often and everytime I get 10 min, between my classes, during lunch break, while traveling to and from college. And since I have a developer mindset, my dev instincts kick in. Why not automate this process? Can I make a script to do all that for me?

This small question lead me to creating my Crypto.trader() project. But I can't give you the exact code as it got deleted when my hard disk once crashed a few years back.

Nah, I am not building it in this blog, and even now that I think of building it, there's a whole lot of taxes on crypto and stuff. But, my dev instincts still want to create something like that again. Well, another story for another day.

By this blog, I just want to write down my experience of how a simple idea lead me to building a full-fledged project, and might be possible that someone's dev instincts kick in by reading this article leading to a new solution.

So, I digged in, did some research and found that coindcx has developer API, from which you can place order, get market details of a token like current price, cancel an order, get status of the order and much more.

Now my idea has a ground, let's create a script/bot that will run 24/7 and monitor the different currencies and get the market data, run some calculation, either place the order and after making profits sell it or hold it.

Back then, I did not understand the design diagrams and design patters, so I just created what I like.

Okay, Enough chit-chat. Let's get started

⚙️ My Very Own Crypto Bot: Overview

The idea was to build a 24/7 script/bot that:

Monitors market data of multiple currencies.
Runs some calculations using a tiny brain (i.e., an algorithm).
Makes a decision: buy, sell, or hold.
Places the order if needed, and logs everything and notify me like my well-wisher.

🧱 Architecture: Four Simple Python Classes

Portfolio

Handles everything market-related:

Fetches the current price of a token.
Places buy/sell orders.
Tracks wallet balance.
Maintains what tokens we hold.

Basically, it’s the bot’s bank account + market window.

Trader

This is where the magic (or nonsense?) happens:

Contains the algorithm that decides whether we should buy, sell, or hold.
Core logic lives in a method called decide_buy_sell_hold()

Logger

If it logs, it's real:

Writes all decisions and actions into a log.txt file. (Buy/Sell signal, at what time, at what price, for which token, etc.)
Sends alerts when an order is placed or an asset is bought/sold.

Crypto

This is the main orchestrator class.
It combines Portfolio, Trader, and Logger together and kicks off the loop.

Main class that packs all of these classes is called Crypto, hence I named it Crypto.trader(), because why not — let’s pretend Python has namespaces like Java.

Yes, you heard it right, I used python language to fuel up my idea.

🐍 Technology Stack

Language: Python (because of course)
API: CoinDCX Developer API, Twilio for messaging
Data Storage: Flat file logging (log.txt)
Runtime: A loop that sleeps between API calls and keeps the bot running 24/7
Deployment: Amazon EC2 instance

💸 The five senses of the Bot: Portfolio API's

This class deals with all kind of marketplace related things

Getting information about the token/coin
Placing/Revoking a market place order (BUY/SELL)
Polling on the pending order to mark if fulfilled or rejected.
If order is fulfilled, add it to the available to sell funds list and if the order is not fulfilled for 10 min, cancel the order and add the funds back into available funds.
Fetches the available balance from the wallet.

This class manages all the configs and available funds, so the Trader class can make an informed decision.

Whenever algo generates a buy/sell signal, the Portfolio class creates a corresponding BUY/SELL order, and put a watcher on it, that polls the order every 10 seconds to know if the order is fulfilled or rejected.

If the order if fulfilled, add the token/coin into the bought list so it can later sell it, when feasible.

If the order is not fulfilled for 10 min, cancels the order and add the funds back to the available funds so it can be used for buying a token later.

🧠 The Brain of the Bot: Trader Logic

The main logic of this bot relies in the Trader class, the trader class has a method decide_buy_sell_hold, which when called upon with params, return whether we want to hold the asset, buy it (if yes, at what price) or sell it if we already bought (if yes, at what price).

📜 Step-by-Step Process:
Step 1 Receive Token: The method is called with the token name (e.g., BTC-INR).

Step 2 Get Price History:

Pulls the last n prices (default 5) of the token.
Used to spot trends.

Step 3 Check If Can Sell:

Looks at Portfolio holdings.
Already holding this token? Okay, maybe we can sell or hold.

Step 4 Sell Conditions:
If prices are strictly decreasing → look deeper:

If current loss > 5%, sell (stop-loss).
If current profit > 20%, sell (profit booking).

Step 5 Check If Can Buy:

Looks into the Portfolio wallet.
Enough balance? Okay, maybe we can buy.

Step 6 Buy Conditions:

If the last 5 prices are strictly increasing (bullish trend).
AND we have money → return BUY signal with price.

Step 7 Else:

No condition matched → return null (HOLD).

🦾 Treasurer and Notifier: Logger

The main objective of this class is to log everything in txt files so there is a written log of everything happened, why it happened and if the bot needs to restart itself, it knows what it already has in account and when it bought it at what price so it can take right decisions.

Logging Mechanism

Whenever algo generate buy or sell signal, timestamp, when the market order is placed, when it got fulfilled or rejected, what was the market depth when the decision was generated, and more. It writes everything down in txt files.

algo_logs.txt

One txt file is to log all of the decisions that algo takes and parameters that made that decision possible.

portfolio_summary.txt

And One txt file is to maintain the config, what currencies to trade in, current order statuses, available funds, what we have in portfolio, when we bought at and at which price point. All the data that the bot can read again if it restarted so it knows what it was doing, funds, and other things. This helps, when I want to change some code or something so the process needs to be restarted.

Notifications

As for the notification part, I used Twilio's API for sending whatsapp messages to myself whenever the bot buys, or sells and at what price. Just to loop myself in and to know if I'm broke or not.

Twilio provides a way so you can send whatsapp messages to any number, so I integrated it to send me a notification when the buy/sell order is placed and when an order gets fulfilled or rejected.

⛭ Deployment

Since I need to run this script 24*7, I chose Amazon's EC2 instance, the basic and Free for 1 yr plan. I uploaded my code directly on the instance, setup the configs, and ran the script hoping I would not go bankrupt.

💰 Finally, let's count the money

Time for the results, we all are waiting for.
I ran the script first time with real money and let it run for one night.
In one night, it made 18Rs. profit. I know it wasn't enough but hey it was just testing.
So, I tuned in some more parameters and let it run for one full day. It made 84.6 rs profit on that day.
After this, I found that if created an order but since the service restarted, it never pulled the status and it never counted it as bought. Here goes, my 342 rs.
I fixed the bug and ran the script again with a max limit on one order of 100 rs. just to keep myself safe from huge losses.

After all the initial tests and fixes, I let it run for about one week. Since I capped the order value to 100 rs. and adjusted the params defensively, it didn't made huge profits.
In first half of the week, it made -23 rs. (yes negative)
And after a whole week, 47 rs. profit (total)

If I've increased the cap, it could've made more money (HOPE), but can't say it might screw up and I could've lost all money.

Because when I checked logs, I found some bugs again which is causing the buying/selling at unfavourable prices. After my semester exams, when I started debugging it again, that's when my ssd fails and since I killed my EC2 instance, the data was also gone. (All hard work gone)

😅 Things I Would Change (But I can't)

Now, that I think of what I could've improved if that project kept running?

Putting in AI into my algo, so it could make more advanced decisions.
Adding in some more information like market sentiments, trending crypto's, news sentiment regarding crypto and other factors so my algo can make more informed decisions.
Use proper exception handling (not just try: except: print(e) 🙈).
Store logs in a database instead of a text file.
Add a web dashboard for live alerts.
Use design patterns like Strategy or Observer, because I now know they exist.

✍️ Conclusion

This bot wasn't perfect, maybe my algo was the culprit or my lack of skills that created the bugs, or why haven't I pushed my code on github or... or... or..., but it taught me more about APIs, automation, and trading logic than most tutorials ever did. Sometimes, the best way to learn is to build something just a little beyond your understanding.

If you’re a dev who loves creating automation scripts and finds finance interesting — give it a shot. Build a bot. Lose some fake money. Learn a lot. 🧠

Thank you for reading about one of the coolest project I built and meet you again.

Umang Mittal
Singing off !!

Behind the Query: The Secret Life of Database Indexes

Umang Mittal — Sun, 04 May 2025 06:12:16 +0000

Hi developers, I hope your database queries are not taking much time to find the records. But if they are... well, that's why I am writing this article.

Before diving into the secret life of our database indexes, let's first understand why do we even need them in the first place.
Can't we use our database without them?
Are my queries slow if I don't use them?

Answer is, "Yes" and "No" both. Let's look at it.

Why should you even care about indexes?

Database can work without using indexes as well but think of the index as a separate lookup table where only the indexed fields are stored along with a pointer to the memory location of the actual record.
Simply put, An index is a data structure that helps find rows fast without scanning the whole table.

Think of it like this:
Suppose you have a 1000 page dictionary with you. Now if you want to search a specific word, you don't search every page, instead you search it alphabetically which reduces the number of lookups in dictionary to find the right word.

Indexes work the same way, when you create index on a field, the field is now copied in a separate collection which only holds the indexed field's values and a pointer. Now, when a query is performed on the database, the database determines which indexes to use. If it finds an index on the filtered or sorted field, then it uses index table to find the record instead of going through a million records.
And obviously, it is fast.

In a nutshell we can say,

"Indexes are the difference between instant results and your app timing out."

But, How does it makes my query faster?

To simplify this, let's take an example. As we know that all the data is written into the disk memory and in our disk, the data is stored in blocks. For our example, let's say one block stores 4 kilo bytes of data (just assume).

Now, Let's look at our database table which we will use for the demonstration.

The table looks something like this:

Let's assume one row of this table takes 400 bytes of disk storage. Now if we calculate, that means ~10 rows/records are stored in one block of disk. That means 1-10 rows are stored in block-1, 11-20 rows are stored in block-2, and so on.

Our table has 1000 rows, which means 100 blocks are required to store our table.

Everytime we need to read even a record, we need to read the whole block, load it into the memory and then do the operations.

Okay, now our user wants all the students whose age is 16.
If user performs this query, we need to go through each block, load it into the memory and then read the 10 rows and check every row if it contains the student with age 16.

Hypothetically, let's assume that one block read takes 1 second to read. According to this, we can say that, to read 100 blocks we need 100s that means your simple query is now taking 100 seconds to fetch the results.

What if we now have indexes on the field age:
The indexed field is now copied to new collection like this:

Now, let's say this row takes 40 bytes of storage. And we have 1000 rows, that means 40,000 bytes we need.
To store this in the disk, we need ~10 blocks to store the records.

And now if we consider the same query, and this time the indexes are used.

Read the whole index table, 10 seconds (10 blocks)
And let's say we found 10 records and those all records are distributed in 10 blocks(worst case). To fetch these records, we need to read the whole block, means 10 seconds again.

If we calculate,
10s(to read index table) + 10s(to fetch the actual records) = 20 seconds.

This is a significant gain in our case, from 100 seconds to 20 seconds. This is ~5x gain in results fetching, and that's huge. And if you scale this to 1 million rows, the effects are significant.

Again, these calculations are just hypothetical, just to prove the index fields are faster and why.

But hey I heard that indexes uses B-tree, and this is just a lookup table.

Yes, let's get into some real optimization.
Now, if you know that indexes are stored in B-Tree, we can divide this lookup table into a B-tree where one node(with multiple values) acts like one block of storage.

Now, if I store the index table blocks (10 blocks) to a B-tree like structure(except you've always seen B-tree vertically, but here think of it as horizontally mounted B-tree).

If the value is between 8 and 9 look into block 1, if it's between 9 and 10, look into block 2 and so on.
And to store this new index-lookup table (B-tree), we only need 1 block as there are only 10 entries in the table.

Then in this case, user is searching for age is 16. Then, we only read the root node of B-tree (1 block) and found that which block we have to read to get the data, then read that exact indexed table entry and then the actual records.

Load B-tree in memory (1 block)
Find required pointer(pointing to the index table block) using log(n) time
Load the founded block in the memory
Finally, load all those blocks required from the main table

Finally, this is how our table looks like:

Now, if we take a look, 1 block to read the main root table (B-tree), find the blocks where the the required block is stored that lies in user-filtered range, then read those block(s), 1 block again and then find the 10 items that are (worst case) splitted into different blocks.

Calculations:
1 block(B-tree) + 1 block(indexed records) + 10 blocks(full records) = results
1s + 1s + 10s = 12 seconds, all the way from 100 seconds.

Huh, that's a lot of things going on there. Hope, I was able to make you understand how indexes improve searching time.

I get the gist, but can you explain B-Tree more?

Gotcha friend, The indexes are not stored in the table itself where it is created. It is in a separate database structure in itself. A whole collection where only indexed fields are stored. And The most common approach to store the indexes are in "Balanced Trees" (also known as B-Trees).

Data is stored like this:

Image source: qwertee.io
If you want to learn more about B-tree index in detail, refer this blog by qwertee.io.

Why B-tree? because searching time in B-tree is very less compared to other data structures.

You might argue that Balanced BST and B-Tree are having similar times, what's the difference?

Think of a B-Tree node as a block (like a disk page) — reading one node gets you many keys at once, minimizing costly I/O. The height of the tress is low as compared to Balanced BST as B-Tree has broader nodes.

How DB determines when to use index table or full table scan?

SQL: A Multi-Stage Process

Relational databases like PostgreSQL, MySQL, and SQL Server follow a classic architecture for query execution:

Parsing – SQL is parsed into a syntax tree.

Planning/Optimization – The query planner analyzes different strategies, using available indexes, stats, and constraints.

Execution – The most efficient plan is executed, often using indexes to avoid full table scans.

Example: If there's an index on email, the planner chooses an index scan instead of a sequential scan of the whole table.

SQL: Parser → Optimizer → Executor → Storage Engine

NoSQL: Indexing is Not Optional

In NoSQL databases like MongoDB or Cassandra, there's no table scan fallback (or it's extremely slow). Efficient querying requires indexing.

MongoDB uses a query planner similar to SQL engines but works with JSON-like documents.

Cassandra relies heavily on partition keys and secondary indexes, designed around high-throughput, distributed access.

If there's no index in MongoDB, a full collection scan is performed—which can be expensive.

NoSQL (e.g., MongoDB): Query Engine → Query Planner → Cursor Traversal.

How can I determine if my query is taking benefit of indexes?

MySQL – Use EXPLAIN

Syntax:

EXPLAIN SELECT * FROM users WHERE email = 'test@example.com';

What it shows:
Whether it's using an index (type = ref or index)
What index is being used (key)
How many rows are being scanned

To see all indexes on a table:

SHOW INDEXES FROM users;

MongoDB – Use .explain()

Syntax:

db.users.find({ email: "test@example.com" }).explain("executionStats")

If you see "stage": "IXSCAN" → you're using an index

If you see "stage": "COLLSCAN" → full collection scan ❌ (slow!)

To see all indexes:

db.users.getIndexes()

Some common pitfalls

If you think that you apply index at every field and your database now becomes blazingly fast, where it can query in nano-seconds, fellow dev, that's not the case.

Too many indexes = slower writes Yes, if you apply indexes on a certain field that means a index tree will be created and every time the field value gets updated, the index-ed tree needs to be updated as well to place the new value at the right place(leaf).
Wrong order in composite indexes While you can create composite indexes, which includes multiple fields, the order of the index matters. If you search in the exact order then only the indexes will be used.
Indexing low-cardinality columns (e.g., gender, boolean) If the field only has a limited variation of values like if it's a gender field or an isActive boolean flag, the index tree created is only divided into less number of branches, resulting in a normal scan. It's faster than not having an index, but not much faster.
Forgetting to reindex after big migrations or bulk operations After adding new fields or data migrations, look at the fields again to ensure that the new field is indexed (if required).

When NOT to Use an Index

Let's see when you should not use indexes:

Small tables where full scan is faster
If the table is small, has less data, couple of thousand records then creating and maintaining indexes are heavy tasks compared to light weight searches.
Frequently updated/deleted fields (causes index maintenance overhead)
Pretty self explanatory, if an indexed field is a updates or gets deleted frequently, then indexing it might not be a great idea as it increases an index updation overhead on the database.
Write-heavy workloads where read speed isn’t crucial
Indexes slow down the write operations. If the field is a write heavy field, better if leave it as is.

So, let's wrap up the indexes section this time. Hope you learned something new or brushed up some already known indexes life.

Let's end this post, with an un-indexed line :

An unindexed query walks into a bar. It takes forever to find a seat.

That's Umang, signing off!!
Thanks for reading this post.

useEffect: The Hook That Keeps You Guessing (And Refreshing)

Umang Mittal — Mon, 17 Feb 2025 06:39:23 +0000

Hi my developer community!

Let's be honest, useEffect is one the most used hook in the React Eco-system. We all have at some point in our development life used this hook for running some side-effects.

Let's learn some advanced things about the useEffect.

We all know that useEffect is used to trigger any side-effect in your React component.

The syntax of useEffect is:

import { useEffect } from 'react';

useEffect(callbackFn, dependencyArr)

Dependency Array

Well, in my experience in taking interviews I asked this question a lot. What would happen if I don't pass any value in the second argument of the useEffect?

And mostly candidates say, "The callback function will run infinitely". That is not the correct answer. And it also shows how much experience they have with the useEffect hook.

Let's try doing that.

I have one console log in the component's useEffect and one outside of the effect. Notice that there is not dependency array in the useEffect hook.

And here is the output:

As you can see there is no infinite logs. That means useEffect hook only runs on every render when there is no dependency array.

Cleanup Function

Sometimes, we attach an event listener on the mount of a component. But have you wondered what happens when the component unmounts. Does that event listener gets destroyed?

To demonstrate, let's attach a keyup listener on the mount of child component and unmounts the child component after 3 seconds.

CAUTION: For demonstration purpose, I have removed the Strict Mode provided in React to demonstrate the deployed version of outputs.

Now, even after the child component unmounts, the event listener is still active and I can still see the logs when I press any key. That proves the fact that event listeners will still mount even when the component itself unmount.

To resolve this we have a cleanup function in useEffect. This will run before the callbackFn and on unmount of the component (I know sounds confusing but I will explain).

Some Dev's say it will run only when the component unmounts which is not entirely true. According to React dev docs:
React calls your setup and cleanup functions whenever it’s necessary, which may happen multiple times:

1. Your setup code runs when your component is added to the page (mounts).
2. After every re-render of your component where the dependencies have changed:
    - First, your cleanup code runs with the old props and state.
    - Then, your setup code runs with the new props and state.
    - Your cleanup code runs one final time after your component is removed from the page (unmounts).

So, if you have given some dependencies in the dependencyArr, then the cleanup function is called before it runs the side-effect again and in case of empty dependency array it will run on unmount.

Order - Order

Now the basic things out of the way, let's understand the execution order of useEffect in a Parent-Child relationship.

In this code, as you can see we have console logs out of the useEffect and inside useEffects as well. So, try to solve it without looking at the solution.
Note: I have disabled React.StrictMode to make the console look cleaner, but if won't make any difference in the order of execution.

The answer:

Hmm.., If you think the Parent's useEffect should've run first, here you got the answer.

Why??
React prioritizes effects in the child components before the parent to ensure that effects affecting the child’s layout or behavior are handled first. This helps to avoid potential issues like the parent reacting to changes in the child that have not yet been fully applied.

And what would be the order of the cleanup functions, is it the same or different?
Let's tweak our little example to see the result:

So, Now we have two useEffect's in both the components. I introduced a count variable just to re-render the parent and child and passed that as a prop to child component.

And yes, the order of the useEffects being registered also matters. If both the side-effects needs to run, the one that registers first will run first.

Let's see what would be the execution of this. As an exercise, you can think of a solution first before looking at the console.

what we've understood so far seems to be working here as well. First we have both parent's and child's outer console's and then useEffect console's. Child's first and then parent's.

Now, let's see what happens when you update the state. In our case, clicking on the button.

I am going to put a console log "Button clicking event" to segregate the output of before the button clicked and after the button is clicked.

As you can see, Parent and child render comes first.
Next up is the cleanup functions. And yes, in the reverse order again.
After the cleanup functions, we again have the side-effects running similarly.

Note: For the simplicity, I've removed the React.StrictMode

I guess that's it for the post, I hope you have gained some extra knowledge of how React works by attaching events and the order of execution for useEffect by reading this post.

Thanks for reading, I'll code a bug next time.
That's Umang, signing off.

Do you think you know Context API in React.js?

Umang Mittal — Sun, 15 Sep 2024 16:07:05 +0000

Hello folks! Hope you're all doing awesome.

Today I want to ask you about the Context API available in React.js.
We all know that it solves prop drilling problem and we should not use it in the complex projects and all. But why we say that. Let's explore that.

So, you might be saying I already know about context API, let's skip this post. WAIT fellow developer... atleast read and find out.

Note: I am not going in the basics of what and why we need context API.

Project Setup

I am going to creating three components named Parent, Child1 and Child2. And a Counter Context for storing the counter value.

Parent Component

Child1 Component

Child2 Component

As you can see we have a button in component to increase the counter value and using the CounterContext in Child1 only.

The output looks like this:

Adding Console logs to determine the rendering flow

Now that we've created the components, it's time to add the console log statements to determine how the rendering is happening.

So, I added a simple console logs like these in all of the components:

If I now open the console of the output window, below are the logs:

Some might ask why we are having two same logs for one console logs statement, well that's because of the React's Strict Mode(Another topic for another day!)

Back to the topic, What do you think will be the output if I click on the Increment button?

I cleared the console and clicked on Increment.

Hmm, Same thing again.
Well yes, whenever we change the state stored in the Context API, only the children components using the context will gets re-rendered.

This dips the performance of React as it has to re-render even those who do not have any linking to the context.

Next time, think about whenever you change any state in the Context API in your project because if you change the state all the components wrapped inside will get re-rendered no matter if they uses the context or not.

That is one more reason people uses different state management techniques like Redux. As in Redux, if the component is using the variable that gets changed, only then it will re-render.

Okay, let me ask you one more question. What if I use React.memo() to wrap my Parent, Child1 and Child2 components? What would happen?

When the button is clicked, will
No component re-renders
Only Parent and Child2 re-renders
Or, all of them

Let's see:

Now if clicked on Increment button:

If you chose Option 2, Congratulation you got it right.

That means, even if you memoize the components, and triggers an state update in the Context. Only the components that uses the context will get re-rendered.

But what if I just declare the useContext hook inside the Child1 component. Not going to destructure or access any state from context. What do you think would happen?

Now when clicked on Increment counter:

As you can see, even when you are just using the context and not the state that gets triggered, the components accessing the context will get re-rendered.

Final Thoughts

The Context API solves the problem of prop drilling and is great if used in smaller contexts/applications. But when the application state gets complex or you have a large number of components accessing and updating the state, Context API is a No-No. Try using Redux or any other state management libraries and you will save yourself from a ton of re-rendering.

Thanks for reading and I will see you in the next one.

Keep developing your bugs.

Okay, so that's Umang Mittal signing off.

My TOP 10 GoTo Vs code Extensions

Umang Mittal — Sun, 01 May 2022 13:33:16 +0000

Hello folks! Hope you're all doing awesome.
Today I want to share with you guys my most favourite and most useful VSCode Extensions that increases my productivity as well as the look and feel of my code editor.

I am going to divide the extensions into parts, which affects my design of the editor, which increases my productivity, which are a must to have, etc.

These extensions are my personal choices which might differ from yours, which I totally agree. These extensions help me to get better out of my coding time.
So, without a futherado, let's roll in to see what I was talking about.

Section1: Setting your VS code Theme

1. Atom Material Theme by Tobias Althoff
This extension provides Atom inspired color theme which in my opinion looks dope. I rock this in all of my vs code fragments whether I am on my laptop or desktop.
I like the way it looks and feels. Here's a look at it.

2. Material Icon Theme by Phillipp Kief
The Material Icon theme is one of the great extension out in the market which has over 52 Million downloads and still growing. It offers various icon themes for every file extension and also the standard folder icons which automatically change depending upon the name of folder like "assets", "images","android", "gradle","components" and what not.
See Pictures below.
File Icons

Folder Icons

Section 2 : Productivity Increasers

This section is devoted to the extensions that increases my productivity either by adding some common shortcuts or by doing some underling task.

3. Better Comments by Aaron Bond
This extension, as the name suggests, help you create more human-friendly comments in your code.With this extension, you will be able to categorise your annotations into:

Alerts
Queries
TODOs
Highlights
Commented out code can also be styled to make it clear the code shouldn't be there
Any other comment styles you'd like can be specified in the settings

With this VS extension, you can use the following characters after a double forward slash // to add easier commenting:

* for highlighted text
! for errors and warnings
? for queries and questions
// for strikethrough
TODO for to-dos

4. Auto Rename Tag by Jun Han
This Vs code extension is very useful if you are a web developer as it automatically rename the paired HTML/XML tag.
I like this extension because I don't have to manually change the other HTML tag if I've changed the paired one. Well, obviously if you changed one tag you have to change the other, right?

5. Live Server by Ritwick Dey
The next extension we have on the list is probably the most used and well-known extension in the web community.
If you've ever write HTML/CSS, you know every time you make changes you have to save those changes and reload the web page to see those new changes.
But, With the help of this extension we do not have to reload the webpage anymore, it adds a script (behind the scene) in the end of your HTML document which helps it auto reload whenever you save the changes.
Here's the demo.

6. Prettier by Prettier
The Prettier extension here does not need any introduction. This is one of the most used extensions out in the market. Prettier, as the name suggests, formats the document whenever you hit the ctrl+s. It automatically beautifies the document.
Here's what is written on the official documentation page of Prettier.
"Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary."
The great thing about Prettier is that it supports a ton of languages and editors which makes it stand where it is standing now.

Section 3: A Must to have and productivity multipliers

7. Advanced New file by Patbenatar
This extension gives you the power to create a new file without even touching your mouse/touchpad which in turn decreases the time it takes to switch between keyboard and mouse/touchpad.
Features:

Fuzzy-matching autocomplete to create new file relative to existing path
Create new directories while creating a new file
Create a directory instead of a file by suffixing the file path with / as in somedirectory/ to create the directory
Ignores gitignored and workspace files.exclude settings.
Additional option of adding advancedNewFile.exclude settings to workspace settings just like native files.exlude except it explicitly effects AdvancedNewFile plugin only.
Control the order of top convenient options ("last selection", "current file", etc) via config setting advancedNewFile.convenienceOptions.

After installation, hit "ctrl+n" whenever you want to create a new file, provide the folder in which you want to create the file, press enter, now provide the file name with the extension to create the file, you can also create a folder just add "/" at the end of the new file and extension will create a new folder like: folder/filename.fileextenstion.

8. Git Lens by GitKraken
If you are working with the git and with a team of programmers, you definitely wants to see this extension. This does not add git into vscode, rather is supercharges the git by adding some cool new features.

It helps you to visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more.

GitLens simply helps you better understand code. Quickly glimpse into whom, why, and when a line or code block was changed. Jump back through history to gain further insights as to how and why the code evolved. Effortlessly explore the history and evolution of a codebase.

Current Line Blame

Git Code Lens

And Much more.

9. Quokka.js by Wallaby.js
The Quokka.js extension is provided by Wallby.js. It is a javascript/typescript playground which can make your life a lot easier if you use pure JS/TS.
Quokka.js runs JavaScript and TypeScript with instant feedback. Runtime values are updated and displayed in your editor next to your code, as you type.

Code runs immediately as you type, on unsaved changes; no need to do anything manually or switch context. Error messages are displayed right next to the code that caused them. Console logs and identifier expression values are displayed inline as well.

It offers some cool features like:

Live Execution and results
Live coverage
Time Machine
Code Stories
Value Explorer
Live Comments and values
Project Files Import
CPU Profiler
Quick Package Install Note: some of these features are only available in pro version.

10. Turbo Console log by ChakrounAnas
Last but not least is the Turbo Console Log. This is one of the most used extension by me and my team members.
Have you ever had to log the variable to the console to know what is the response of the network call, what is the value of this variable at this point of time. And after writing many console logs, when you open up your browser's console, you see a ton of consoles with no meaning.
I know I've been there. Turbo console to the rescue.
This extension make debugging much easier by automating the operation of writing meaningful log message.
Suppose, you want to log the value of param in this function foo. If you have this extension installed and enables, just select the variable and hit the shortcut- "ctrl+alt+l" and you will get the message like this.

function foo(params){
    console.log("🚀 ~ file: demo.js ~ line 2 ~ foo ~ params", params)
    return true 
}

foo("bar")

This message is more meaningful as it exactly tells from where this log is generating,right? It has filename, line number,function name, and the variable's name in it.

PS

So, that was my top 10 vs code extensions that I rock all the time whenever I code, they not only increases my productivity but also adds a bit more elegance to my code editor.

Hope you liked them. If you have some recommendation, just let me know in the comments. I will definitely try them and probably include it the next time I create a extension list.

Okay, So that's Umang Mittal signing off!

The Rest and the Spread operator of JS

Umang Mittal — Mon, 25 Apr 2022 01:56:41 +0000

Hello folks! I hope you are all doing great.
Ever heard developers talking about "spread" operators or just saw "..." [Triple Dots] in JS code and wondered what is this thing.
Well, we're going to cover that today.

The syntax of rest and spread operator looks exactly the same but they are polar opposite of each other in terms of functionality.

Let's look at both of them one by one.

The Rest operator

The rest operator is used to take an indefinite number of arguments in a function and condenses it to an array.
Example:

function foo(...bar){
    return bar;
}

console.log(foo(1,2,3,4));  // [ 1, 2, 3, 4 ]
console.log(foo(1,2));  // [ 1, 2 ]

Whatever the number of parameters you pass into a function the rest operator collects all the arguments and "condenses" them into an Array which can be useful in a lot of cases.

It can also be used like this:

function foo(a,b,...bar){
    console.log(a);  // 1
    console.log(b);  // 2
    console.log(bar);  // [ 3, 4 ]
}

foo(1,2,3,4);

What we've done is told the function that we are going to pass "a", "b" and whatever we pass after that, condense it into an array.
Now, you might me thinking of some edge cases like "what will happen if I ... ". Don't worry I am getting on that too.
What happens if I pass no value for the rest oprator?

function foo(a,b,...bar){
    console.log(a);  // 1
    console.log(b);  // 2
    console.log(bar);  // []
}

foo(1,2);

Here, the rest parameter does not gets any value which results in an empty array.

But, what happens if I shift the rest parameter to the first or the second position?

function zen(a,...bar,b){  // SyntaxError: Rest parameter must be last formal parameter
    console.log(a);
    console.log(b);
    console.log(bar);
}

zen(1,2,3,4);

This will not run. The reason is clearly mentioned in the error.
The rest parameter must be the last function argument.

Now that we know, what is rest operator. Let's look at a use-case.

Suppose, you were said to create a function that takes two values and returns the sum of them. Easy? isn't it. Let's escalate it, Now you need to create the same function but there could be any possible number of parameters and your function must return the sum of all of the arguments.

One approach is that you create different functions for different number of parameters. Now that you know the rest operator, you must'nt worry about that.

function addValues(...values){
    let sum = 0;
    for(let i = 0; i< values.length;i++){
        sum += values[i]
    }
    return sum;
}

console.log(addValues(1,2,3,4,5))  // 15

Note: I know I could've used foreach or even reduce method to do the same task but to keep this post general for all the people, I used the for loop.Well, another topic for another day.

The Spread operator

Earlier, I told you that both rest and spread has same syntax and still they are opposites of each other.
Where rest operator takes multiple values and condenses them , the spread opeartor expands the object values.

const arr = [1,2,3,4];
console.log(arr);  // [ 1, 2, 3, 4 ]
console.log(...arr);  // 1 2 3 4

As you can see the spread operator spreads the value of the array and it also works on the object.

Spread Operator can be used in many different tasks like:

Copying an array
Adding to state in React
Concatenating or combining arrays
Using Math functions
Converting NodeList to an array
Using an array as arguments
Adding an item to a list
Combining objects

The spread works on the objects too.

const obj = {
    "hello" : "world",
    "foo" : "bar"
}

console.log(obj)  // { hello: 'world', foo: 'bar' }
console.log(...obj)  // TypeError: Found non-callable @@iterator
console.log({...obj})  // { hello: 'world', foo: 'bar' }

You can create a clone of an object and updates it's value with the help of it's key.

// Creating array
const arr = [1,2,3];
console.log([...arr, 4,5]);  // [ 1, 2, 3, 4, 5 ]

// Creating Object
const obj = {
    "hello" : "world",
    "foo" : "bar"
};

console.log({...obj, "foo" : "zen"});  // { hello: 'world', foo: 'zen' }

Final Thoughts

The rest parameters and the spread operator has become an integral part of any web project since it's launch. I hope I made both of them clear to you.
Thanks for reading.

Okay, so that's Umang Mittal signing off.

JavaScript is a little weird!!

Umang Mittal — Wed, 20 Apr 2022 03:17:43 +0000

Hey Folks, Hope you're all doing great.

Today, I wanted to talk about some weird things that are really really weird about Javascript language and not only in JS, some of them are also applicable in other programming languages.

Let's start with the basics.

What is Javascript?

Well, Javascript is a scripting language that conforms to the ECMAScript standard. And you know, its initial release was built in only ten days back in December, 1995.

What I was talking about.

But Js is a little bit wierd and it doesn't always behave the way you might think and does not produce the expected output.

Note: Even senior JS developers don't use some of these syntax'es. This post is just for showing how quirky js can get.

Talk is cheap, show me the code

Here you go,

if(0.2+0.1 == 0.3){
  console.log("Foo");
}else{
  console.log("bar");
}

Output: bar
Try to expect the output, you might say it will log out "Foo". But that's the catch, if you do something like this you can see why it logs "bar".

That's just the problems with the programming languages not particularly with js. Programming languages lacks the base 10 accuracy. Let's see what I mean.

console.log(0.2+0.1);   //0.30000000000000004

So obviously, 0.30000000000000004 is not equals to 0.3

Okay, the next one.

console.log([,].length);  //1

So, the array has 2 elements, right? One before the comma and one after that (Even though they are empty). But JS treats this as only 1 element. In Js, until and unless you pass the value to the last position (after the last comma) of the array, it will not treat this as a value and will not insert it into the array but that's not the case with the other positions.
The last comma is called the trailing comma
And you will find it everywhere in the JS code, like

const example = {
    foo: "foo",
    bar: "bar", // 👈🏻 here you can see a trailing comma
};

Here's the example.

console.log([1,2,].length);  //2
console.log([,,3].length);   //3

Here, when you pass nothing in the last position, the array's length is 2 but when you pass only the last position it still counts all the other values.

One More
We all at one or the other point in time of our coding journey used increment operator.
Let's look at that in JS.

console.log(++1);  //Error
console.log(++true);  //Error

Well, to be honest, it's giving an error not because of JS, but due to the fact that we are trying to mutate an already defined value.

You might say that increment operator might not exists in Js. But let me tell you that the syntax is absolutely correct.

let foo=1;
console.log(++foo);  //2
let bar = true;
console.log(++bar);  //2

This is a valid syntax but it only works with variables.
And this is not the case with Js only, it works the same way with Java, C and many more programming languages.

The last one

console.log((10,2));  //2
console.log((2+1,3+1,1));  //1
console.log((2-1,3*1,1+1));  //2

The comma operator evaluates its operands, from left to right, but returns only the last operand.

The definitely last one

const arr1 = ["a","b","c"];
const arr2 = [1,2,3];
console.log(arr1+arr2);  // a,b,c1,2,3

This happens because when you try to concat two array's, they will first get converted into strings and are then concatenated.

If you really need to concat two arrays, you should use the "spread" operator.

const arr1 = ["a","b","c"];
const arr2 = [1,2,3];
console.log([...arr1 , ...arr2 ]);  //[ 'a', 'b', 'c', 1, 2, 3 ]

Final Thoughts

So, I think you all might agree with me on the fact that js is a little funny language and does not works the same we think it does.

If you think Js is not wierd enough, please let me know in the comments below and I will probably make another post about the more quirks that Js has.

Okay, so that's Umang Mittal signing off.