DEV Community: hithesh.kumar

Master JavaScript Promises: 10 Tricky Output Questions Every Developer Must Know! (Part 2)

hithesh.kumar — Tue, 08 Oct 2024 12:36:46 +0000

Welcome to Part 2 of our JavaScript promises series! In Part 1, we explored basic promise behaviors, including resolution, chaining, and rejection handling. Now, we’ll take things up a notch and delve into more advanced promise techniques like Promise.race(), Promise.all(), Promise.allSettled(), and Promise.any().

Let’s dive into five more tricky questions that will help you master these advanced promise concepts.

Question 6: `Promise.all()` – Handling Multiple Promises

const promiseA = Promise.resolve("A");
const promiseB = new Promise((resolve) => setTimeout(resolve, 100, "B"));
const promiseC = Promise.resolve("C");

Promise.all([promiseA, promiseB, promiseC]).then((results) => {
  console.log(results);
});

Output:

["A", "B", "C"]

Explanation:

Promise.all() waits for all promises to resolve before returning the results.
The resolved values are returned in the same order as the promises in the array, even if they resolve at different times. Here, promiseB takes longer but Promise.all waits for it to complete before logging ["A", "B", "C"].

Question 7: `Promise.all()` with Rejection

const promiseD = Promise.resolve("D");
const promiseE = new Promise((_, reject) => setTimeout(reject, 50, "Error"));
const promiseF = Promise.resolve("F");

Promise.all([promiseD, promiseE, promiseF])
  .then((results) => {
    console.log(results);
  })
  .catch((error) => {
    console.log("Caught:", error);
  });

Output:

Caught: Error

Explanation:

If any promise in Promise.all() rejects, the entire operation immediately rejects.
In this case, promiseE rejects after 50ms, so the .catch() handler catches the error and logs Caught: Error. The remaining promises are ignored once the rejection occurs.

Question 8: `Promise.race()` – Fastest Promise Wins

const promiseG = new Promise((resolve) => setTimeout(resolve, 100, "Resolved G"));
const promiseH = new Promise((_, reject) => setTimeout(reject, 50, "Rejected H"));
const promiseI = new Promise((resolve) => setTimeout(resolve, 150, "Resolved I"));

Promise.race([promiseG, promiseH, promiseI])
  .then((result) => {
    console.log("Won:", result);
  })
  .catch((error) => {
    console.log("Lost:", error);
  });

Output:

Lost: Rejected H

Explanation:

Promise.race() returns a promise that settles as soon as the first promise settles, whether it's resolved or rejected.
Since promiseH rejects the fastest (after 50ms), the .catch() handler logs Lost: Rejected H.

Question 9: `Promise.allSettled()` – Get All Results Regardless of Outcome

const promiseJ = Promise.resolve("J");
const promiseK = new Promise((_, reject) => setTimeout(reject, 50, "Error in K"));
const promiseL = new Promise((resolve) => setTimeout(resolve, 100, "L"));

Promise.allSettled([promiseJ, promiseK, promiseL]).then((results) => {
  console.log(results);
});

Output:

[
  { status: "fulfilled", value: "J" },
  { status: "rejected", reason: "Error in K" },
  { status: "fulfilled", value: "L" }
]

Explanation:

Promise.allSettled() returns an array of results after all promises settle (either fulfilled or rejected).
Each result is an object with a status field (fulfilled or rejected) and either a value (for fulfilled promises) or a reason (for rejected promises).
In this case, promiseK rejects while promiseJ and promiseL fulfill, but we still get the results for all promises.

Question 10: `Promise.any()` – The First Fulfilled Promise

const promiseM = new Promise((_, reject) => setTimeout(reject, 100, "Rejected M"));
const promiseN = new Promise((resolve) => setTimeout(resolve, 50, "Resolved N"));
const promiseO = new Promise((_, reject) => setTimeout(reject, 200, "Rejected O"));

Promise.any([promiseM, promiseN, promiseO])
  .then((result) => {
    console.log("First fulfilled:", result);
  })
  .catch((error) => {
    console.log("All rejected:", error.errors);
  });

Output:

First fulfilled: Resolved N

Explanation:

Promise.any() resolves as soon as any promise is fulfilled.
Here, promiseN is fulfilled after 50ms, so the .then() block logs First fulfilled: Resolved N.
If all promises were rejected, Promise.any() would throw an AggregateError, but that doesn’t happen in this case.

Conclusion:

In Part 2, we covered advanced promise techniques using Promise.all(), Promise.race(), Promise.allSettled(), and Promise.any(). These methods provide powerful ways to handle multiple asynchronous tasks simultaneously, each suited to different scenarios.

Here are the key takeaways:

Promise.all() waits for all promises to either resolve or reject, and if any reject, the entire operation fails.
Promise.race() returns the result of the fastest promise, whether it's resolved or rejected.
Promise.allSettled() is useful when you need to wait for all promises to finish regardless of success or failure.
Promise.any() resolves with the first successfully fulfilled promise, ignoring rejections unless all promises fail.

By mastering these promise methods, you'll be well-equipped to handle even the most complex asynchronous workflows in JavaScript.

Happy coding!

Master JavaScript Promises: 10 Tricky Output Questions Every Developer Must Know! (Part 1)

hithesh.kumar — Tue, 08 Oct 2024 07:58:44 +0000

JavaScript promises are an essential part of modern web development. They allow us to handle asynchronous operations cleanly and efficiently. However, promises can often behave in surprising ways, especially when combined with event loops and microtasks. This article is Part 1 of a two-part series where we tackle tricky promise-based output questions to sharpen your JavaScript skills.

By the end of this series, you'll have a deeper understanding of how promises interact with the JavaScript event loop. Let’s dive into the first five tricky questions!

Question 1: Basic Promise Resolution

console.log("Start");

const promise1 = new Promise((resolve) => {
  console.log("Promise started");
  resolve("Resolved");
});

promise1.then((result) => {
  console.log(result);
});

console.log("End");

Output:

Start
Promise started
End
Resolved

Explanation:

The first console.log("Start") is executed.
The promise executor runs immediately, logging Promise started.
The .then() block is scheduled as a microtask after the current code finishes executing.
console.log("End") runs next.
Finally, the .then() callback logs Resolved when the microtask queue is processed.

Question 2: Nested Promises

const promise2 = new Promise((resolve) => {
  resolve("Resolved 1");
});

promise2.then((result) => {
  console.log(result);
  return new Promise((resolve) => {
    resolve("Resolved 2");
  });
}).then((result) => {
  console.log(result);
});

Output:

Resolved 1
Resolved 2

Explanation:

The first .then() logs Resolved 1 and returns a new promise.
The second .then() waits for the returned promise to resolve, logging Resolved 2.

Question 3: Chained Promise with Immediate Resolution

const promise3 = Promise.resolve();

promise3
  .then(() => {
    console.log("Then 1");
  })
  .then(() => {
    console.log("Then 2");
  })
  .then(() => {
    console.log("Then 3");
  });

Output:

Then 1
Then 2
Then 3

Explanation:

When a promise is immediately resolved (Promise.resolve()), its .then() handlers are queued in the microtask queue.
Each .then() returns a new promise that resolves after its callback runs, resulting in a sequential execution of Then 1, Then 2, and Then 3.

Question 4: Rejection Handling

const promise4 = new Promise((_, reject) => {
  reject("Error occurred");
});

promise4
  .then(() => {
    console.log("This will not run");
  })
  .catch((error) => {
    console.log("Caught:", error);
  })
  .then(() => {
    console.log("This will still run");
  });

Output:

Caught: Error occurred
This will still run

Explanation:

The promise is rejected with the message "Error occurred".
The .catch() block catches the error and logs Caught: Error occurred.
After .catch(), the next .then() still runs because it’s treated as a resolved promise unless the catch throws again.

Question 5: Mixing Async/Await with Promises

async function asyncFunc() {
  console.log("Async function started");
  return "Async result";
}

asyncFunc().then((result) => {
  console.log(result);
});

console.log("Synchronous log");

Output:

Async function started
Synchronous log
Async result

Explanation:

When asyncFunc is called, it immediately logs Async function started.
The return value of an async function is a promise, so the .then() is scheduled as a microtask.
console.log("Synchronous log") runs next, followed by the resolution of the promise which logs Async result.

Conclusion:

In this first part, we covered the basics of JavaScript promises and explored how promise resolution, chaining, and rejection handling work. Understanding the event loop and microtask queue is crucial to mastering promises, and these questions highlight that. Stay tuned for Part 2, where we’ll dive into more advanced promise behaviors, including Promise.race, Promise.all, and more!

Key Takeaways:

Promise resolution is always asynchronous, and .then() handlers are processed after the current synchronous code.
Each .then() returns a new promise, allowing chaining.
catch() handles promise rejections, and subsequent .then() calls will still be executed.

Stay tuned for Part 2 of this series, where we tackle more advanced promise tricks!

Code Smells: Warning Signs in Your Codebase You Can't Ignore

hithesh.kumar — Mon, 07 Oct 2024 05:34:54 +0000

If you're a coder, you've likely encountered code that feels "off"—it's harder to maintain, understand, or scale. These common warning signs in your codebase, known as code smells, are indications that something isn't quite right. Just like a bad odor points to something rotten, a code smell hints at potential problems with the design or implementation of your code.

Before diving in, let’s clarify:

The term "smell" is a metaphor, comparing problematic code to a foul odor. What constitutes a code smell can be subjective, depending on:

The programming language you use
The development methodology your team follows
The personal preferences of the developers

Why Should You Care About Code Smells?

Ignoring code smells is like putting off car maintenance—it might not cause issues today, but over time, it can lead to major breakdowns. Here's why you should care:

Maintainability

Bloated or unclear code is a nightmare to maintain. It slows down debugging and increases the likelihood of introducing bugs.
Scalability

Smelly code makes scaling your application difficult. As your codebase grows, the underlying issues can cause exponential problems.
Technical Debt

Ignoring code smells is like accumulating debt—you'll eventually have to pay it back, often with interest, in the form of time-consuming rewrites or debugging.

Common Code Smells (and How to Fix Them)

Let’s explore some of the most common code smells and strategies to clean them up.

1. Bloated Code

🛑 Long Methods or Classes

When methods or classes grow too long, they become difficult to understand, test, and maintain.

Example:

function processOrder(order) {
    validateOrder(order);
    calculateDiscount(order);
    applyTaxes(order);
    updateInventory(order);
    sendConfirmation(order);
}

While this method seems fine, it performs too many tasks, making it hard to follow.

Solution: Break long methods into smaller, single-purpose functions.

function processOrder(order) {
    validateOrder(order);
    applyDiscountsAndTaxes(order);
    finalizeOrder(order);
}

function applyDiscountsAndTaxes(order) {
    calculateDiscount(order);
    applyTaxes(order);
}

🛑 Excessive Comments

Excessive comments can indicate that the code is not self-explanatory.

Example:

// Calculate the total price after applying the discount
let totalPrice = price - (price * discount);

Solution: Refactor code to be self-documenting.

let totalPrice = applyDiscount(price, discount);

2. Object-Oriented Abuses

🛑 Switch Statements

Switch statements that deal with type-specific behavior can often be replaced by polymorphism in object-oriented programming.

Example:

function getArea(shape) {
    switch(shape.type) {
        case 'circle':
            return Math.PI * shape.radius ** 2;
        case 'square':
            return shape.side * shape.side;
    }
}

Solution: Use polymorphism to handle shape-specific behavior.

class Shape {
    getArea() {
        throw "Must be implemented by subclass";
    }
}

class Circle extends Shape {
    constructor(radius) {
        super();
        this.radius = radius;
    }

    getArea() {
        return Math.PI * this.radius ** 2;
    }
}

class Square extends Shape {
    constructor(side) {
        super();
        this.side = side;
    }

    getArea() {
        return this.side * this.side;
    }
}

🛑 Temporary Fields

Fields that are only used in certain scenarios can clutter your class and lead to unnecessary complexity.

Solution: Move such fields to local variables or parameters when possible, or split responsibilities into multiple classes.

3. Rigidity

🛑 Divergent Change

When a single class has to be modified for unrelated reasons, it’s a sign that the class is trying to do too much.

Solution: Apply the Single Responsibility Principle by splitting the class into smaller, more focused units.

🛑 Shotgun Surgery

When a change requires modifying multiple classes, it signals poor modularity. This can make refactoring or adding features painful.

Solution: Identify the reason for scattered changes and refactor by grouping related logic together.

4. Unnecessary Complexity

🛑 Duplicate Code

Having the same piece of code in multiple places can lead to bugs and maintenance headaches.

Example:

function calculateTotalPrice(price, tax) {
    return price + (price * tax);
}

function calculateDiscountedPrice(price, discount, tax) {
    let discountedPrice = price - (price * discount);
    return discountedPrice + (discountedPrice * tax);
}

Solution: Extract common logic into reusable methods.

function calculatePrice(price, tax, discount = 0) {
    let discountedPrice = price - (price * discount);
    return discountedPrice + (discountedPrice * tax);
}

🛑 Dead Code

Dead code is functionality that is no longer used. It can clutter your codebase and confuse developers.

Solution: Regularly remove unused code to keep your codebase clean and concise.

5. Tight Coupling

🛑 Feature Envy

When a method relies heavily on another object's data instead of its own, it’s a sign of tight coupling.

Example:

function getDiscount(customer) {
    return customer.purchaseHistory.totalAmount > 1000 ? 0.1 : 0;
}

Solution: Consider moving the behavior to the object itself.

class Customer {
    getDiscount() {
        return this.purchaseHistory.totalAmount > 1000 ? 0.1 : 0;
    }
}

🛑 Inappropriate Intimacy

Classes that rely too heavily on each other’s internal details create unnecessary dependencies.

Solution: Enforce stricter encapsulation and reduce reliance on internal data.

Additional Code Smells to Watch Out For

Magic Numbers Replace unexplained numbers with named constants to improve readability and maintainability.

Example:

  const SALES_TAX = 0.07;
  let total = price + (price * SALES_TAX);

Deep Nesting

Simplify deeply nested loops or conditionals for better readability. Consider early returns or extracting methods.
Long Parameter Lists

Refactor methods that take many parameters by using parameter objects or reducing the method’s responsibility.

How to Deal with Code Smells

Code smells don’t mean your code is broken, but they are early indicators that your design may need improvement. Here's how you can deal with them:

Refactoring

The most effective way to deal with code smells is through refactoring—improving the internal structure of your code without changing its external behavior.
Incremental Changes

You don’t have to fix everything at once. Start with small, focused refactorings, targeting the smelliest areas of your code.
Testing

Before you refactor, ensure that your code has adequate tests in place. This helps you catch regressions and verify that the refactored code behaves as expected.

Final Thoughts

Recognizing and addressing code smells is crucial for maintaining healthy, scalable, and maintainable code. Think of it as preventative care—cleaning up these smells early will save you time, effort, and headaches down the line. Keep an eye out for these common warning signs, and make refactoring a regular part of your coding process!

"Master JavaScript Hoisting: 10 Tricky Output Questions Every Developer Must Know!" - Part 2

hithesh.kumar — Fri, 04 Oct 2024 13:28:00 +0000

Here are a few advanced hoisting-related questions that challenge your deeper understanding of JavaScript's execution context, closures, and async behavior:
link for part-1 of the series

11. Hoisting with Functions and `var` Declaration in the Same Name

Question:

var foo = 10;

function foo() {
    console.log('I am a function');
}

console.log(foo);

Output:

Explanation:

When both a variable and a function are declared with the same name, the function declaration is hoisted first, but the variable assignment takes precedence during execution. So, the variable foo holds the value 10 and not the function.

Concept:

Function vs Variable Hoisting: Function declarations are hoisted first, but var variable assignments override them if declared later in the same scope.

12. Hoisting with Functions inside `if` Statements

Question:

if (true) {
    function test() {
        console.log('Inside function');
    }
}

test();

Output:

Inside function

Explanation:

In most JavaScript engines, function declarations inside blocks (if, for, etc.) are hoisted to the top of their enclosing scope, making them available outside of the block. So, even though test() is declared inside an if block, it is hoisted and accessible outside the block.

Concept:

Function Hoisting inside Blocks: Functions inside blocks can still be hoisted to the top of their scope, though this behavior can differ between strict and non-strict mode.

13. Hoisting and Class Declarations

Question:

const obj = new MyClass();

class MyClass {
    constructor() {
        this.name = 'JavaScript';
    }
}

Output:

ReferenceError: Cannot access 'MyClass' before initialization

Explanation:

Unlike functions, class declarations are not hoisted. They behave more like variables declared with let or const, where they are in a temporal dead zone until fully initialized. Accessing a class before its declaration will throw a ReferenceError.

Concept:

Class Hoisting: Class declarations are hoisted but are not initialized before their actual definition, meaning they cannot be accessed before they are declared.

14. Hoisting and Named Function Expressions

Question:

var foo = function bar() {
    console.log(typeof bar);
};

foo();
console.log(typeof bar);

Output:

function
undefined

Explanation:

This example uses a named function expression. Inside the function expression, the name bar is available and refers to the function itself, but bar is not hoisted or available in the outer scope. So, typeof bar inside the function returns "function", while outside it returns undefined.

Concept:

Named Function Expression: Function names in expressions are not hoisted and are only accessible inside the function itself.

15. Hoisting with Async/Await and `var`

Question:

async function asyncTest() {
    console.log(a);
    var a = 10;
    await new Promise(resolve => setTimeout(resolve, 1000));
    console.log(a);
}

asyncTest();

Output:

undefined
10

Explanation:

This question combines hoisting with asynchronous code. The variable a is hoisted inside asyncTest() and is initialized as undefined at the start. After the await is resolved, the second console.log(a) prints 10, which was assigned before the asynchronous code was executed.

Concept:

Async/Await and Hoisting: Hoisting happens normally within async functions, and await simply pauses the execution without affecting the hoisting behavior.

16. Hoisting with `var` and Immediately Invoked Function Expressions (IIFE)

Question:

var a = 1;

(function() {
    console.log(a);
    var a = 2;
    console.log(a);
})();

console.log(a);

Output:

undefined
2
1

Explanation:

Inside the IIFE, var a = 2 hoists the variable declaration but not its assignment. So the first console.log(a) inside the function prints undefined.
The second console.log(a) prints 2 after the assignment.
Outside the IIFE, the global a remains unchanged and prints 1.

Concept:

Hoisting within IIFE: Each function (including IIFEs) has its own scope for hoisting. The outer a is unaffected by the hoisting inside the IIFE.

17. Hoisting and Function Expression inside a Block

Question:

{
    var a = function() {
        return 'I am a function';
    };
}

console.log(a());

Output:

I am a function

Explanation:

In this example, var a is hoisted to the top of the surrounding scope, which is the global scope. The function expression is then assigned to a. So when console.log(a()) is called, it correctly executes the function and returns "I am a function".

Concept:

Function Expression Hoisting: The var declaration of the function is hoisted, making the function available in the surrounding scope, even if declared inside a block.

These advanced questions provide a deeper dive into hoisting, covering more complex scenarios like class declarations, async functions, and function expressions. Understanding these intricacies is crucial for mastering JavaScript and avoiding potential issues in your code.

"Master JavaScript Hoisting: 10 Tricky Output Questions Every Developer Must Know!" Part 1

hithesh.kumar — Fri, 04 Oct 2024 13:22:57 +0000

JavaScript hoisting is one of the most important yet often misunderstood concepts for developers, especially when working with variable declarations and function scopes. Hoisting essentially allows you to use functions and variables in your code even before they are formally declared. While this might seem like magic, understanding how JavaScript interprets and rearranges code can help you avoid common pitfalls and write more predictable, efficient programs.

In this article, we’ll dive into hoisting through a series of output-based questions, ranging from beginner to advanced levels. Each question is followed by an explanation of the concept behind it, helping you solidify your understanding of how JavaScript hoists variables and functions during execution.

Let’s explore some key hoisting-related output questions and break down the behavior you need to be aware of when writing JavaScript.

1. Variable Hoisting with `var`

Question:

console.log(x);
var x = 10;
console.log(x);

Output:

undefined
10

Explanation:

In JavaScript, var declarations are hoisted to the top of their scope but are initialized with undefined. When console.log(x) is called before the initialization, x is hoisted but not yet assigned the value 10, so it outputs undefined. After the initialization, x holds the value 10.

Concept:

Hoisting: Variable declarations are moved to the top of the scope, but the initialization happens in place.

2. Hoisting with Function Declaration

Question:

console.log(foo());

function foo() {
    return "Hello!";
}

Output:

Hello!

Explanation:

Function declarations are hoisted in their entirety, including the function body. So, even though foo() is called before the function definition, it works as expected because the function is fully hoisted to the top.

Concept:

Function Hoisting: Entire function declarations (including the body) are hoisted to the top of the scope.

3. Hoisting with `let` and `const`

Question:

console.log(a);
let a = 5;

Output:

ReferenceError: Cannot access 'a' before initialization

Explanation:

Variables declared with let and const are hoisted but enter a "temporal dead zone" (TDZ) from the start of the block until they are initialized. This means that even though the declaration is hoisted, accessing a before its initialization will throw a ReferenceError.

Concept:

Temporal Dead Zone (TDZ): Variables declared with let and const are hoisted but cannot be accessed before initialization.

4. Hoisting with `var` inside a Function

Question:

function test() {
    console.log(a);
    var a = 10;
    console.log(a);
}

test();

Output:

undefined
10

Explanation:

Within the function test(), the var declaration of a is hoisted to the top of the function. So, the first console.log(a) outputs undefined because the variable is hoisted but not yet initialized. After initialization, the second console.log(a) prints 10.

Concept:

Function Scope Hoisting: Inside a function, variables declared with var are hoisted to the top of the function, initialized as undefined.

5. Hoisting with Multiple `var` Declarations

Question:

console.log(a);
var a = 10;
var a = 20;
console.log(a);

Output:

undefined
20

Explanation:

JavaScript allows multiple var declarations in the same scope, but only the first declaration is hoisted. The initial console.log(a) logs undefined due to hoisting, and the last console.log(a) logs 20 because the second assignment overwrites the first one.

Concept:

Multiple Declarations with var: Multiple var declarations in the same scope are allowed but only the final assignment takes effect.

6. Hoisting with Function Expressions

Question:

console.log(foo);

var foo = function() {
    return "Hello!";
};

console.log(foo());

Output:

undefined
Hello!

Explanation:

In this case, foo is declared using a function expression. The variable foo is hoisted to the top and initialized with undefined. Therefore, the first console.log(foo) outputs undefined. Once the function is assigned to foo, the second console.log(foo()) successfully calls the function, outputting "Hello!".

Concept:

Function Expressions and Hoisting: Only the variable declaration is hoisted, not the function body. The function is assigned later in the code execution.

7. Hoisting with `const` Declaration

Question:

console.log(b);
const b = 30;

Output:

ReferenceError: Cannot access 'b' before initialization

Explanation:

Like let, variables declared with const are hoisted but are in the temporal dead zone (TDZ) until initialized. Accessing b before it is initialized results in a ReferenceError.

Concept:

Hoisting and const: Variables declared with const are hoisted but are not accessible before initialization due to TDZ.

8. Hoisting with Function Declarations and Variable Declarations

Question:

function hoist() {
    console.log(a);
    var a = 10;
    console.log(a);
}

var a = 20;
hoist();
console.log(a);

Output:

undefined
10
20

Explanation:

Inside hoist(), a is hoisted as a local variable, so console.log(a) prints undefined first. After assignment, a becomes 10. Outside the function, the global a is unaffected and retains its value of 20.
Hoisting ensures that the local a in hoist() is treated separately from the global a.

Concept:

Local vs Global Scope: Variable hoisting applies within function scope and does not affect the global scope.

9. Hoisting with Arrow Functions

Question:

console.log(foo);

var foo = () => {
    return "Arrow Function!";
};

console.log(foo());

Output:

undefined
Arrow Function!

Explanation:

Similar to function expressions, when using arrow functions, the variable foo is hoisted but remains undefined until it is initialized. So, the first console.log(foo) prints undefined, and the second console.log(foo()) works after foo is assigned the arrow function.

Concept:

Arrow Function Hoisting: Arrow functions behave like function expressions, where only the variable is hoisted, not the function body.

10. Hoisting with `let` and `var` in Loops

Question:

for (var i = 0; i < 3; i++) {
    setTimeout(() => console.log(i), 1000);
}

for (let j = 0; j < 3; j++) {
    setTimeout(() => console.log(j), 1000);
}

Output:

Explanation:

For var i, the variable i is hoisted and shared across all iterations. By the time the setTimeout callback runs, the loop is done and i has the value 3.
For let j, let is block-scoped, so each iteration of the loop gets a new copy of j. Therefore, when the setTimeout callback runs, it prints the correct values (0, 1, 2).

Concept:

Loop Scoping with var vs let: Variables declared with var are hoisted and shared across loop iterations, while let creates a new binding for each iteration.

These output-based questions on hoisting will help you understand how JavaScript manages variable and function declarations in its execution context. Hoisting plays a crucial role in understanding the behavior of code, especially when dealing with var, let, const, and functions.

Optimize cyclomatic complicity in your javascript code.

hithesh.kumar — Thu, 29 Dec 2022 13:38:56 +0000

Cyclomatic complexity is a measure of the complexity of a program, and it is calculated based on the number of independent paths through the code. High cyclomatic complexity can make code difficult to understand and maintain, and it can also be an indication of potential bugs.

To optimize cyclomatic complexity in JavaScript, you can follow these steps:

Identify areas of your code with high cyclomatic complexity. You can use a tool like SonarQube or a code analysis plugin for your editor to identify areas of your code with high cyclomatic complexity.

Refactor your code to reduce the number of independent paths. Here are a few ways you can do this:

Extract complex logic into separate functions or modules to make the code more modular and easier to understand.
Use early return statements to exit functions early when certain conditions are met.
Use conditional statements with fewer branches, such as using a switch statement instead of multiple if-else statements.

Here's an example of how these techniques might be applied to reduce cyclomatic complexity in a function:

Before:

function calculateTotal(items) {
  let total = 0;
  for (const item of items) {
    if (item.price > 10) {
      total += item.price * 0.9;
    } else if (item.price > 5) {
      total += item.price * 0.95;
    } else {
      total += item.price;
    }
  }
  return total;
}

After:

function calculateTotal(items) {
  let total = 0;
  for (const item of items) {
    total += getDiscountedPrice(item);
  }
  return total;
}

function getDiscountedPrice(item) {
  if (item.price > 10) {
    return item.price * 0.9;
  } else if (item.price > 5) {
    return item.price * 0.95;
  } else {
    return item.price;
  }
}

6 Best practices for react state management in 2023.

hithesh.kumar — Thu, 29 Dec 2022 13:20:34 +0000

There are several best practices to follow when managing state in a React application:

1.Keep the state as minimal as possible: It's important to only store data in the state that is necessary for the component to render. This can help to keep your application's state tree small and easy to manage.



import { useState } from 'react';

function MyComponent() {
  // Only store the data that is necessary for the component to render
  const [state, setState] = useState({
    userName: '',
    userId: ''
  });

  return (
    <div>
      {/* Render the state data */}
      <p>Username: {state.userName}</p>
      <p>User ID: {state.userId}</p>
    </div>
  )
}

2.Avoid direct manipulation of the state: It's a good practice to avoid directly manipulating the state object. Instead, use React's setState() method to update the state. This ensures that the component will re-render when the state changes, allowing the user interface to stay up-to-date.



import { useState } from 'react';

function MyComponent() {
  const [state, setState] = useState({
    userName: '',
    userId: ''
  });

  const handleNameChange = (event) => {
    // Use setState() to update the state, rather than directly manipulating the state object
    setState({
      ...state,
      userName: event.target.value
    });
  }

  return (
    <div>
      {/* Render the state data */}
      <p>Username: {state.userName}</p>
      <p>User ID: {state.userId}</p>

      {/* Use an event handler to update the state */}
      <input type="text" onChange={handleNameChange} />
    </div>
  )
}

3.Use a state management library: If your application becomes complex and has a lot of state to manage, it can be helpful to use a state management library like Redux or MobX. These libraries provide a predictable and centralized way to manage state in your application.



import { useReducer } from 'react';
import { createStore } from 'redux';

// Define the reducer function to handle state updates
function reducer(state, action) {
  switch (action.type) {
    case 'SET_USERNAME':
      return {
        ...state,
        userName: action.userName
      };
    case 'SET_USER_ID':
      return {
        ...state,
        userId: action.userId
      };
    default:
      return state;
  }
}

// Create the store with the reducer function
const store = createStore(reducer);

function MyComponent() {
  // Use the store's state as the component's state
  const [state, dispatch] = useReducer(reducer, store.getState());

  const handleNameChange = (event) => {
    // Dispatch an action to update the store's state
    dispatch({
      type: 'SET_USERNAME',
      userName: event.target.value
    });
  }

  return (
    <div>
      {/* Render the state data */}
      <p>Username: {state.userName}</p>
      <p>User ID: {state.userId}</p>

      {/* Use an event handler to update the state */}
      <input type="text" onChange={handleNameChange} />
    </div>
  )
}

4.Use functional setState(): When updating the state based on the previous state, it's a good idea to use the functional form of setState(), which allows you to pass a function to setState() instead of an object. This function receives the previous state as an argument and returns the new state.



import { useState } from 'react';

function MyComponent() {
  const [state, setState] = useState({
    userName: '',
    userId: ''
  });

  const handleNameChange = (event) => {
    // Use the functional form of setState() to update the state based on the previous state
    setState((prevState) => ({
      ...prevState,
      userName: event.target.value
    }));
  }

  return (
    <div>
      {/* Render the state data */}
      <p>Username: {state.userName}</p>
      <p>User ID: {state.userId}</p>

      {/* Use an event handler to update the state */}
      <input type="text" onChange={handleNameChange} />
    </div>
  )
}

5.Use the context API: If you have state that needs to be shared across multiple components, consider using the React context API. This allows you to create a "context" that can be shared by any component in the tree, without having to pass props down manually through multiple levels of the component hierarchy.



import { useState } from 'react';

// Create the context with a default value
const UserContext = React.createContext({
  userName: '',
  userId: ''
});

function MyComponent() {
  // Use the context to get the state
  const { userName, userId } = useContext(UserContext);

  return (
    <div>
      {/* Render the state data */}
      <p>Username: {userName}</p>
      <p>User ID: {userId}</p>
    </div>
  )
}

function App() {
  // Use the useState hook to manage the state within the context provider
  const [state, setState] = useState({
    userName: '',
    userId: ''
  });

  const handleNameChange = (event) => {
    setState((prevState) => ({
      ...prevState,
      userName: event.target.value
    }));
  }

  return (
    // Wrap the component tree in the context provider to make the state available to all components
    <UserContext.Provider value={state}>
      <MyComponent />
      <input type="text" onChange={handleNameChange} />
    </UserContext.Provider>
  )
}

6.Use the useReducer hook: If you have complex state logic that involves multiple sub-values or the need to perform calculations based on the previous state, you may want to consider using the useReducer hook. This hook allows you to define a reducer function that handles state updates in a predictable way, similar to how Redux works.



import { useReducer } from 'react';

// Define the reducer function to handle state updates
function reducer(state, action) {
  switch (action.type) {
    case 'SET_USERNAME':
      return {
        ...state,
        userName: action.userName
      };
    case 'SET_USER_ID':
      return {
        ...state,
        userId: action.userId
      };
    default:
      return state;
  }
}

function MyComponent() {
  // Initialize the state with the reducer function
  const [state, dispatch] = useReducer(reducer, {
    userName: '',
    userId: ''
  });

  const handleNameChange = (event) => {
    // Dispatch an action to update the state
    dispatch({
      type: 'SET_USERNAME',
      userName: event.target.value
    });
  }

  return (
    <div>
      {/* Render the state data */}
      <p>Username: {state.userName}</p>
      <p>User ID: {state.userId}</p>

      {/* Use an event handler to update the state */}
      <input type="text" onChange={handleNameChange} />
    </div>
  )
}

"Is Your React/Node App Safe? How to Detect Vulnerabilities Using OWASP Dependency-Check!"

hithesh.kumar — Thu, 07 Jan 2021 15:59:36 +0000

In today’s fast-paced development world, security often takes a back seat to feature building. However, ensuring your React/Node.js application is secure should be a top priority! Security vulnerabilities in third-party dependencies can expose your app to serious threats. That’s where the OWASP Dependency-Check comes into play.

🚨 What is OWASP Dependency-Check?
OWASP Dependency-Check is a powerful tool designed to identify publicly disclosed vulnerabilities in your project’s dependencies. It scans your package.json and package-lock.json (or yarn.lock) files in Node.js projects, cross-referencing them against known vulnerability databases like the National Vulnerability Database (NVD).

Why Should You Care About Vulnerabilities?
Third-party dependencies can introduce potential attack vectors if they have outdated or vulnerable versions.
Automated tools like OWASP Dependency-Check allow you to identify issues before they become critical exploits.

When developing software, we have to use 3rd party npm packages in many cases. For example, If we want to make an HTTP call to an API, from our application we would use the Axios library. However, before using a 3rd party library, it is important to check if there are any known security vulnerabilities reported against these libraries. In such a case, you can use a tool to do the search for you. OWASP Dependency-Check is one among them.

Here I will demonstrate how to use the command line tool of OWASP Dependency-Check to analyze external dependencies and generate a report based on the known vulnerabilities detected.

1) First, download the command-line tool from the official website OWASP Dependency-Check

2) After downloading and extract. Goto dependency-check folder, In the bin directory you can find the executable script. dependency-check.bat file is for running the tool on Windows and the dependency-check.sh file is for running on Linux.

3) Open in terminal and run the following script.

./dependency-check.sh --project "<project_name>" --scan <folder containing 3rd party libraries> --out <folder to generate reports> --suppression <xml file containing suppressions>

--project: Specify a name for the project and this would appear in the report. (optional)

--scan: Path of the folder which contains the 3rd party dependency libraries. (required)

--out: Path of the folder where the vulnerability analysis reports should be generated. (optional)

--suppression: An XML file that contains the known vulnerabilities that should be hidden from the report (false positives). (optional)

checkout lists the command line arguments

OWASP dependency-check includes an analyzer that will scan Node Package Manager package specification files that works in conjunction with the Node Audit Analyzer to create a bill-of-materials for a Node.js project.

Files Types Scanned: package.json, package-lock.json, npm-shrinkwrap.json

./dependency-check.sh --project demo_app --scan ~/react_learning/demo_app/package-lock.json  --out ~/react_learning/demo_app/

When you run the OWASP Dependency-Check for the very first time, it would download the known vulnerabilities from the National Vulnerability Database (NVD) and it would maintain this information in a local database. So, it will take some time to run this for the very first time, because all the vulnerability information have to be downloaded.

By default the duration for syncing the local database and NVD is 4 hours. If you have run the Dependency Check within 4 hours, it will just use the data in local database without trying to update the local database with NVD.

Here I have react-app in this directory /home/user/react_learning/demo_app and generated report in the same directory.

Conclusion: Don’t Let Vulnerabilities Linger!
Your React/Node.js app’s security is only as strong as its weakest link—often a third-party dependency. Regularly scanning your app with OWASP Dependency-Check can protect you from well-known vulnerabilities lurking in your project. Stay one step ahead of attackers and secure your app before it’s too late!

Make sure to give your app the protection it needs with automated vulnerability scanning—because in the world of web development, prevention is always better than cure!

DEV Community: hithesh.kumar

Master JavaScript Promises: 10 Tricky Output Questions Every Developer Must Know! (Part 2)

Question 6: Promise.all() – Handling Multiple Promises

Output:

Explanation:

Question 7: Promise.all() with Rejection

Output:

Explanation:

Question 8: Promise.race() – Fastest Promise Wins

Output:

Explanation:

Question 9: Promise.allSettled() – Get All Results Regardless of Outcome

Output:

Explanation:

Question 10: Promise.any() – The First Fulfilled Promise

Output:

Explanation:

Conclusion:

Master JavaScript Promises: 10 Tricky Output Questions Every Developer Must Know! (Part 1)

Question 1: Basic Promise Resolution

Output:

Explanation:

Question 2: Nested Promises

Output:

Explanation:

Question 3: Chained Promise with Immediate Resolution

Output:

Explanation:

Question 4: Rejection Handling

Output:

Explanation:

Question 5: Mixing Async/Await with Promises

Output:

Explanation:

Conclusion:

Code Smells: Warning Signs in Your Codebase You Can't Ignore

Why Should You Care About Code Smells?

Common Code Smells (and How to Fix Them)

1. Bloated Code

🛑 Long Methods or Classes

Example:

🛑 Excessive Comments

Example:

2. Object-Oriented Abuses

🛑 Switch Statements

Example:

🛑 Temporary Fields

3. Rigidity

🛑 Divergent Change

🛑 Shotgun Surgery

4. Unnecessary Complexity

🛑 Duplicate Code

Example:

🛑 Dead Code

5. Tight Coupling

🛑 Feature Envy

Example:

🛑 Inappropriate Intimacy

Additional Code Smells to Watch Out For

How to Deal with Code Smells

Final Thoughts

"Master JavaScript Hoisting: 10 Tricky Output Questions Every Developer Must Know!" - Part 2

11. Hoisting with Functions and var Declaration in the Same Name

Question:

Output:

Explanation:

Concept:

12. Hoisting with Functions inside if Statements

Question:

Output:

Explanation:

Concept:

13. Hoisting and Class Declarations

Question:

Output:

Explanation:

Concept:

14. Hoisting and Named Function Expressions

Question:

Output:

Question 6: `Promise.all()` – Handling Multiple Promises

Question 7: `Promise.all()` with Rejection

Question 8: `Promise.race()` – Fastest Promise Wins

Question 9: `Promise.allSettled()` – Get All Results Regardless of Outcome

Question 10: `Promise.any()` – The First Fulfilled Promise

11. Hoisting with Functions and `var` Declaration in the Same Name

12. Hoisting with Functions inside `if` Statements

15. Hoisting with Async/Await and `var`

16. Hoisting with `var` and Immediately Invoked Function Expressions (IIFE)

1. Variable Hoisting with `var`

3. Hoisting with `let` and `const`

4. Hoisting with `var` inside a Function

5. Hoisting with Multiple `var` Declarations

7. Hoisting with `const` Declaration

10. Hoisting with `let` and `var` in Loops