DEV Community: RakibRahman

Understanding the Single Responsibility Principle in S.O.L.I.D

RakibRahman — Sat, 29 Mar 2025 17:23:54 +0000

Intro
What is the S.O.L.I.D Principle?
What is SRP?
Real-World Analogy of SRP
Code Example
- Violation of SRP
- Adhering to SRP
What breaks SRP
- 1. Not adhering to DRY principle
- 2. Missing KISS principle
- 3. Tight Coupling
How to achieve SRP
- 1. Adhere to the DRY Principle
- 2. Follow the KISS Principle
- 3. Avoid Tight Coupling
Benefits of SRP
References
Conclusion

Intro

Writing flexible and scalable code is hard, but the S.O.L.I.D principles help us achieve that. At first glance, S.O.L.I.D may seem daunting, and applying it correctly takes time and practice. However, with proper theoretical knowledge and hands-on experience, mastering these principles becomes achievable.

I’m writing this blog to:

Document my learning journey – so I (and others) can revisit and refresh our understanding.
Improve over time – As I gain more insights, I’ll update and refine my explanations.

This will be a 5-part series, where each blog dives deep into one principle. Let’s begin with the first one: Single Responsibility Principle (SRP)

What is the S.O.L.I.D Principle?

SOLID is an acronym for the first five object-oriented design (OOD) principles, introduced by Robert C. Martin (Uncle Bob) in the early 2000s. These principles help developers create software that is:

Maintainable -> Easy to modify and extend.
Understandable –> Clear and readable structure.
Flexible –> Adapts to changes without breaking.
Scalable –> Reduces complexity as the application grows.

The five principles are:

Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

What is SRP?

The Single Responsibility Principle (SRP) states that:

A class or module should have only one reason to change, meaning it should have only one job or responsibility.

In simpler terms:

One class = One primary job or responsibility.
If a class does too much, it becomes harder to maintain.
Changes in one functionality shouldn’t risk breaking unrelated features.

Violating SRP often leads to tight coupling, which makes code hard to test and maintain.

Real-World Analogy of SRP

Let’s try to understand SRP with a real-world scenario. Think of a supershop where:

The cashier only deals with cash (doesn’t help customers find products).
The salesman only helps customers locate desired products (doesn’t manage cash).
The cleaner only cleans (doesn’t assist with product searches or cash handling).

The supershop works efficiently because each expert focuses on their responsiblity. Changes to one role do not disrupt others.

Code Should Work the Same Way!
Just as you wouldn't expect a cleaner to handle billing, a class or module shouldn't mix unrelated responsibilities.

Code Example

Enough theoretical knowledge. Let's see SRP in action. I'll use Go(Golang) to demonstrate the SRP, but the following example should also apply to other languages.

Violation of SRP

Let’s look at a common scenario where SRP is violated. In this example, the User struct handles both saving data to the database and sending emails.

type User struct {
    name  string
    email string
}

// Violation of SRP. It handles both database operations and email sending.
func (u *User) Save() error {
    // Logic to save user to the database
    fmt.Printf("Saving user %s to database\n", u.name)

    // Logic to send email
    u.SendEmail(u.email, "Welcome to our community")
    return nil
}

func (u *User) SendEmail(email, message string) {
    // Email sending logic
    fmt.Println(message, email)
}

func main() {
    user := User{name: "Rakib", email: "rakib@gmail.com"}
    user.Save()
}

The Save method handles both database and email operations, which violates SRP.
Additionally, we can’t reuse database/email-related logic because it’s tightly coupled to the Save method.

Adhering to SRP

Now, let’s refactor the code to adhere to SRP. We’ll separate the responsibilities into dedicated methods.

type User struct {
    name  string
    email string
}

// DatabaseService handles database operations - single responsibility
type DatabaseService struct{}

func (db *DatabaseService) SaveUser(user *User) {
    // Logic to save user to the database
    fmt.Println("Saving user to database", user.name)
}

// EmailService handles email-related operations - single responsibility
type EmailService struct{}

func (es *EmailService) SendEmail(user *User, message string) {
    // Logic to send an email
    fmt.Println(message, user.email)
}

func main() {
    user := User{name: "Rakib", email: "rakib@gmail.com"}

    dbService := &DatabaseService{}
    emailService := &EmailService{}

    dbService.SaveUser(&user)
    emailService.SendEmail(&user, "Welcome to our community")
}

Now, we’ve assigned each responsibility to a separate module:
- DatabaseService handles database operations.
- EmailService handles email-related operations.
The SaveUser and SendEmail methods are not tightly coupled, can be reused, and changing one’s logic does not disrupt the other.

What breaks SRP

Here are some common scenarios where SRP is broken:

1. Not adhering to DRY principle.

Duplicate functionality in your code violates SRP. If you copy-paste the same logic into multiple places, it often indicates scattered responsibilities and a lack of a single source of truth.

   // Duplicate validation logic in two places  
func CreateUser(name string, email string) error {
    if len(name) == 0 {
        return errors.New("name cannot be empty")
    }
    // ... rest of the function  
}

func UpdateUser(name string, email string) error {
    if len(name) == 0 {
        return errors.New("name cannot be empty")
    }
    // ... rest of the function  
}

In the above example, the CreateUser and UpdateUser methods use the same logic for validating the name. If we need to update the logic, we have to do it manually in each method.

2. Missing KISS principle.

When a class tries to do too much, it becomes overly complex and difficult to understand. The level of abstraction is missing.

  type Report struct {}

func (r *Report) Generate() string { /* ... */ }
func (r *Report) SaveToFile() error { /* ... */ }
func (r *Report) SendEmail() error { /* ... */ }

Here, the Report struct handles generating reports, saving them to files, and sending emails—all in one place.

3. Tight Coupling

When a class is tightly coupled with other classes or modules, it becomes harder to modify one without affecting others. This coupling often arises when a class takes on responsibilities that don't belong to it.

type Order struct {
    DB *sql.DB
}

func (o *Order) Process() error {
    // Business logic + direct database access  
    _, err := o.DB.Exec("INSERT INTO orders...")
    return err
}

The Order struct is directly responsible for both business logic and database operations, making it tightly coupled with the database.

How to achieve SRP

To adhere to the Single Responsibility Principle, address the issues outlined above with these strategies:

1. Adhere to the DRY Principle

Centralize shared functionality into a single module or function. For example, extract the validation logic into a dedicated function to avoid duplication.

func ValidateName(name string) error {
    if len(name) == 0 {
        return errors.New("name cannot be empty")
    }
    return nil
}

func CreateUser(name string, email string) error {
    if err := ValidateName(name); err != nil {
        return err
    }
    // ... rest of the function  
}

func UpdateUser(name string, email string) error {
    if err := ValidateName(name); err != nil {
        return err
    }
    // ... rest of the function  
}

2. Follow the KISS Principle

Keep classes simple and focused. Each class should have one clear responsibility. Split the Report struct into smaller, focused structs.

type ReportGenerator struct{}

func (r *ReportGenerator) Generate() string {
    // Logic for generating report
    return "Generated Report"
}

type FileSaver struct{}

func (f *FileSaver) SaveToFile(content string) error {
    // Logic for saving to file
    return nil
}

type EmailSender struct{}

func (e *EmailSender) SendEmail(content string) error {
    // Logic for sending email
    return nil
}

Each struct now has a single responsibility: generating reports, saving files, or sending emails.

3. Avoid Tight Coupling

Use composition to delegate responsibilities to other classes. For instance, separate the business logic from database operations by injecting a repository or service.

  type OrderRepository struct {
    DB *sql.DB
}

func (r *OrderRepository) Save(orderData map[string]interface{}) error {
    // Database-specific logic
    _, err := r.DB.Exec("INSERT INTO orders...", orderData)
    return err
}

type Order struct {
    Repository *OrderRepository
}

func (o *Order) Process(orderData map[string]interface{}) error {
    // Business logic only
    return o.Repository.Save(orderData)
}

Here, the Order struct delegates database operations to the OrderRepository, reducing coupling and adhering to SRP.

Benefits of SRP

Reusability -> The DatabaseService and EmailService can be reused across different parts of the application, reducing duplication.
Easier debugging -> Responsibilities are isolated, so it’s easier to pinpoint issues.
Simpler testing -> Each class or module has a clear purpose and can be tested independently. It allows for unit testing without mocking unrelated logic.
Better organization -> The code is modular, providing greater readability.
Maintainability -> Changing one module does not cause unintended side effects in other modules. For example, if the email-sending logic changes (e.g., switching from SMTP to an external service), only the EmailService needs modification, leaving the DatabaseService unaffected.
Abstraction -> SRP often leads to better abstraction, which is a key concept in good software design.

References

Conclusion

Simply put, implementing SRP greatly improves code quality. It makes the code easier to maintain, test, and scale. Always try to implement SRP in your projects to improve code quality. Stay tuned for the next blog in the series, which will cover the Open/Closed Principle (OCP).

That’s all for today! Thank you for reading, and don’t forget to connect with me on LinkedIn to get updates.

If you have any questions or feedback, please leave a comment below!

web worker

RakibRahman — Wed, 19 Feb 2025 01:34:38 +0000

Simplifying React with EventEmitter: Reduce Prop Drilling & Unnecessary Re-renders

RakibRahman — Fri, 14 Feb 2025 18:13:17 +0000

Intro

In React applications, state management tools like Redux, Zustand, or React Context help manage shared data across components. However, when it comes to event-driven communication, EventEmitter can be a lightweight and efficient alternative. It enables components to interact without deep prop drilling or unnecessary re-renders. In this blog, we'll explore how EventEmitter works, how to implement it in React, and when it’s the right tool for the job.

What's an Event Emitter?

In browsers, we handle user interactions using events. An event can be triggered by a user's action, such as a mouse click or a keyboard key press. For example, when we copy and paste text or media files into our app, it’s handled by the ClipboardEvent to achieve the desired outcome. Different frameworks and libraries provide various implementations of this concept. In Node.js, the EventEmitter class offers a simple and flexible way to handle events. Simply put, it emits (or triggers) an event that anyone can listen to and perform tasks based on the emitted data.

Basic Example of EventEmitter in JavaScript

Here’s a basic implementation of EventEmitter in JavaScript using Node.js' built-in EventEmitter class.

The emit method is used to trigger an event. In this example, it triggers the login event and passes the phone number ('01829546') as data.
The on method is used to listen for an event and execute a callback function when the event is triggered. Here, it invokes the sendOTP function with the provided phone number.

Implementing EventEmitter in React

React doesn’t have a built-in EventEmitter, so we’ll use the eventemitter3 package from npm. This approach allows us to manage app-wide events without tightly coupling components.

Step 1: Setting Up EventEmitter

Let’s create a file (eventEmitter.ts) to define and export a single instance of EventEmitter. This ensures that the same instance is shared across the entire application.

Step 2: Emitting an Event from Any Component

The LoginButton component emits an event named login with a phone number as data.

Step 3: Subscribing to the Event from Any Component

The OTPHandler component listens for the login event and performs an action.
Components can listen for events even if they are not directly related to the emitter component. This eliminates the need for deep prop drilling, as the data is available app-wide.

Code Example Repo

Benefits of Using EventEmitter

Decoupling Logic: The LoginButton and OTPHandler components are completely independent. They communicate via the shared AppEmitter instance.
Preventing Deep Prop Passing: You don’t need to pass props through deeply nested components, as the event data is globally accessible.
Avoiding Re-renders: Since events are handled outside of React's state management, unrelated components won’t re-render unnecessarily.
App-Wide Notifications: EventEmitter is useful for broadcasting notifications, logging, or analytics across the app.

Drawbacks of EventEmitter

Hard to Debug: Events are decoupled, making it difficult to trace where an event was emitted or which listeners handle it, especially as the application grows.
Memory Leaks: If listeners are not cleaned up (e.g., using .off()), they can persist after components are unmounted, leading to memory leaks and unexpected behaviour.
No Built-in Error Handling: Errors in listeners can crash the application since EventEmitter does not provide robust error-handling mechanisms.
Not for Complex State Management: EventEmitter is unsuitable for managing complex state or workflows. It’s designed for simple event-driven communication, not for maintaining synchronized application state

EventEmitter, React Context, Redux/Zustand: Which Tool Fits Your Use Case?

EventEmitter: Best for event-driven workflows (e.g., logging, analytics). Avoids re-renders but requires manual cleanup and lacks built-in error handling.
React Context: Ideal for shared UI state (e.g., themes, auth). Easy to use but triggers frequent re-renders, making it less efficient for high-frequency updates.
Redux/Zustand: Perfect for complex global state (e.g., complex business logic) in large apps. Offers scalability and middleware support.

Feature	EventEmitter	React Context	Redux/Zustand
Decoupling	High	Low	Medium
Re-render Optimization	Yes (operates outside React lifecycle)	No (triggers re-renders for listeners)	Depends on setup
Use Case	Event-driven workflows (e.g., logging, analytics, WebSocket events)	Shared UI state (e.g., themes, user auth)	Complex app state (e.g., large-scale apps)
Memory Management	Requires manual cleanup (`.off()`)	Automatically managed by React	Automatically managed by library
Error Handling	Manual (no built-in mechanisms)	Manual	Built-in middleware support
Scalability	Good for small-to-medium apps	Good for medium apps	Excellent for large-scale apps
Performance Overhead	Minimal	Moderate (re-renders can be costly)	Moderate to High (depends on usage)

Conclusion

EventEmitter is a powerful tool for event-driven workflows, allowing React components to communicate without deep prop drilling or excessive state management. While it helps optimize performance by preventing unnecessary re-renders, it comes with trade-offs like manual cleanup and lack of built-in error handling. When used correctly, EventEmitter can be a lightweight and efficient alternative for handling app-wide notifications, logging, and one-time interactions. However, for managing complex application states, React Context or state management libraries like Redux and Zustand remain more suitable options.

That wraps up our deep dive into EventEmitter!. Thank you for reading, and don't forget to connect on LinkedIn or X to get more content.

If you have any questions or feedback, please leave a comment.

Promise.all(), Promise.any(), and More: Handling Multiple Promises in JavaScript

RakibRahman — Wed, 05 Feb 2025 04:09:56 +0000

Introduction

In Asynchronous JavaScript, Promise plays a vital role. If you're unfamiliar with asynchronous programming in JavaScript, you can Read about it here. In this article, I'll talk about Promise, handling multiple promises, and, more specifically, various Promise Methods and how and when to use them.

Table of Contents:

What is Promise
Promise Methods
Conclusion

Promise

Let's have an overview of Promise first. In JavaScript, Promise is used to perform asynchronous operations. It's an object that contains a status & represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

For example, uploading an image to the server is an asynchronous operation. When the image upload process is done, it can return a value or throw an exception error.
The following code is an example of using a Promise based function.

A Promise has three states:
- Pending(⏳): The initial state, where the promise is neither resolved nor rejected
- Fulfilled(✔): The state when the promise is successfully resolved with a value.
- Rejected(❌): The state when the promise fails due to an error or exception.

Understanding `.then()`, `.catch()`, and `.finally()` in Promises

The .then() method is used to handle the result of a fulfilled promise. It executes only when the promise is successfully resolved.
The .catch() method handles errors when a promise is rejected. It executes if the promise is rejected or if an error occurs in the preceding .then() block.
Both .then() and .catch() always return promises, allowing us to chain promise methods unconditionally to fulfil our requirements.
The .finally() method is always executed, regardless of whether the promise is fulfilled or rejected. It is commonly used for cleanup tasks, such as hiding a loading spinner or logging completion.

For a more detailed explanation of Promise Read this awesome article

How to handle multiple promises.

When working with multiple promises, we can use the following methods to handle them as per our requirements.

Promise.all()
Promise.any()
Promise.race()
Promise.allSettled()

All of these methods take zero or more promises (you can say Arrays of Promises) and iterate over them to produce a single Promise. However, each method has its own characteristics.

Let's see how these methods work.

Promise.all()

Fulfilled if all the promises are resolved.
- returns an array of fulfilled values of Promises.
- Example Code:
Rejected if at least one Promise is rejected.
- returns the value of the rejected Promise
- Example Code:
Diagram:
Use case: When you need all promises to succeed before proceeding (e.g., fetching multiple resources).

Promise.allSettled()

Fulfills when all promises settle. Does not stop even if there are failed promises.
- returns returns each fulfilled promise as an object.
- if the promise is resolved, it will return the promise value with status.

  {
    status: 'fulfilled',
    value:'result'
  }

if the promise is rejected, it will return the promise rejection reason with status.

  {
    status: 'rejected',
    reason: 'Something went wrong'
  }

Example code:
Diagram:
Use case: When you want to handle both successes and failures without stopping the process (e.g., uploading multiple files).

Promise.any()

Fulfills when the first promise is resolved.
- returns the value of the first fulfilled promise.
- Example Code:
If all promises are rejected, then it will return the rejected Promise with an instance of AggregateError which contains all rejection values.
- Example Code:
Diagram:
Use case: When you need the first successful outcome among multiple options (e.g., using redundant APIs or payment gateways, ignoring failures as only need one to succeed).

Promise.race()

Fulfills if any of the promises are resolved or rejected. It does not matter if the settled promise is resolved or rejected, it returns the promise value of the very first settled Promise.
Example Code:
Diagram:
Use case: When you need to act on the first settled promise, regardless of success or failure (e.g., implementing timeouts).

Conclusion

Promises are a cornerstone of modern JavaScript, enabling efficient handling of asynchronous operations. By mastering methods like Promise.all(), Promise.allSettled(), Promise.any(), and Promise.race(), you can tackle complex workflows with ease. From fetching multiple resources to implementing timeouts, these tools empower you to build robust and scalable applications.

That's all for today. Thank you for reading, and don't forget to connect on LinkedIn or X to get more contents.

If you have any questions or feedback, please leave a comment.

JavaScript Essentials: Handling Null, Undefined, and Safely Accessing Data with ?? and ?.

RakibRahman — Sat, 01 Feb 2025 05:51:52 +0000

Table of contents

Introduction
Null
Undefined
Checking for null & undefined value
The Nullish coalescing operator(??)
Difference between nullish coalescing operator and logical Or operator
Optional chaining (?.)
Interview questions
References
Conclusion

Introduction

There are two types of values in JavaScript. One is Primitive values, and another is objects. null and undefined are primitive data types and behave similarly. Both are treated as falsy values and often used interchangeably. Which sometimes leads to unexpected results due to not being able to distinguish between them. null and undefined are only two JS values that give us exception (TypeError) messages when trying to read property.

Hopefully, this post will help you firm your knowledge of these data types and how to use nullish coalescing operator & optional chaining when dealing with null and undefined values.

Null

In JavaScript null means intentional absence of value
null is a primitive datatype but treated as an object. Variables with object type are initialized with null.
null will be treated as 0 if any primitive operation is applied.
null is treated as falsy value for boolean operations.
The JSON data format does not support undefined, only null

Undefined

In JavaScript undefined means not initialized or does not exist.
undefined datatype indicates that variable is declared but it does not exist in the memory(no value assigned).
Declared variable is always treated as undefined if no value is assigned.
If a function does not return anything ,it will always return undefined by default.
undefined datatype occurs when variable is uninitialized, specific function parameter is not provided.

Checking for null and undefined value

JavaScript provides different ways to check for null and undefined. Here’s an example demonstrating how to handle them safely.

The Nullish coalescing operator(??)

The nullish coalescing operator(??) was introduced in ECMAScript 2020. It returns left hand side value if the value is not either undefined or null.If the value is either undefined or null it will return the right hand side value.

For example, when fetching data from the server, if the value is not either null or undefined we can show the received value otherwise it will show the default value as a fallback.The syntax of `nullish coalescing operator is ??.

Difference between nullish coalescing operator and logical Or operator

At first glance, nullish coalescing operator feels similar to the logical Or (||) operator.The main difference is that nullish coalescing operator only returns default value when left hand side value is either undefined or null. Logical Or (||) operator returns the default value for all other falsy values such false,0,string etc.

Optional chaining (?.)

Optional chaining (?.) operator is used to access properties and methods calls of an object. If the object value is either null or undefined it will return undefined instead of throwing an error, otherwise it will perform the operation.

Optional Chaining is useful when fetching data from the server, as it wont crash the app if any object property is null or undefined.

Interview questions

Let's look at some interview questions related to null,undefined,nullish coalescing operator and optional chaining.

what is the difference between null and undefined?

Ans: undefined means a variable that has no value. null means the variable was intentionally set to have no value.

What is the type of null?

Ans: object

What is output of following code?

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

Ans: NaN

What does the nullish coalescing operator do?

Ans: It returns the right-hand side operand when the left hand operand is null or undefined. Otherwise, the left hand operand is returned. The syntax is ??.

If a function has no return value specified, what value does it return?

Ans: undefined

What is change can be made that can prevent this code from throwing an error?

 const person = {
    name: 'Mehedi',
    age: 21,
    address: {
        city: 'Dhaka',
        }
            }
console.log(person.address.houseNumber)

Ans: error can be avoided by using Optional chaining(?.), change console.log(person.address.houseNumber); to console.log(person.address?.houseNumber);

References

Conclusion

In this short post, we've looked at null and undefined data types. We also talked about Nullish Coalescing and Optional Chaining operators and when and how to use them. Go through the interviews question to solidify your learning. Hopefully, you learned something new today.

That's all for today. Thank you for reading, and don't forget to connect on LinkedIn or Twitter to get more contents.

If you have any questions or feedback, please leave a comment

Memoization in JavaScript? And how to apply it to get better code performance.

RakibRahman — Sun, 20 Feb 2022 17:01:35 +0000

As a programmer, we always want to write code that is robust and gives us better performance. But sometimes we face performance issues due to not applying good optimization techniques. One such technique is Memoization. Memoization offers notable performance benefits when dealing with a function that has repeated parameters.
In this article, I'm going to talk about Memoization, how you can implement it and when it should be used.

Table of contents

Prerequisites
What is Memoization
Implementing Memoization
How memoization works
Normal function vs Memoized Function
Use Cases
Libraries for Memoization
Tradeoffs
References
Conclusion

Prerequisites

Before you begin reading, it will be great to know the followings:

JavaScript Fundamentals
Closure
Pure Function
Higher-Order Function

So let's get started!!!

What is memoization?

From Wikipedia:

In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.

So, Memoization is an optimization technique that can be used to reduce extensive(time-consuming) calculations by saving previous input to something called cache and returning the result from it. When a memoized function is given the same input again, it will return the cached result without calculating from the start. Thus saving code execution time and memory.

As you can guess, Memoization is not only limited to JavaScript but is also widely supported by many other languages. It's a common concept in the programming world.

Implementing Memoization

Before seeing how Memoization works, let's look at a simple example that will demonstrate how Memoization can help us to get better performance.
Consider the following function which returns the square of a number.

Normal Function

In case if you are not familiar with console.time() and console.timeEnd , they are used to track how long an operation takes. Read more about them on MDN.

Here, I've invoked the function with the same input four times. Here is its completion time:

Invocations	Time Taken
First	9.331ms
Second	2.336ms
Third	1.397ms
Fourth	0.137ms

Later we'll compare this result against the memoized result.

Memoized Function

Now we are going to implement Memoization in the getSquare function. Remember that to memoize a function, it should be pure so that return values are the same for the same inputs every time.

Take a look at the following function:

Demo Output:

How Memoization works?

The principal to making a function memoized function is to store its last input and output. In JavaScript environment, Memoization heavily relies on Closure and Higher-Order Functions.

Code breakdown of `memoSquare()` function:

In line 3 we have variable named cache to store previous inputs.
In Line 5 we return the whole memoized function.
In Line 7 we check if the input is in the cache. If so, we return the cached value.cache can remember the values because of the closure it's implemented in. And this only works because the function we're working with is a pure function.
If we check the output of cache in line 9 of Output, we'll see that cache object is containing all the inputs only once.For example, We have inputted value 4 multiple times but it only storing it once. If the current inputted value is in the cache then it simply returns value. Check the Demo output screenshot.
From line 13 we write our function logic. In here it runs a for loop and simply returns a square of a number.
In line 15 we cache/store our new input value to the cache object.

Now lets checkout the completion time of memoSquare() function.

Invoking the function multiple times with same value:

Result:

Invocations	Time Taken
First	7.741ms
Second	0.056ms
Third	0.52ms
Fourth	0.045ms

Normal function vs Memoized Function:

From the comparison table, you can see how Memoization grants us better performance aka execution time each time it is called with the same value. It cuts down the heavy calculations for a previous value. So it's a good idea to memoize a function that does heavy computations or is expensive on time and memory.

Use Cases

You can use Memoization in the following cases:

Repeated invocations of a function.
When you have a wide range of input values.
You have an idea what will be the possible inputs.
Functions that involves mathematically heavy operations.
In recursive functions.

Tradeoffs

Like any other optimization technique, There are limitations of Memoization. In some cases, improper use of Memoization can actually harm performance. Memoization works by storing old results and it has to be stored somewhere. As a consequence, memoized functions consume additional memory.
Memoization is appropriate for functions where there’s a high chance that the same input values will be used regularly. So Memoization may not be ideal for infrequently called or fast executing functions.

Third-party libraries for Memoization

You can use following third party libraries to implement Memoization:

References:

Followings are some resources to help you out:

Conclusion

Memoization is a form of caching which gives performance improvements where a function is called many times with the same input. Applying Memoization will help you to write performant and robust code. But you have to be careful about not implementing it in an irrelevant scenario.

That's all for today. Thank you for reading, and don't forget to connect on LinkedIn or Twitter

If you have any questions or thoughts, please leave a comment!?

JavaScript Array Methods Cheat Sheet with brief explanation.

RakibRahman — Sun, 14 Mar 2021 16:40:32 +0000

Today I'll share some important array methods cheat sheet along with short summary which will tell you main usage of the particular method.

Lets Start!

⚡ `concat()`,`copyWithin()`,`every()`,`fill()` Methods

⚡ `filter()`,`find()`,`findIndex()`,`forEach()` Methods

⚡ `reduce()`,`join()`,`includes()`,`some()` Methods

⚡ `reverse()`,`push()`,`pop()`,`unshfit()`,`shift()` Methods

⚡ `slice()`,`splice()`,`sort()`,`flat()` Methods

Get the source code || Download The CheatSheet

Thanks for reading this article.Stay tuned and keep coding!

The Set() Object in JavaScript - A Nimble Introduction

RakibRahman — Mon, 01 Mar 2021 20:42:20 +0000

Hello, I am going to give you a quick introduction about JavaScript Set() object and its must know properties and methods.

The Set() Object

The Set object is a collection of elements. It can store primitive values or object references.Set can only contains distinctive elements,so With Set object you can remove duplicate elements.

Using the Set object

Setting up an empty Set object
Set object With array

Iterating Sets

You can iterate over items in Set object using for...of statement.

Adding an element to a set

You can add an element to the end of a Set object via the add() method.

Number of elements in a Set

To see the number of (unique) elements in a Set object use the size property.

Checking an element in the set

The has method will tell you whether a value exists in a Set object.

Delete elements from set

Using delete method you can remove a value from the Set object.

Remove all elements from set

To remove all the elements from Set object simply use clear method.

Hope you have learnt something from this article.Kindly forgive any mistake as it is my first article. Happy Coding!

DEV Community: RakibRahman

Understanding the Single Responsibility Principle in S.O.L.I.D

Table of Contents

Intro

What is the S.O.L.I.D Principle?

What is SRP?

Real-World Analogy of SRP

Code Example

Violation of SRP

Adhering to SRP

What breaks SRP

1. Not adhering to DRY principle.

2. Missing KISS principle.

3. Tight Coupling

How to achieve SRP

1. Adhere to the DRY Principle

2. Follow the KISS Principle

3. Avoid Tight Coupling

Benefits of SRP

References

Conclusion

web worker

Simplifying React with EventEmitter: Reduce Prop Drilling & Unnecessary Re-renders

Intro

What's an Event Emitter?

Basic Example of EventEmitter in JavaScript

Implementing EventEmitter in React

Step 1: Setting Up EventEmitter

Step 2: Emitting an Event from Any Component

Step 3: Subscribing to the Event from Any Component

Benefits of Using EventEmitter

Drawbacks of EventEmitter

EventEmitter, React Context, Redux/Zustand: Which Tool Fits Your Use Case?

Conclusion

Promise.all(), Promise.any(), and More: Handling Multiple Promises in JavaScript

Introduction

Promise

Understanding .then(), .catch(), and .finally() in Promises

How to handle multiple promises.

Promise.all()

Promise.allSettled()

Promise.any()

Promise.race()

Conclusion

JavaScript Essentials: Handling Null, Undefined, and Safely Accessing Data with ?? and ?.

Introduction

Null

Undefined

Checking for null and undefined value

The Nullish coalescing operator(??)

Difference between nullish coalescing operator and logical Or operator

Optional chaining (?.)

Interview questions

References

Conclusion

Memoization in JavaScript? And how to apply it to get better code performance.

Prerequisites

What is memoization?

Implementing Memoization

Normal Function

Memoized Function

Demo Output:

How Memoization works?

Code breakdown of memoSquare() function:

Invoking the function multiple times with same value:

Result:

Normal function vs Memoized Function:

Use Cases

Tradeoffs

Third-party libraries for Memoization

References:

Conclusion

JavaScript Array Methods Cheat Sheet with brief explanation.

⚡ concat(),copyWithin(),every(),fill() Methods

⚡ filter(),find(),findIndex(),forEach() Methods

⚡ reduce(),join(),includes(),some() Methods

⚡ reverse(),push(),pop(),unshfit(),shift() Methods

⚡ slice(),splice(),sort(),flat() Methods

The Set() Object in JavaScript - A Nimble Introduction

The Set() Object

Understanding `.then()`, `.catch()`, and `.finally()` in Promises

Code breakdown of `memoSquare()` function:

⚡ `concat()`,`copyWithin()`,`every()`,`fill()` Methods

⚡ `filter()`,`find()`,`findIndex()`,`forEach()` Methods

⚡ `reduce()`,`join()`,`includes()`,`some()` Methods

⚡ `reverse()`,`push()`,`pop()`,`unshfit()`,`shift()` Methods

⚡ `slice()`,`splice()`,`sort()`,`flat()` Methods