DEV Community: Dhanasai Tholeti

Mastering the Strategy Pattern with a Car Example 🚗⚙️

Dhanasai Tholeti — Thu, 13 Feb 2025 15:48:23 +0000

In the world of software design, flexibility and maintainability are crucial. One of the best ways to achieve this is through the Strategy Pattern—a behavioral design pattern that allows us to define a family of algorithms, encapsulate each one, and make them interchangeable.

Let’s break it down using a car example! 🚘

What is the Strategy Pattern?

The Strategy Pattern enables an object’s behavior to be selected at runtime. Instead of hardcoding logic inside an object, we delegate it to separate strategy classes that encapsulate different behaviors. This promotes the Open-Closed Principle—where code is open for extension but closed for modification.

Real-World Example: Cars and Their Behaviors 🚗⚡️⛽

Consider a car that can have different transmission types (manual, automatic, semi-automatic) and fuel types (gasoline, diesel, electric). Instead of tightly coupling the car’s logic to these behaviors, we use the Strategy Pattern to define separate classes for each.

🔹 Implementing Transmission Strategies

Each transmission type is an independent class that implements the TransmissionStrategy interface:

export interface TransmissionStrategy {
  changeGear(): void;
}

export class ManualTransmission implements TransmissionStrategy {
  changeGear(): void {
    console.log("Changing gear manually.");
  }
}

export class AutomaticTransmission implements TransmissionStrategy {
  changeGear(): void {
    console.log("Changing gear automatically.");
  }
}

export class SemiAutomaticTransmission implements TransmissionStrategy {
  changeGear(): void {
    console.log("Changing gear semi-automatically.");
  }
}

🔹 Implementing Fuel Strategies

Similarly, different fuel types adhere to a FuelStrategy interface:

export interface FuelStrategy {
  refuel(): void;
}

export class Gasoline implements FuelStrategy {
  refuel(): void {
    console.log("Refueling gasoline...");
  }
}

export class Diesel implements FuelStrategy {
  refuel(): void {
    console.log("Refueling diesel...");
  }
}

export class Electric implements FuelStrategy {
  refuel(): void {
    console.log("Charging the battery...");
  }
}

🔹 The Car Class Using Strategies

The Car class now delegates behavior to the appropriate strategy:

export class Car {
  private transmission: TransmissionStrategy;
  private fuel: FuelStrategy;

  constructor(transmission: TransmissionStrategy, fuel: FuelStrategy) {
    this.transmission = transmission;
    this.fuel = fuel;
  }

  setTransmission(transmission: TransmissionStrategy): void {
    this.transmission = transmission;
  }

  setFuel(fuel: FuelStrategy): void {
    this.fuel = fuel;
  }

  refuel(): void {
    this.fuel.refuel();
  }

  changeGear(): void {
    this.transmission.changeGear();
  }
}

Why Use the Strategy Pattern? 🤔

✅ Flexibility: We can change the car’s transmission and fuel type dynamically at runtime.

✅ Encapsulation: Each behavior is encapsulated separately, making it easy to add new strategies.

✅ Maintainability: Avoids complex if-else conditions, making the code clean and modular.

✅ Reusability: Strategies can be reused across different contexts without modifications.

Example Usage 🚀

Now, let’s create different cars and modify their behaviors at runtime:

const manualCar = new Car(new ManualTransmission(), new Gasoline());
manualCar.changeGear(); // Output: Changing gear manually.

const automaticCar = new Car(new AutomaticTransmission(), new Electric());
automaticCar.changeGear(); // Output: Changing gear automatically.

const semiAutomaticCar = new Car(new SemiAutomaticTransmission(), new Diesel());
semiAutomaticCar.changeGear(); // Output: Changing gear semi-automatically.

manualCar.setTransmission(new AutomaticTransmission()); // Switching to automatic
semiAutomaticCar.setFuel(new Electric()); // Switching to electric

manualCar.changeGear(); // Output: Changing gear automatically.
semiAutomaticCar.refuel(); // Output: Charging the battery...

Final Thoughts 💡

The Strategy Pattern is a powerful tool for designing flexible and reusable software. By decoupling behaviors into independent strategies, we make our applications more adaptable to change.

If you found this insightful, drop a like and share this with your network! 🚀💬

A Game-Changing Next.js Feature That Will Make Your Life Easier! 🚀

Dhanasai Tholeti — Mon, 10 Feb 2025 11:57:48 +0000

As frontend developers, we all know the struggle:

You add tons of console.log statements while debugging, making sure your data is just right. Then comes the tedious part—removing them one by one before deploying to production.

But what if I told you there’s an easier way?

Meet Next.js’s Hidden Gem: Automatic Console Log Removal

I recently discovered a cool Next.js config setting that removes all console.log statements from your production build automatically—without any manual effort!

Here’s how it works:

🔹 Remove All `console.log`s Effortlessly

Simply add this snippet to your next.config.js file:

{
  ...restOfTheConfig,
  compiler: {
    removeConsole: true,
  }
}

✨ This will strip out all console logs from your production build, keeping your codebase cleaner and optimized!

🔹 Want to Keep Error Logs? No Problem!

If you still want to retain error logs while removing everything else, tweak the config like this:

{
  ...restOfTheConfig,
  compiler: {
    removeConsole: {
      exclude: ["error"],
    }
  }
}

With this setting, only error logs will be preserved while other logs are removed—making debugging easier without cluttering your production code.

Why This Matters?

✅ No more manual cleanup of console.logs before deployment

✅ Better performance by reducing unnecessary logs

✅ Cleaner production code while still keeping error tracking intact

This small yet powerful Next.js feature streamlines your workflow and saves you time. If you found this helpful, drop a ❤️ and share it with fellow developers!

Have you used this feature before? Let me know in the comments! 👇

🚀 Git Cherry-Pick: The Hidden Gem You Need to Know! 🚀

Dhanasai Tholeti — Mon, 03 Feb 2025 14:39:57 +0000

Last Friday, I made a small typo fix and accidentally pushed it straight to production instead of the testing environment. Since it was already live, I had to merge the change back into testing.

At first, I thought of pulling production into testing—but that felt unnecessary. Then, while digging through Git’s documentation, I found a game-changing command: git cherry-pick.

🍒 What is Git Cherry-Pick?

It lets you pick and apply specific commits from one branch to another without pulling or rebasing. Neat, right?

Here’s a quick guide on how to use it:

🔹 Scenario: You have two branches, A (target) and B (source), and you need a specific commit from B in A.

🔹 Steps:

1️⃣ Checkout your target branch:

   git checkout A

2️⃣ View commit history of source branch:

   git log B --oneline

3️⃣ Copy the commit hash you want to merge.

4️⃣ Apply the commit to your target branch:

   git cherry-pick <commit-hash>

5️⃣ Want multiple commits? No problem!

   git cherry-pick <commit-hash1> <commit-hash2>

6️⃣ If conflicts occur:

   # Resolve conflicts
   git add .
   git cherry-pick --continue

And just like that, you've merged the changes you needed without messing up the Git history! 😎

💡 Have you used git cherry-pick before? Share your experience below! 👇

A Comprehensive Guide to Structuring Your React App Project

Dhanasai Tholeti — Sun, 31 Dec 2023 01:55:51 +0000

Introduction

Structuring a React app project is crucial for maintaining code organization, scalability, and modularity. By dividing your app into multiple folders and files, you can easily navigate and manage different components, styles, utilities, and other resources. In this article, we will explore the benefits of structuring your React app and provide a step-by-step guide on how to effectively structure your project for optimal development experience.

Benefits of Structuring Your React App

Code Organization and Readability

A well-structured project allows developers to easily locate and understand different parts of the codebase. By dividing your app into meaningful folders and files, you can create a logical hierarchy that reflects the app's architecture. This makes it easier for both you and your team to navigate, maintain, and update the codebase, resulting in improved code readability and organization.

Modularity and Reusability

Structuring your React app promotes modularity and reusability. By breaking down your app into smaller components, you can create self-contained and reusable pieces of code. This allows you to easily reuse components across different parts of your app or even in future projects, saving time and effort in development.
Scalability and Collaboration

As your React app grows, maintaining scalability becomes essential. A well-structured project provides a solid foundation for scaling your app without introducing complexity. It allows for easy integration of new features, reduces the risk of code conflicts during collaboration, and facilitates efficient teamwork among developers.

The Individual Files:

Main.tsx

The Main.tsx file serves as the entry point for your React application. Its primary function is to render the App component within the index.html file. This file acts as the starting point for your application's component tree.

App.tsx

The App.tsx file is responsible for rendering the entire application's routes along with their respective layouts. It serves as the central point for routing and composition of different pages and components.

Layout.tsx

The Layout.tsx file is responsible for rendering shared components, such as a navbar, that need to be displayed across multiple pages or components within your application. It helps maintain consistency in the overall design and layout.

index.css

The index.css file is where the root styles of your application are stored. If you are using a CSS framework like Tailwind CSS, separate CSS files may not be necessary. However, if you choose to use custom CSS, you can define the global styles in this file.

The Folder Structure:

assets folder

The assets folder is used to store static files such as fonts, images, or any other external resources required by your application. Keeping them separate from the source code allows for easier management and scalability.

components folder

The components folder is where reusable components are stored. It is recommended to create a separate folder for each component if you are using CSS, SCSS, or styled components. This folder should contain an index.tsx file for rendering the JSX and an index.css file for styling the component. If you are using css-in-js then you don't have to create a separate directory for each component.

components/
├── Component1/
│   ├── index.tsx
│   └── index.css
└── Chat/
    ├── ChatRender.tsx
    └── ChatInput.tsx

Additionally, it is beneficial to group related components into subfolders within the components directory. For example, if you have a chat UI, you can create a separate folder called Chat and group all chat-related components within it.

configs folder

The configs folder is used to store application configurations. If you have multiple APIs or backend services, you can store their configurations in separate files and export them for use throughout the application. This allows for easy management and modification of configuration settings.

hooks folder

The hooks folder is where reusable custom hooks live. Hooks are abstracted functions that encapsulate common functionality and can be shared across different components. To differentiate them from regular TypeScript files, you can consider using the .hook.ts extension.

libs/utils folder

The libs or utils folder is a handy directory that houses helper functions, types, and any other utility files. It is recommended to organize this folder by creating subdirectories for data, types, and other relevant categories.

libs/
├── Data/
│   └── dummyData.json
└── Types/
    ├── user.type.ts
    └── device.type.ts

This separation allows for easy accessibility and organization of external data, such as dummy data, and reusable types.

pages folder

The pages folder is where all the routable pages or screens of your application reside. Each page is typically composed of one or more components, representing a specific view or functionality.

pages/
├── LoginScreen.tsx
├── SignupScreen.tsx
├── HomeScreen.tsx
└── NotFoundScreen.tsx

routes folder

The routes folder is where you can manage and define the routes of your application. You can implement route guards or any other operations related to routing within this directory.

services folder

The services folder is used for integrating external services, such as state management with Redux or WebSocket connections. It is recommended to organize services into subdirectories based on functionality or type.

services/
├── state/
│   ├── slices/
│   └── store.ts
└── websockets/
    └── socketManager.ts

This folder structure allows for better separation and organization of different services used within your application.

Conclusion:

No matter the size of your project, it is crucial to adhere to the aforementioned folder structure in order to ensure code reusability, maintainability, and collaboration. Remember, it is essential to customize the folder structure to suit your specific requirements.