DEV Community: Chhakuli Zingare

Why the Boy Scout rule will make you a better developer

Chhakuli Zingare — Thu, 13 Mar 2025 03:30:00 +0000

Introduction: Why Messy Code Frustrates Developers

Imagine you’re tasked with fixing a small bug in an old codebase. You open the relevant file and immediately feel a wave of frustration, variables with meaningless names, outdated comments, functions doing way more than they should. You fix the bug, but the experience leaves a bad taste in your mouth.

Why didn’t the previous developers clean up their mess? Why do we keep inheriting code that is harder to work with than it should be?

This is where I think knowing the Boy Scout Rule will help us. The Boy Scouts have a simple principle:

“Leave the campground cleaner than you found it.” In software development, this translates to “Leave the code better than you found it.”

This isn’t just a best practice; it’s a mindset shift. When developers embrace this rule, they contribute to cleaner, more maintainable codebases without waiting for large-scale refactors.

In this article, you’ll learn why adopting the Boy Scout Rule will make you a better developer, how it prevents technical debt, and how to apply it in your daily work.

What is the Boy Scout Rule?

Origin of the Term

The phrase comes from the Boy Scouts of America, who teach young scouts to leave campsites in better condition than when they arrived. The idea is simple: small, consistent improvements create a better experience for everyone.

Let’s see how it applies in Software Development

Robert C. Martin (Uncle Bob), author of Clean Code, introduced this idea into software development. Instead of waiting for massive refactoring projects, he suggested that developers make incremental improvements every time they touch code.

Following the Boy Scout Rule means:

Renaming unclear variable names
Removing unused code
Splitting large functions into smaller, more focused ones
Writing or improving documentation
Replacing outdated practices with modern approaches

By consistently improving code in small ways, developers create a culture of quality that compounds over time.

The Importance of Incremental Code Improvement

Developers always say, including me, “I’ll clean this up later” or “We’ll refactor this in the next sprint.” But let’s be real: that rarely happens. There’s always a new feature to build, a bug to fix, or a deadline to meet. Refactoring takes a backseat; before you know it, messy code just sits there, growing worse with every update.

The longer it stays, the harder it becomes to fix. Every new layer of complexity makes it riskier to touch, and soon, what could have been a small improvement turns into a massive, intimidating refactor that no one has time for.

That’s why you shouldn’t wait for a “perfect time” to clean up code. Instead, make small, consistent improvements every time you work on a file.

If you come across a vague variable name like x1, rename it to something meaningful like customerId.
If you see a 100-line function, break it down into smaller, more manageable helper functions.
If there’s dead code taking up space, delete it. These tiny changes may seem insignificant at the moment, but they add up over time, making the codebase cleaner, more readable, and easier to maintain.

Just a few extra minutes each day is enough to prevent technical debt from piling up. When the code stays clean, future updates become smoother, debugging becomes faster, and I don’t have to waste time deciphering past decisions.

Think, like, my goal is simple:

leave the code a little better than I found it. Instead of waiting for that big refactor that may never happen, Focus on improving things now.

How to Apply the Boy Scout Rule in Your Daily Development

The Boy Scout Rule is simple: Leave the code better than you found it. But how do you actually make that a daily habit? It’s not about massive rewrites or dedicating full sprints to refactoring; it’s about small, meaningful improvements that add up over time.

Here’s how you can apply it every day:

Fix Small Things When You Touch the Code

Whenever you are working on a feature or fixing a bug, take an extra minute to clean up something small. Maybe rename a confusing variable so the next person (or future me) doesn’t have to decode its meaning. If you see a messy if statement, simplify it. Unnecessary console logs or outdated comments? Get rid of them. These tiny changes don’t slow you down, but they make a big difference over time.
Refactor Gradually Instead of Rewriting Everything

Bad code is everywhere: legacy files, old functions, and quick fixes that somehow became permanent. But the trick isn’t to rewrite everything in one go. Instead, break it down. Maybe today you extract a helper function to make a long method more readable. In a later PR, you can optimize performance. Step by step, the code improves without derailing your current tasks.
Make It a Team Habit

It’s easier to keep code clean when the whole team is on board. That’s why you can bring up small refactors in code reviews and encourage others to do the same. Instead of just pointing out problems, suggest simple improvements. When clean code becomes a shared responsibility, it doesn’t feel like a chore, it becomes part of how we work.
Improve Code Reviews with the Boy Scout Rule

Code reviews aren’t just about catching bugs; they’re an opportunity to improve code quality. Always appreciate when someone suggests a small refactor alongside their feedback; it makes the codebase better without extra effort. Also, highlight good improvements in PRs so the whole team learns from them. And to keep things smooth, rely on automated tools like linters and formatters to handle the basic clean-up so you can focus on the bigger improvements.

Challenges & Pushback: Why Developers Resist Cleaning Code

"I don’t have time for this!"

Small changes take seconds but save hours of future debugging. Incremental improvements reduce long-term complexity and maintenance costs.
"It’s not my responsibility!"

Everyone on a team owns the codebase. If no one improves it, it will degrade over time, hurting productivity for everyone.

The Long-Term Benefits of Following the Boy Scout Rule

When teams consistently apply this principle, they see major benefits:

Faster onboarding for new developers. A cleaner codebase makes it easier for newcomers to understand and contribute.
Less frustration when maintaining old code. Developers spend less time deciphering bad code and more time solving real problems.
Fewer bugs and better performance. Cleaner, well-structured code leads to fewer errors.
A team culture that values quality. When everyone takes ownership of code quality, the entire development process improves.

Conclusion: The Rule That Sets Great Developers Apart

The Boy Scout Rule isn’t about striving for perfection; it’s about continuous improvement. By making small, incremental changes every time you touch code, you create a healthier, more maintainable codebase.

Next time you work on a feature or fix a bug, challenge yourself: Find one small thing to improve. Do this consistently, and over time, you’ll become a better developer.

Great developers aren’t just coders; they’re caretakers of the codebase, ensuring that future generations of developers inherit something better than what came before.

Making small, continuous improvements not only enhances the codebase but also boosts motivation and confidence. Developers experience a sense of accomplishment when they leave things better than they found them. Over time, this builds a habit of writing clean, efficient code naturally.

As someone who is actively learning and trying to apply best practices in software development, I find that every small improvement teaches me something new. Whether it’s refactoring a function, cleaning up, or enhancing readability, I am continuously improving myself and my understanding of code quality. The journey towards mastering clean code is never-ending, but each incremental step makes a difference.

I hope that after reading this blog, you will also start taking these incremental steps to make your codebase cleaner.

Happy Coding!

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

The YAGNI principle in React development

Chhakuli Zingare — Mon, 10 Mar 2025 03:30:00 +0000

Introduction

Imagine you’re working on a new feature, and an idea pops into your head: “Maybe I should add this extra function now—it might be useful later.” It seems like a proactive approach, right? After all, future-proofing your code is a good thing, isn’t it?

Not always.

This is where You Ain’t Gonna Need It (YAGNI) comes in. YAGNI is one of the simplest yet most powerful software development principles. It helps developers avoid wasted effort, keeps code simple and maintainable, and reduces complexity and future technical debt.

Yet, many developers, especially ambitious ones, tend to ignore this rule. Why? Because we love solving problems, even ones that don’t exist yet. It’s tempting to build for every possible future scenario, but doing so often leads to bloated, hard-to-maintain code.

What is YAGNI, Really?

Don’t implement something until you actually need it.

However, many misunderstand YAGNI. Some developers think it means never planning ahead, which isn’t true. Others assume it leads to writing lazy, unscalable code, but YAGNI is actually about writing just the right amount of code: no more, no less.

Following YAGNI doesn’t mean ignoring future scalability. It simply ensures that your development process remains focused on solving immediate problems rather than hypothetical ones.

Why Do Developers Over-Engineer?

1. Fear of Future Changes

Developers worry: “What if we need this later?” This fear leads to building unnecessary features that might never be used.

2. Desire to Build the 'Perfect' System

Trying to account for every possible edge case upfront often results in overly complex architectures that slow development down.

3. Lack of Experience

New developers often equate writing more code with writing better code. In reality, simplicity is often more valuable.

Real-World Example

Let's look at some actual code where developers often do too much.

Example 1: The Button That Does Everything

Here's a button component that's trying way too hard:

interface ButtonProps {
  label: string;
  onClick: () => void;
  variant?: 'primary' | 'secondary' | 'tertiary';
  size?: 'small' | 'medium' | 'large';
  shape?: 'round' | 'square' | 'pill';
  elevation?: 'flat' | 'raised' | 'floating';
  animation?: 'bounce' | 'pulse' | 'wave';
  customClasses?: string;
  icon?: React.ReactNode;
  iconPosition?: 'left' | 'right';
  loading?: boolean;
  disabled?: boolean;
  tooltipText?: string;
  tooltipPosition?: 'top' | 'bottom' | 'left' | 'right';
}

const Button: React.FC<ButtonProps> = ({
  label,
  onClick,
  variant = 'primary',
  size = 'medium',
  shape = 'square',
  elevation = 'flat',
  animation,
  customClasses,
  icon,
  iconPosition = 'left',
  loading,
  disabled,
  tooltipText,
  tooltipPosition = 'top',
}) => {
  return (
    <div className="button-wrapper">
      {tooltipText && <Tooltip position={tooltipPosition}>{tooltipText}</Tooltip>}
      <button
        className={`button ${variant} ${size} ${shape} ${elevation} ${animation} ${customClasses}`}
        onClick={onClick}
        disabled={disabled || loading}
      >
        {loading && <Spinner />}
        {icon && iconPosition === 'left' && icon}
        {label}
        {icon && iconPosition === 'right' && icon}
      </button>
    </div>
  );
};

Here's what you probably actually need:

interface ButtonProps {
  label: string;
  onClick: () => void;
  variant?: 'primary' | 'secondary';
  disabled?: boolean;
}

const Button: React.FC<ButtonProps> = ({
  label,
  onClick,
  variant = 'primary',
  disabled = false,
}) => (
  <button
    className={`button ${variant}`}
    onClick={onClick}
    disabled={disabled}
  >
    {label}
  </button>
);

Way simpler, right? If you need a loading state later, add it then!

Balancing YAGNI with Future-Proofing

YAGNI doesn’t mean ignoring scalability—it’s about solving real problems, not imaginary ones.

How to Apply YAGNI Without Sacrificing Flexibility:

Keep Code Modular: Design components that can be extended without premature implementation.
Follow Lean Development: Build only what’s necessary and iterate as needed.
Use Feature Toggles: Instead of fully implementing a feature that might not be used, toggle it on when the need arises.

How to Keep It Simple

So, how do you resist the temptation to overengineer? Here are practical strategies:

1.Ask yourself:

"Do we really need this now?"
"What's the simplest thing that could work?"

2.Follow the "Rule of Three":

Wait until you need to solve the same problem three times
Then think about making it flexible

3.Make it work first:

Get it working simply
Then make it better if you need to
Don't try to make it perfect right away

Key Takeaways

Write only what’s needed. Avoid adding features just because they "might be useful."
Refactor when necessary. If new requirements come up, adjust your code when they arrive.
Embrace simplicity. The simplest solution is often the best one.

Following YAGNI helps keep your code clean, maintainable, and efficient—so you can focus on building real solutions instead of solving problems that don’t exist yet!

Final Thoughts: Becoming a YAGNI-First Developer

By embracing YAGNI, you’ll write less code, introduce fewer bugs, and ship faster. Every time you feel tempted to add something just in case, pause and ask yourself: “Are we really gonna need this?”

The best software isn’t the one with the most features; it’s the one that’s easiest to maintain, understand, and extend when the time comes.

Remember:

Simple code = Good code
Add stuff when you need it
Don't guess about the future
Less code = Less bugs

Next time you're coding and think, "maybe we'll need this...", stop and ask "but do we need it right now?"

Chances are, you don't!

Keep it simple and happy coding!

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

Dependency Inversion Principle (DIP) in React

Chhakuli Zingare — Mon, 03 Mar 2025 03:30:00 +0000

Welcome back to our SOLID principles in the React series! So far, we’ve covered:

✅ S: Single Responsibility Principle (SRP): Keep components focused.

✅ O: Open/Closed Principle (OCP): Make extensions easy, not modifications.

✅ L: Liskov Substitution Principle (LSP): Keep components interchangeable without breaking behavior.

✅ I: Interface Segregation Principle (ISP): Keep your React components and interfaces lean, modular, and easier to maintain.

In today's blog, let's talk about something that can dramatically improve your React applications: the Dependency Inversion Principle (DIP). Don't worry if it sounds complicated by the end of this post, you'll have a practical understanding of how to use it in your React projects.

What's DIP in simple words?

The Dependency Inversion Principle has two main parts:

High-level components shouldn't depend on low-level components. Both should depend on abstractions.
Abstractions shouldn't depend on details. Details should depend on abstractions.

In React terms, think of it this way: instead of having your components directly depend on specific implementations (like a particular API service or UI library), they should depend on interfaces or props that define what they need. This makes your components more flexible and easier to change.

Why Dependency Inversion Matters in React

Applying DIP in React can help with:

Better component reusability: Separating UI logic from business logic makes components more reusable across different parts of the app.
Easier testing: Components relying on abstractions (props, context, hooks) instead of direct API calls are easier to test using mocks.
Improved maintainability: When components depend on abstractions instead of concrete implementations, swapping logic (e.g., changing an API call) doesn't require rewriting UI components.
Clearer separation of concerns: Business logic stays in services or hooks, while components focus on rendering UI.

Now, let’s see a bad example and refactor it using DIP.

A Bad Example: Tight Coupling Between UI and Business Logic

Consider this React component that fetches user data and displays it:

import React, { useEffect, useState } from "react";

const UserProfile: React.FC = () => {
  const [user, setUser] = useState<{ name: string; email: string } | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch("https://api.example.com/user")
      .then((res) => res.json())
      .then((data) => {
        setUser(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <p>Loading...</p>;
  return <div>{user ? <h2>{user.name}</h2> : <p>No user found</p>}</div>;
};

export default UserProfile;

What’s Wrong Here?

Direct API call inside the component: This makes it hard to reuse UserProfile elsewhere with different data sources.
Difficult to test: Since fetch is inside the component, mocking API responses becomes a hassle.
Tightly coupled logic: UI and data fetching are tightly bound, violating the separation of concerns.

Applying Dependency Inversion: Refactoring with Hooks

We can improve this by moving data-fetching logic into a separate hook and passing the data as props.

Step 1: Create a Custom Hook for Data Fetching

import { useEffect, useState } from "react";

export const useUserData = () => {
  const [user, setUser] = useState<{ name: string; email: string } | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch("https://api.example.com/user")
      .then((res) => res.json())
      .then((data) => {
        setUser(data);
        setLoading(false);
      });
  }, []);

  return { user, loading };
};

Step 2: Use Dependency in the Component

import React from "react";

interface UserProfileProps {
  user: { name: string; email: string } | null;
  loading: boolean;
}

const UserProfile: React.FC<UserProfileProps> = ({ user, loading }) => {
  if (loading) return <p>Loading...</p>;
  return <div>{user ? <h2>{user.name}</h2> : <p>No user found</p>}</div>;
};

export default UserProfile;

Step 3: Compose Components Together

import React from "react";
import UserProfile from "./UserProfile";
import { useUserData } from "./useUserData";

const UserProfileContainer: React.FC = () => {
  const { user, loading } = useUserData();
  return <UserProfile user={user} loading={loading} />;
};

export default UserProfileContainer;

Benefits of This Refactor

UserProfile is now independent of the data-fetching logic and can be used anywhere.
useUserData can be easily mocked in tests.

Common Mistakes to Avoid

Over-abstraction: Don’t create unnecessary interfaces/hooks unless they add real flexibility.
Still relying on direct API calls in UI components: Always separate concerns properly.
Skipping dependency injection in favor of global state everywhere: Context or Redux can help, but they should not be the default choice for everything.
Not considering reusability: Ask yourself if this component needed different data tomorrow, would it still work?

When to Apply DIP in Real Projects

Reusable UI Components: Components that need different data sources (e.g., UserProfile, ProductCard).
Testing Flexibility: When API responses or logic should be mocked easily.
Scalable Applications: If the project is growing, keeping UI and logic separate prevents future headaches.

Conclusion

The Dependency Inversion Principle (DIP) is all about making React components more maintainable, testable, and reusable. By moving business logic into hooks/services and injecting dependencies via props, we can keep our components lean and flexible.

Key Takeaways:

Avoid direct API calls inside components.
Use hooks or services for business logic.
Pass dependencies via props instead of hardcoding them.
Keep UI components focused on rendering, not logic.

Applying DIP might seem like extra work at first, but it pays off in the long run with better scalability and maintainability. Start small and apply it where it makes sense!

And with that, our SOLID series comes to an end—but there's much more to come! Stay tuned for more blogs.

If you found this helpful, share it with your team and improve your React codebase together! 🚀

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

Interface Segregation Principle (ISP) in React Development

Chhakuli Zingare — Thu, 20 Feb 2025 03:30:00 +0000

Welcome back to our SOLID principles in the React series! So far, we’ve covered:

✅ S: Single Responsibility Principle (SRP): Keep components focused.

✅ O: Open/Closed Principle (OCP): Make extensions easy, not modifications.

✅ L: Liskov Substitution Principle (LSP): Keep components interchangeable without breaking behavior.

Today, we’re diving into the Interface Segregation Principle (ISP)—a principle that helps keep our React components and interfaces lean, modular, and easier to maintain.

If SOLID principles were a gym for your code, ISP would be the exercise that trims down bloated, unfocused interfaces. Let’s break it down and then apply it to real-world React examples.

What is the Interface Segregation Principle (ISP)?

ISP is one of the five SOLID principles from object-oriented programming (OOP), but it’s just as relevant in React.

In simple terms:

“A class (or component) should not be forced to depend on interfaces it does not use.”

In React terms:

A component should only receive the props it actually needs.
Interfaces (types) should be small and specific, not overloaded with unrelated properties.
Hooks should return only the data relevant to their purpose.

If an interface has too many properties, components will be bloated, harder to reuse, and difficult to maintain.

In simple terms, ISP states that an interface should only have the methods and properties relevant to a specific use case. In React, this means breaking down component props and interfaces into smaller, focused ones. This improves maintainability, reusability, and readability.

Why Should React Developers Care?

Before we dive into code, let's talk about why this matters in real-world React development:

Easier Testing: When components have fewer responsibilities, they're much easier to test. You don't have to mock a bunch of unused props just to test one feature.
Better Reusability: Smaller, focused components are like LEGO blocks - you can mix and match them in different ways to build different features.
Simpler Maintenance: When something breaks, you know exactly where to look. Plus, changing one component is less likely to cause unexpected issues elsewhere.
Improved Performance: React can better optimize renders when components only depend on the props they actually use.

Why Does ISP Matter in React?

Violating ISP often leads to these common issues:

Bloated Components: Components receive too many props, making them complex and hard to manage.
Unnecessary Re-renders: A component re-renders even when only an unrelated prop changes.
Poor Reusability: A component tied to a massive interface becomes difficult to reuse elsewhere.

The Problem: A Monolithic Component

Let's look at a common mistake: creating a component that tries to do too much.

Here's an example of a user profile card that violates ISP:

interface UserProfileProps {
  // Basic user info
  userId: string;
  name: string;
  email: string;
  avatar: string;

  // Social media links
  twitter?: string;
  linkedin?: string;
  github?: string;

  // Activity stats
  postCount: number;
  commentCount: number;
  likeCount: number;

  // Admin features
  isAdmin: boolean;
  canDelete: boolean;
  canEdit: boolean;

  // Event handlers
  onEdit: () => void;
  onDelete: () => void;
  onFollow: () => void;
  onMessage: () => void;
}

const UserProfile: React.FC<UserProfileProps> = ({
  userId,
  name,
  email,
  avatar,
  twitter,
  linkedin,
  github,
  postCount,
  commentCount,
  likeCount,
  isAdmin,
  canDelete,
  canEdit,
  onEdit,
  onDelete,
  onFollow,
  onMessage
}) => {
  return (
    <div className="user-profile">
      <div className="user-basic-info">
        <img src={avatar} alt={name} />
        <h2>{name}</h2>
        <p>{email}</p>
      </div>

      <div className="social-links">
        {twitter && <a href={twitter}>Twitter</a>}
        {linkedin && <a href={linkedin}>LinkedIn</a>}
        {github && <a href={github}>GitHub</a>}
      </div>

      <div className="activity-stats">
        <span>Posts: {postCount}</span>
        <span>Comments: {commentCount}</span>
        <span>Likes: {likeCount}</span>
      </div>

      <div className="actions">
        <button onClick={onFollow}>Follow</button>
        <button onClick={onMessage}>Message</button>
        {isAdmin && canEdit && <button onClick={onEdit}>Edit</button>}
        {isAdmin && canDelete && <button onClick={onDelete}>Delete</button>}
      </div>
    </div>
  );
};

See the problem? This component is doing way too much:

Handling basic user information
Managing social media links
Displaying activity statistics
Dealing with admin functionality
Managing various user interactions

Applying ISP: Breaking It Down

Let's refactor this component using ISP. We'll break it into smaller, focused interfaces and components:

// Basic user information interface
interface UserBasicInfoProps {
  name: string;
  email: string;
  avatar: string;
}

const UserBasicInfo: React.FC<UserBasicInfoProps> = ({ name, email, avatar }) => (
  <div className="user-basic-info">
    <img src={avatar} alt={name} />
    <h2>{name}</h2>
    <p>{email}</p>
  </div>
);

// Social links interface
interface SocialLinksProps {
  twitter?: string;
  linkedin?: string;
  github?: string;
}

const SocialLinks: React.FC<SocialLinksProps> = ({ twitter, linkedin, github }) => (
  <div className="social-links">
    {twitter && <a href={twitter}>Twitter</a>}
    {linkedin && <a href={linkedin}>LinkedIn</a>}
    {github && <a href={github}>GitHub</a>}
  </div>
);

// Activity stats interface
interface ActivityStatsProps {
  postCount: number;
  commentCount: number;
  likeCount: number;
}

const ActivityStats: React.FC<ActivityStatsProps> = ({ 
  postCount, 
  commentCount, 
  likeCount 
}) => (
  <div className="activity-stats">
    <span>Posts: {postCount}</span>
    <span>Comments: {commentCount}</span>
    <span>Likes: {likeCount}</span>
  </div>
);

// Admin actions interface
interface AdminActionsProps {
  isAdmin: boolean;
  canEdit: boolean;
  canDelete: boolean;
  onEdit: () => void;
  onDelete: () => void;
}

const AdminActions: React.FC<AdminActionsProps> = ({
  isAdmin,
  canEdit,
  canDelete,
  onEdit,
  onDelete
}) => {
  if (!isAdmin) return null;

  return (
    <div className="admin-actions">
      {canEdit && <button onClick={onEdit}>Edit</button>}
      {canDelete && <button onClick={onDelete}>Delete</button>}
    </div>
  );
};

// User interaction interface
interface UserInteractionProps {
  onFollow: () => void;
  onMessage: () => void;
}

const UserInteractions: React.FC<UserInteractionProps> = ({
  onFollow,
  onMessage
}) => (
  <div className="user-interactions">
    <button onClick={onFollow}>Follow</button>
    <button onClick={onMessage}>Message</button>
  </div>
);

// Main UserProfile component now composing smaller components
interface UserProfileProps {
  user: UserBasicInfoProps;
  social: SocialLinksProps;
  stats: ActivityStatsProps;
  admin: AdminActionsProps;
  interactions: UserInteractionProps;
}

const UserProfile: React.FC<UserProfileProps> = ({
  user,
  social,
  stats,
  admin,
  interactions
}) => {
  return (
    <div className="user-profile">
      <UserBasicInfo {...user} />
      <SocialLinks {...social} />
      <ActivityStats {...stats} />
      <AdminActions {...admin} />
      <UserInteractions {...interactions} />
    </div>
  );
};

What Changed and Why It's Better

Let's break down the improvements:

Focused Components: Each component now has a single responsibility:

UserBasicInfo handles only basic user data
SocialLinks manages only social media links
ActivityStats displays only user statistics
AdminActions handles admin-specific functionality
UserInteractions manages user engagement actions

Flexible Composition: Now you can easily:

Use components independently where needed
Test each component in isolation
Modify one aspect without touching others

Better Props Management: Each component receives only the props it needs, making it:

Easier to understand what each component requires
Simpler to maintain type safety
More efficient with React's rendering

Real-World Example: A Data Table Component

Here's a practical example of how ISP can help with a common React pattern data table:

// Instead of one massive table interface
interface DataTableProps<T> {
  data: T[];
  columns: Column[];
  sortable?: boolean;
  filterable?: boolean;
  pagination?: boolean;
  pageSize?: number;
  onSort?: (column: string) => void;
  onFilter?: (filters: Filter[]) => void;
  onPageChange?: (page: number) => void;
  loading?: boolean;
  error?: Error;
  selection?: boolean;
  onSelect?: (items: T[]) => void;
  // ... many more props
}

// Break it down using ISP
interface TableDataProps<T> {
  data: T[];
  columns: Column[];
}

interface SortableProps {
  sortable?: boolean;
  onSort?: (column: string) => void;
}

interface FilterableProps {
  filterable?: boolean;
  onFilter?: (filters: Filter[]) => void;
}

interface PaginationProps {
  pagination?: boolean;
  pageSize?: number;
  onPageChange?: (page: number) => void;
}

interface TableStateProps {
  loading?: boolean;
  error?: Error;
}

interface SelectionProps<T> {
  selection?: boolean;
  onSelect?: (items: T[]) => void;
}

// Compose them using higher-order components or hooks
const DataTable = <T extends unknown>(props: TableDataProps<T>) => {
  // Base table implementation
};

const withSorting = <T extends unknown>(
  WrappedComponent: React.ComponentType<TableDataProps<T>>
) => {
  return (props: TableDataProps<T> & SortableProps) => {
    // Add sorting functionality
    return <WrappedComponent {...props} />;
  };
};

const withFiltering = <T extends unknown>(
  WrappedComponent: React.ComponentType<TableDataProps<T>>
) => {
  return (props: TableDataProps<T> & FilterableProps) => {
    // Add filtering functionality
    return <WrappedComponent {...props} />;
  };
};

// Usage
const SortableTable = withSorting(DataTable);
const FilterableTable = withFiltering(DataTable);
const FullFeaturedTable = withFiltering(withSorting(DataTable));

Common Mistakes to Avoid

While applying ISP, watch out for these pitfalls:

1. Over-segregation

// Too granular!
interface NameProps { name: string; }
interface EmailProps { email: string; }
interface AvatarProps { avatar: string; }

// Better balance
interface UserBasicInfoProps {
  name: string;
  email: string;
  avatar: string;
}

2. Prop Drilling

// Passing admin props through multiple layers
const App = () => (
  <UserProfile 
    adminProps={adminProps} 
    userProps={userProps} 
  />
);

// Better approach: Use Context or composition
const AdminContext = React.createContext<AdminProps | null>(null);

const App = () => (
  <AdminContext.Provider value={adminProps}>
    <UserProfile userProps={userProps} />
  </AdminContext.Provider>
);

3. Premature Abstraction

// Creating interfaces for everything
interface ButtonProps {
  onClick: () => void;
  children: React.ReactNode;
}

// Use built-in types when they suffice
const Button: React.FC<React.ButtonHTMLAttributes<HTMLButtonElement>> = (props) => (
  <button {...props} />
);

When to Apply ISP in Real Projects

ISP isn't always necessary. Here's when you should consider it:

Good Times to Apply ISP:

When components have multiple distinct responsibilities
When different parts of a component change for different reasons
When you find yourself passing many unused props through components
When testing becomes complicated due to component complexity

Maybe Skip ISP When:

Working with simple, focused components
The overhead of separation doesn't provide clear benefits
Components are unlikely to change or be reused

Key Takeaways

Start Simple: Begin with cohesive components and split them only when needed.
Follow Dependencies: Let natural dependencies guide your interface boundaries.
Think Reusability: Design interfaces with reuse in mind, but don't over-abstract.
Consider Testing: If testing becomes complex, it might be time to split interfaces.
Balance Trade-offs: Sometimes a slightly larger interface is better than extreme segregation.

Final Thoughts: Keep Your Interfaces Lean & Focused

The Interface Segregation Principle (ISP) is all about clarity, performance, and maintainability in React.

Avoid bloated interfaces that force components to accept unnecessary props.
Split interfaces wisely to make components easier to reuse.
Improve performance by preventing unnecessary re-renders.

This is not just about following rules blindly; it's about writing components that are easier to understand, test, and maintain. By breaking down large interfaces into focused, purpose-specific ones, we create more flexible and maintainable React applications.

Remember: The goal isn't to have the smallest possible interfaces, but to have interfaces that serve a clear, single purpose. Start with reasonable component sizes and refactor when you see clear benefits from separation.

Keep practicing these patterns, and you'll develop an intuition for when and how to apply ISP in your React projects.

This wraps up our “I” from our SOLID principles in the React series! If you’ve learned something new, share this post with your fellow React developers.

Next, we’ll tackle the Dependency Inversion Principle (DIP)

Until then, keep your React code SOLID, and let’s build something amazing together.

Stay tuned, and happy coding!

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

Liskov Substitution Principle in React: Building Reliable Component Hierarchies

Chhakuli Zingare — Fri, 14 Feb 2025 03:30:00 +0000

Welcome back to our SOLID principles series!

If you’ve been following along, we’ve already covered:

✅ S: Single Responsibility Principle (SRP): Keep components focused.

✅ O: Open/Closed Principle (OCP): Make extensions easy, not modifications.

Today, we’re going to talk about L—the Liskov Substitution Principle (LSP), a principle that might sound technical but boils down to one simple idea: keeping things consistent and predictable.

LSP is like an unwritten contract between your components, functions, and hooks. It ensures that you don't break existing behavior when you extend or modify something.

If you’re wondering, "Why should I care?" imagine this:

You build a button component that works everywhere in your app.
Later, you extend it to create a special button—but instead of extending behavior, it removes some functionality (like onClick).
Now, unexpected errors pop up anywhere this new button is used.

That’s an LSP violation in action. Small changes shouldn’t break what’s already working in your web app.

Why Should React Developers Care?

Before we dive into code, here's why LSP matters in your day-to-day React work:

Predictable Components: When components follow LSP, they behave predictably when extended or substituted.
Safer Refactoring: You can confidently refactor and extend components without unexpected side effects.
Type Safety: TypeScript can help enforce LSP, catching potential issues before runtime.

So today, let’s have a look into LSP with real-world examples in React—not just theory but actual problems you’ll run into as a developer and how to fix them the right way.

What Is the Liskov Substitution Principle (LSP)?

LSP is part of the SOLID principles—a set of best practices for writing clean, scalable, and maintainable code.

In simple terms:

A child class (or component) should be able to replace its parent class without breaking the application.

In React terms, this means:

A component or hook should respect the contract of the parent component or function it extends from.
If a function is expecting a base component, you should be able to pass a derived component without issues.
Subclassed or extended components should not remove essential behavior.

If that’s still too abstract, let’s make it very real with a common mistake we often see in frontend development.

In code, this happens when a subclass or extended component fails to replace its parent without breaking expectations. We will see how this plays out in React.

Why is LSP important in React?

When you follow LSP in React, you unlock several benefits:

Predictability: Developers can confidently reuse or extend components without surprises.
Reusability: Extended components are useful across different parts of your app.
Maintainability: Fewer bugs and cleaner relationships between components.

Violating LSP, on the other hand, leads to confusion, unexpected behavior, and headaches when debugging or testing.

LSP in Everyday React Development

Let’s make this real with practical examples. We’ll explore how to apply LSP in common React scenarios and highlight what happens when it’s violated.

1. Extending Components Without Breaking Behavior

Broken Example: A Button That Breaks Expectations

Imagine we have a simple Button component:

type ButtonProps = {
  label: string;
  onClick: () => void;
};

export const Button = ({ label, onClick }: ButtonProps) => {
  return (
    <button onClick={onClick} className="px-4 py-2 bg-blue-500 text-white">
      {label}
    </button>
  );
};

Later, we decide we need a special button that prevents spam clicking.

A developer tries to solve this by creating a new DebouncedButton:

import { useState } from "react";

export const DebouncedButton = ({ label, onClick }: ButtonProps) => {
  const [disabled, setDisabled] = useState(false);

  const handleClick = () => {
    if (disabled) return;
    setDisabled(true);
    setTimeout(() => setDisabled(false), 3000); // 3-second delay
    onClick();
  };

  return (
    <button onClick={handleClick} disabled={disabled} className="px-4 py-2 bg-green-500 text-white">
      {label}
    </button>
  );
};

Looks harmless, right? Wrong.

Why is this an LSP violation?

Button originally allowed immediate clicks, but now DebouncedButton delays execution.
Code that expected immediate action will now behave differently, breaking user expectations.
If someone replaces <Button> with <DebouncedButton>, they could introduce unexpected UX issues.

Fix: Instead of Changing Behavior, Extend It with Props

A better approach is to modify the existing Button and allow debouncing as an optional feature:

import { useState } from "react";

type ButtonProps = {
  label: string;
  onClick: () => void;
  debounce?: boolean;
};

export const Button = ({ label, onClick, debounce = false }: ButtonProps) => {
  const [disabled, setDisabled] = useState(false);

  const handleClick = () => {
    if (debounce) {
      if (disabled) return;
      setDisabled(true);
      setTimeout(() => setDisabled(false), 3000); // 3-second delay
    }
    onClick();
  };

  return (
    <button onClick={handleClick} disabled={disabled} className="px-4 py-2 bg-blue-500 text-white">
      {label}
    </button>
  );
};

Now, we extend behavior without breaking existing usage:

<Button label="Click Me" onClick={() => console.log("Clicked!")} />
<Button label="Debounced Click" onClick={() => console.log("Clicked!")} debounce />

Why is this better?

The component can still be used normally without debouncing.
We extend behavior instead of changing it.
The Button contract remains intact.

2. Extending Hooks Without Breaking Data Contracts

Custom hooks in React are another area where LSP can easily be violated. Let’s say you create a useFetchData hook to fetch data from an API, and you want to extend it for fetching users.

Broken Example:

// Base Hook
const useFetchData = (url: string) => {
  const [data, setData] = useState(null);

 useEffect(() => {
    fetch(url)
      .then((res) => res.json())
      .then((data) => setData(data));
  }, [url]);

  return data;
};

// Extended Hook with Inconsistent Data Structure
const useFetchUsers = (url: string) => {
  const data = useFetchData(url);
  return { users: data, error: 'Feature not implemented' }; // Unexpected structure
};

The useFetchUsers hook violates LSP because it changes the return type, making it incompatible with components expecting the original hook's structure.

Fixing the Hook:

const useFetchUsers = (url: string) => {
  const data = useFetchData(url);
  return data ? { users: data } : null; // Consistent structure
};

By ensuring the return type matches expectations, you make useFetchUsers a proper substitute for useFetchData.

Common LSP Violations in React

Strengthening Preconditions

// Bad: Strengthening preconditions
interface BaseProps {
  data?: string[];
}

interface ExtendedProps extends BaseProps {
  data: string[]; // Making optional prop required
}

// Good: Maintaining preconditions
interface ExtendedProps extends BaseProps {
  onDataLoad?: () => void; // Adding optional features
}

Weakening Postconditions

// Bad: Weakening return type
interface BaseProps {
  getValue: () => string;
}

interface ExtendedProps extends BaseProps {
  getValue: () => string | null; // Breaking LSP by possibly returning null
}

// Good: Maintaining return type consistency
interface ExtendedProps extends BaseProps {
  getValue: () => string;
  getValueOrNull?: () => string | null; // Add new method instead
}

Breaking Behavioral Contracts

// Bad: Breaking expected behavior
const BaseButton: React.FC<ButtonProps> = ({ onClick }) => (
  <button onClick={onClick}>Click Me</button>
);

const ExtendedButton: React.FC<ButtonProps> = ({ onClick }) => (
  <button 
    onClick={(e) => {
      e.preventDefault(); // Breaking expected behavior
      onClick();
    }}
  >
    Click Me
  </button>
);

// Good: Maintaining behavioral contract
const ExtendedButton: React.FC<ButtonProps> = ({ onClick }) => (
  <button onClick={onClick} className="extended">
    Click Me
  </button>
);

How to Avoid LSP Violations in Your Project?

If you’re extending a component, don’t remove expected functionality—just add optional behaviors.
If you modify API responses, make sure they maintain backward compatibility.
Favor props over creating new components if the change is just a small behavior tweak.

By following LSP, your code will be:

1. Predictable – No unexpected side effects.

2. Scalable – New features won’t break old ones.

3. Easier to maintain – Less refactoring, fewer bugs.

Practical Tips for Following LSP in React

Use TypeScript's extends Wisely

// Base props for all form fields
interface FormFieldBase {
  name: string;
  label?: string;
  error?: string;
}

// Extend only when maintaining substitutability
interface TextFieldProps extends FormFieldBase {
  type?: 'text' | 'password' | 'email';
}

interface NumberFieldProps extends FormFieldBase {
  min?: number;
  max?: number;
}

Favor Composition Over Inheritance

// Instead of inheritance, use composition
interface ValidationProps {
  validate?: (value: string) => string | undefined;
}

interface StyleProps {
  variant?: 'outline' | 'filled';
  size?: 'small' | 'medium' | 'large';
}

// Compose interfaces for different needs
type CustomInputProps = FormFieldBase & ValidationProps & StyleProps;

Use Default Props Carefully

const CustomInput: React.FC<CustomInputProps> = ({
  name,
  label,
  error,
  validate = (value) => undefined,
  variant = 'outline',
  size = 'medium'
}) => {
  // Implementation
};

Final Thoughts: Building Predictable and Scalable React Apps

The Liskov Substitution Principle is all about predictability. By ensuring components and hooks respect the contracts they inherit, you create a codebase that’s easier to understand, maintain, and scale.

LSP isn’t just a theoretical principle—it saves you from debugging nightmares.

This is the third part of our SOLID Principles in React series. Next, we’ll tackle the Interface Segregation Principle (ISP)—a principle that will help you design leaner, more efficient components and interfaces.

Until then, keep your React code SOLID, and let’s build something amazing together.

Stay tuned, and happy coding! 🚀

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

Open/Closed Principle: Writing Scalable Code in React

Chhakuli Zingare — Fri, 07 Feb 2025 03:16:09 +0000

Welcome back to our journey through the SOLID principles! In our last blog, we talked about the Single Responsibility Principle (SRP) and how it helps us write clean, maintainable code. If you missed it, go check it out first—it’s the foundation for everything else we’re discussing in this series.

Today, we’re diving into the O - Open/Closed Principle (OCP), an essential pillar of software design that ensures your code is scalable and flexible while minimizing regressions.

If you’ve ever worked on a React project and found yourself modifying existing components over and over again to add new features, you’re probably violating this principle. But don’t worry—I’ll walk you through practical, real-world examples that make this concept easy to understand and apply.

By the end of this post, you’ll not only grasp the essence of OCP but also be able to write better, more extensible React components. Ready? Let’s get started!

What is the Open/Closed Principle (OCP)?

The Open/Closed Principle, coined by Bertrand Meyer, is defined as:

A software entity (class, module, function, etc.) should be open for extension but closed for modification.

In simpler terms:

• Open for extension: You should be able to add new functionality to your code without changing its existing implementation.

• Closed for modification: Existing code should remain untouched to avoid introducing bugs or breaking existing features.

The principle encourages developers to build modular and flexible systems by abstracting and encapsulating logic, reducing the risk of regressions when requirements evolve.

Why is OCP Important?

Failing to adhere to OCP often results in tightly coupled code that becomes increasingly hard to maintain as your application grows. Some of the key benefits of applying OCP include:

1. Scalability: Adding new features without disrupting existing code makes your application more adaptable to change.

2. Stability: Existing functionality remains untouched, reducing the risk of introducing bugs.

3. Testability: Isolated extensions are easier to test.

4. Collaboration: Different developers can work on extensions without stepping on each other’s toes.

Now that we understand the importance of OCP, let’s see how to implement it in React.

OCP in React: Practical Examples

In React, OCP is all about designing extensible components, hooks, and modules without modifying their core logic. Let’s examine some scenarios in which this principle can be applied.

1. Extending UI Components with Props and Composition

One of React’s core strengths is composition, which aligns perfectly with OCP. Instead of hardcoding logic into components, use props and composition to make them extensible.

Problem: A button component that needs different styles and behaviors for various use cases.

// Not OCP-friendly: Hardcoding styles and logic

const Button = ({ type }: { type: string }) => {

  if (type === 'primary') {
    return <button className="bg-blue-500 text-white">Primary Button</button>;
  }

  if (type === 'secondary') {
    return <button className="bg-gray-500 text-black">Secondary Button</button>;
  }

  return <button>Default Button</button>;
};

This implementation violates OCP because adding new button types requires modifying the existing component.

Solution: Use props and composition to make the component extensible.

// OCP-friendly: Open for extension via props
interface ButtonProps {
  children: React.ReactNode;
  className?: string;
  onClick?: () => void;
}

const Button: React.FC<ButtonProps> = ({ children, className, onClick }) => {
  return (
    <button className={`px-4 py-2 rounded ${className}`} onClick={onClick}>
      {children}
    </button>
  );
};

// Usage examples
<Button className="bg-blue-500 text-white">Primary Button</Button>;
<Button className="bg-gray-500 text-black">Secondary Button</Button>;
<Button className="bg-green-500 text-white">Success Button</Button>;

Here, the Button component is closed for modification but is open for extension by passing new styles or children as props.

2. Implementing Strategy Pattern with Custom Hooks

React hooks provide a powerful way to abstract logic and make it reusable. By applying the strategy pattern, you can extend functionality without modifying the core hook.

Problem: A hook that fetches data from an API but requires different URLs for various endpoints.

// Not OCP-friendly: Hardcoding the endpoint
const useFetchData = () => {
  const [data, setData] = React.useState(null);

  useEffect(() => {
    fetch('/api/users')
      .then((res) => res.json())
      .then((data) => setData(data));
  }, []);

  return data;
};

This violates OCP because the endpoint is hardcoded, making it impossible to reuse the hook for different APIs.

Solution: Accept the endpoint as a parameter to extend the hook’s functionality.

// OCP-friendly: Open for extension via parameters
const useFetchData = (endpoint: string) => {
 const [data, setData] = React.useState(null);

 useEffect(() => {
    fetch(endpoint)
      .then((res) => res.json())
      .then((data) => setData(data));
  }, [endpoint]);

  return data;
};

// Usage examples
const users = useFetchData('/api/users');
const posts = useFetchData('/api/posts');

Here, the hook is extensible to fetch data from any endpoint without modifying its internal implementation.

3. Extending Configurations with Factory Functions

Another practical example of OCP is using factory functions to dynamically create configurations or components.

Problem: You have a chart component that needs different configurations for bar charts, pie charts, and line charts.

// Not OCP-friendly: Hardcoding configurations
const Chart = ({ type }: { type: string }) => {
  if (type === 'bar') {
    return <BarChart data={data} />;
  }

  if (type === 'pie') {
    return <PieChart data={data} />;
  }

  return null;
};

Solution: Use a factory function to generate configurations dynamically.

// OCP-friendly: Open for extension with factory functions
const createChartConfig = (type: string) => {
  switch (type) {
    case 'bar':
      return { type: 'bar', options: { ... } };

    case 'pie':
      return { type: 'pie', options: { ... } };

    default:
      throw new Error('Unsupported chart type');
  }
};

const Chart = ({ type }: { type: string }) => {
  const config = createChartConfig(type);

  return <ChartComponent config={config} />;
};

This approach allows you to add new chart types without altering the existing logic.

Common Mistakes When Applying OCP

1. Over-Engineering: Adding abstractions where they’re not needed can complicate the code unnecessarily.

2. Tight Coupling: Relying on concrete implementations instead of abstractions.

3. Violating SRP: Trying to handle too many extensions in a single module. Always adhere to SRP when implementing OCP.

Best Practices for OCP in React

1. Use Composition: Favor composition over inheritance to extend components.

2. Abstract Logic: Use hooks and utility functions to encapsulate reusable logic.

3. Leverage TypeScript: Use interfaces and generics to define extensible types.

4. Test Extensions: Ensure your extensions don’t inadvertently break existing functionality.

Conclusion: Embrace Extensibility Without Breaking Stability

The Open/Closed Principle is a powerful design guideline that helps you build flexible, maintainable, and scalable React applications. By designing components, hooks, and modules that are open for extension but closed for modification, you reduce the risk of breaking existing functionality while keeping your codebase adaptable to future requirements.

This blog is part of our series on the SOLID principles. In the next instalment, we’ll tackle the Liskov Substitution Principle (L) and explore how to write substitutable components for better reusability and consistency.

Stay tuned, and happy coding! 🚀

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

Single Responsibility Principle in React Development

Chhakuli Zingare — Mon, 03 Feb 2025 04:30:00 +0000

Introduction: The First Step in SOLID Principles

When building scalable and maintainable software, adopting the SOLID principles is like laying the foundation for a robust structure. These principles guide developers toward creating clean, modular, and reusable codebases.

The first letter in SOLID stands for the Single Responsibility Principle (SRP)—the topic we’ll explore in this blog. As we dive into this, remember that this is just the beginning of a series where we’ll cover all five principles. You can think of it as a step-by-step guide to mastering clean code design.

Understanding Complexity in Modern Web Development

React has emerged as a powerful tool for building interactive user interfaces. However, with great power comes great responsibility—literally. As applications grow in complexity, developers face an increasingly challenging task: creating code that is not just functional, but maintainable, scalable, and easy to understand.

If you’ve been working with React (or programming in general), chances are you’ve heard the phrase Single Responsibility Principle (SRP) thrown around. It sounds fancy, but don’t let that intimidate you! At its core, SRP is a straightforward and incredibly powerful idea that can make your code cleaner, easier to maintain, and a joy to work with. Let’s break it down step-by-step.

What is the Single Responsibility Principle?

At its core, the Single Responsibility Principle is a design philosophy that advocates for creating components with a singular, well-defined purpose.

The Philosophical Underpinnings

The Single Responsibility Principle is one of the five principles in SOLID design, a set of guidelines for writing maintainable and scalable code. It states:

“A module, class, or function should have one and only one reason to change.”

Borrowed from object-oriented programming principles, SRP suggests that a component should have one reason to change. This might sound simple, but in practice, it requires careful thought and deliberate design.

In simpler terms, each piece of code (like a component in React) should focus on doing one thing well. It should have a single job or responsibility. If it’s responsible for more than one thing, you’re risking a codebase that becomes messy, hard to test, and even harder to extend as requirements grow.

Think of SRP as decluttering your kitchen. Instead of piling all your utensils, pots, and groceries into one giant drawer, you use cabinets and compartments to keep things organized. Each drawer has a specific purpose, so you can easily find what you need without rummaging through chaos. Similarly, in code, keeping responsibilities separate makes it easier to debug, maintain, and extend.

The Cost of Complexity: Why SRP Matters

Let’s take a moment to understand why SRP is more than just a “good-to-have” principle:

1. Improves Code Quality

When each component or function has a single responsibility, your code becomes predictable. This predictability reduces bugs and makes your code easier to understand at a glance.

2. Improved Code Readability

When components have a clear, singular focus, they become self-documenting. A new developer can quickly understand the purpose and functionality of each component without diving deep into its implementation.

3. Enhances Maintainability

As your application grows, changes will inevitably happen. Code that adheres to SRP is easier to update because the changes are isolated. If you only need to tweak the button’s style, you won’t accidentally break unrelated logic.

4. Increased Reusability

Focused components become like building blocks—they can be easily combined, moved, and reused across different parts of your application or even in different projects.

Applying SRP in React: Breaking It Down

React’s component-based architecture is perfectly suited for SRP. By default, React encourages you to break your UI into reusable, focused components. But even with this architecture, it’s easy to fall into the trap of overloading components with too many responsibilities. Let’s look at how we can avoid this and truly embrace SRP.

1. Start with a Big Component

Let’s begin with an example of a “God component”—a component that does too much.

Imagine you have a UserProfile component that does the following:

• Renders user information like name, email, and avatar.

• Handles user authentication (e.g., login/logout).

• Fetches data about the user’s activity and displays it.

This violates SRP because it combines UI rendering with logic related to authentication and fetching data. Let’s take a look at the code:

import { useState, useEffect } from "react";

const UserProfile = () => {
  const [user, setUser] = useState(null);
  const [isAuthenticated, setIsAuthenticated] = useState(false);

  useEffect(() => {
    // Mock user authentication logic
    setIsAuthenticated(true);
    setUser({
      name: "John Doe",
      email: "john@example.com",
      avatarUrl: "/avatar.jpg",
    });
  }, []);

  const handleLogout = () => {
    setIsAuthenticated(false);
    setUser(null);
  };

  return (
    <div className="flex items-center p-4 bg-gray-200 rounded">
      <div className="flex-shrink-0">
        <img className="w-12 h-12 rounded-full" src={user?.avatarUrl} alt="Avatar" />
      </div>
      <div className="ml-4">
        <p className="text-lg font-semibold">{user?.name}</p>
        <p className="text-sm text-gray-500">{user?.email}</p>
        <button onClick={handleLogout} className="mt-2 text-red-500">
          Logout
        </button>
      </div>
    </div>
  );
};

export default UserProfile;

Problems with This Approach:

• Single Responsibility Violation: This component is doing too much—it handles rendering, authentication logic, and manages state.

• Hard to Extend: If you want to add new features (e.g., fetching more data about the user), it’ll be difficult because the component is already overloaded.

• Testing Complexity: Testing this component would require you to test authentication logic and UI rendering together.

2. Refactor into Smaller Components

Now, let’s refactor this into smaller, more focused components. We’ll break it into three parts:

1. UserInfo: Focuses only on displaying the user’s information.

2. AuthStatus: Handles authentication status and logout logic.

3. UserProfile: Combines both the UserInfo and AuthStatus components to build the profile UI.

UserInfo.tsx:

This component only focuses on rendering the user’s info.

interface UserInfoProps {
  name: string;
  email: string;
  avatarUrl: string;
}

const UserInfo: React.FC<UserInfoProps> = ({ name, email, avatarUrl }) => (
  <div className="flex items-center p-4 bg-gray-200 rounded">
    <div className="flex-shrink-0">
      <img className="w-12 h-12 rounded-full" src={avatarUrl} alt="Avatar" />
    </div>
    <div className="ml-4">
      <p className="text-lg font-semibold">{name}</p>
      <p className="text-sm text-gray-500">{email}</p>
    </div>
  </div>
);

export default UserInfo;

AuthStatus.tsx:

This component handles authentication and logout functionality.

interface AuthStatusProps {
  isAuthenticated: boolean;
  onLogout: () => void;
}

const AuthStatus: React.FC<AuthStatusProps> = ({ isAuthenticated, onLogout }) => {
  if (!isAuthenticated) return <p>Please log in to view your profile.</p>;

  return (
    <button onClick={onLogout} className="text-red-500">
      Logout
    </button>
  );
};

export default AuthStatus;

UserProfile.tsx:

Finally, we bring everything together in a container component, which handles fetching the user’s data.

import { useState, useEffect } from "react";
import UserInfo from "./UserInfo";
import AuthStatus from "./AuthStatus";

const UserProfile = () => {
  const [user, setUser] = useState<any>(null);
  const [isAuthenticated, setIsAuthenticated] = useState(false);

  useEffect(() => {
    // Mock user authentication logic
    setIsAuthenticated(true);
    setUser({
      name: "John Doe",
      email: "john@example.com",
      avatarUrl: "/avatar.jpg",
    });
  }, []);

  const handleLogout = () => {
    setIsAuthenticated(false);
    setUser(null);
  };

  return (
    <div className="max-w-sm mx-auto p-4 bg-white rounded shadow-lg">
      {user && <UserInfo name={user.name} email={user.email} avatarUrl={user.avatarUrl} />}
      <AuthStatus isAuthenticated={isAuthenticated} onLogout={handleLogout} />
    </div>
  );
};

export default UserProfile;

Why This Works:

Single Responsibility: Each component now has a clear and distinct responsibility

• UserInfo is responsible for displaying user details.

• AuthStatus handles authentication logic.

• UserProfile manages fetching data and combines the other two components.

If you ever need just the user info (without authentication), you can reuse the UserInfo component elsewhere. If you need just the logout button (without the user data), you can reuse the AuthStatus component.

Now each component is much smaller and easier to test. For example, testing UserInfo would involve only rendering the user’s data, while testing AuthStatus would focus on the login/logout logic.

Common Mistakes and How to Avoid Them

Even seasoned developers sometimes make the mistake of overloading components. Here are some common pitfalls to watch out for and tips on how to avoid them:

1. Combining UI and Business Logic

A component should not contain complex business logic or side effects unless it’s its primary responsibility (such as in container components). Avoid mixing UI rendering with heavy data manipulation or API calls.

• Tip: Use hooks for logic and side effects (like useEffect) and pass data into presentation components as props.

2. Not Extracting Reusable Components

When a component is doing too much, it’s easy to forget that parts of it may be reusable elsewhere.

• Tip: Look for opportunities to split a component into smaller, reusable pieces. If a section of your UI can stand alone (like a button, input field, or card), it’s often a good candidate for extraction.

Common Pitfalls and Best Practices

When to Split Components

Consider breaking a component when:

It handles more than two types of state
Render methods become complex
The component's logic spans more than 200-250 lines
You find yourself adding conditional rendering logic

Strategies for Maintaining SRP

Use Custom Hooks: Extract complex state and side-effect logic
Composition Over Inheritance: Build complex UIs by combining simple components
Keep Components Small and Focused
Practice Continuous Refactoring

Learning and Improvement

Mastering the Single Responsibility Principle is a journey. Start small:

Review existing components
Identify areas of mixed responsibility
Gradually refactor
Learn from each iteration

Conclusion: A Mindset, Not Just a Technique

The Single Responsibility Principle is more than a coding technique—it's a mindset of writing clean, intentional, and maintainable code. It requires continuous learning, practice, and a commitment to craftsmanship.

By embracing SRP, you're not just writing better React code. You're becoming a more thoughtful, strategic developer who understands that great software is built through careful, deliberate design.

Remember: Complex problems are solved not by adding more code, but by writing smarter, more focused code.

The Single Responsibility Principle is more than just a buzzword—it’s a practical strategy for improving your code quality, readability, and scalability. By breaking down your React components into smaller, more focused units, you make your application more maintainable, testable, and easier to extend. SRP doesn’t just apply to React; it’s a universal concept in software engineering that can make a world of difference in any codebase.

Here are the key takeaways:

• Keep components focused on doing one thing well.

• Extract reusable parts of the UI into smaller, simpler components.

• Test components independently to ensure your application is bug-free.

• Don’t let “God components” clutter your codebase—embrace SRP to keep things clean.

Next time you’re building a feature in React, ask yourself: Does this component have a single responsibility? If the answer is no, it’s time to refactor.

This blog is part of our series on the SOLID principles. In the next installment, we’ll dive into the Open-Closed Principle (O) and discuss how to design components that are open to extension but closed to modification—making your code more flexible and robust.

Stay tuned, and happy coding! 🚀

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

React Component Composition Design Pattern With Examples

Chhakuli Zingare — Mon, 27 Jan 2025 05:29:00 +0000

As a developers, we’re constantly looking for ways to make our applications more maintainable, scalable, and reusable. One of the most powerful patterns to help achieve this is the Composite Component Pattern. It allows us to break down large, complex UIs into small, focused components that can be easily combined to create more dynamic layouts.

In this post, I’ll walk you through everything you need to know about the Composite Component Pattern in React, including real-world use cases, in-depth examples, and the best practices you should follow to maximize its effectiveness.

What Is the Composite Component Pattern?

In simple terms, the Composite Component Pattern is all about building small, focused components and then combining them to make bigger, more complex components. Instead of having huge components that try to do everything, you break things down into pieces that are easier to manage and reuse.

Think of it like building a car. Instead of designing the entire car as a single piece, you make parts like wheels, the engine, the seats, etc., and then assemble them into a full car. This gives you the flexibility to swap out parts, upgrade them, or reuse them in different cars.

By following this pattern, we end up with a more modular and easier-to-manage codebase.

Why Is It Useful in React?

1. Reusability: In large applications, having reusable components is a lifesaver. Components like Button, InputField, Modal, etc., can be used across different parts of the app, saving us time and reducing code duplication.

2. Maintainability: Smaller components are easier to manage. If there’s a bug in one part of your UI, you can pinpoint it faster without sifting through hundreds of lines of code.

3. Scalability: As your application grows, composing components to add new features is much easier than trying to modify an already large, complicated component.

Real-World Scenarios and Use Cases

To truly understand the power of the Composite component Pattern, let’s see how to build a Blog Page using the Composite Component Pattern with Next.js, TypeScript, and Tailwind CSS. We’ll look at how to break down the blog UI into smaller pieces, and how these pieces can be composed to create a dynamic and flexible blog page.

Step 1: Setting Up the Components

Our blog page will be composed of the following components:

1. Header — A navigation bar at the top of the page.

2. PostCard — A card that displays a single blog post’s title, excerpt, and a “Read More” link.

3. Pagination — Controls for navigating through multiple pages of blog posts.

4. BlogPage — The main component that ties everything together.

Let’s start by setting up the components.

1. Header Component

This component will render a simple navigation bar.

import React from 'react';
import Link from 'next/link';

const Header: React.FC = () => {
  return (
    <header className="bg-gray-800 p-4">
      <nav className="max-w-4xl mx-auto flex justify-between text-white">
        <Link href="/" className="text-2xl font-bold">
          My Blog
        </Link>
        <div>
          <Link href="/" className="px-4">
            Home
          </Link>
          <Link href="/about" className="px-4">
            About
          </Link>
          <Link href="/contact" className="px-4">
            Contact
          </Link>
        </div>
      </nav>
    </header>
  );
};

export default Header;

The Header component is simple: it displays a navigation bar with links to different pages of the site.

2. PostCard Component

This component will display an individual blog post’s title, an excerpt, and a “Read More” link.

import React from 'react';
import Link from 'next/link';

interface PostCardProps {
  title: string;
  excerpt: string;
  id: string;
}

const PostCard: React.FC<PostCardProps> = ({ title, excerpt, id }) => {
  return (
    <div className="bg-white p-6 rounded-lg shadow-md mb-6">
      <h2 className="text-2xl font-bold mb-2">{title}</h2>
      <p className="text-gray-700 mb-4">{excerpt}</p>
      <Link href={`/post/${id}`} className="text-blue-500 hover:text-blue-700">
        Read More
      </Link>
    </div>
  );
};

export default PostCard;

Each PostCard will receive three props: title, excerpt, and id. The “Read More” link will redirect the user to a separate page where they can read the full post.

3. Pagination Component

This component handles the pagination controls for navigating through multiple blog posts.

import React from 'react';
import Link from 'next/link';

interface PaginationProps {
  currentPage: number;
  totalPages: number;
}

const Pagination: React.FC<PaginationProps> = ({ currentPage, totalPages }) => {
  return (
    <div className="flex justify-center mt-8">
      {currentPage > 1 && (
        <Link href={`/?page=${currentPage - 1}`} className="px-4 py-2 bg-blue-500 text-white rounded-md hover:bg-blue-600">
          Previous
        </Link>
      )}
      <span className="mx-4 text-xl">{currentPage} / {totalPages}</span>
      {currentPage < totalPages && (
        <Link href={`/?page=${currentPage + 1}`} className="px-4 py-2 bg-blue-500 text-white rounded-md hover:bg-blue-600">
          Next
        </Link>
      )}
    </div>
  );
};

export default Pagination;

The Pagination component displays the Previous and Next buttons and shows the current page number along with the total number of pages.

Step 2: Assembling the Blog Page

Now let’s assemble these components in the BlogPage component.

import React from 'react';
import Header from '../components/Header';
import PostCard from '../components/PostCard';
import Pagination from '../components/Pagination';

const BlogPage: React.FC = () => {
  // Sample data for posts
  const posts = [
    { id: '1', title: 'How to Learn React', excerpt: 'An easy guide to learning React in 2025.' },
    { id: '2', title: 'Mastering TypeScript', excerpt: 'A deep dive into the power of TypeScript.' },
    { id: '3', title: 'Building with Tailwind CSS', excerpt: 'Creating beautiful UIs with Tailwind CSS.' },
  ];

  const currentPage = 1; // Simulating the current page
  const totalPages = 3;  // Simulating the total number of pages

  return (
    <div>
      <Header />
      <main className="max-w-4xl mx-auto p-4">
        <h1 className="text-4xl font-bold mb-8 text-center">Welcome to My Blog</h1>
        {posts.map(post => (
          <PostCard key={post.id} title={post.title} excerpt={post.excerpt} id={post.id} />
        ))}
        <Pagination currentPage={currentPage} totalPages={totalPages} />
      </main>
    </div>
  );
};

export default BlogPage;

Here’s how we use the components:

• Header is rendered at the top.

• We map through the posts array and render a PostCard for each post.

• Pagination is included at the bottom of the page to navigate between pages.

Best Practices for the Composite Component Pattern

When using the Composite Component Pattern, it’s important to follow some best practices to ensure that your code remains clean, efficient, and scalable.

1. Single Responsibility Principle (SRP)

Each component should have a single responsibility. If you find yourself adding more than one responsibility to a component, it’s a sign that it needs to be broken down into smaller components.

For example, if a component handles both UI and logic, it might be better to split it into separate presentational and container components.

2. Keep Components Small and Focused

Aim to create smaller components that do one thing well. This makes them easier to reuse, test, and maintain.

• Bad: A UserProfile component that handles rendering the profile, updating the user data, and sending requests to the server.

• Good: Separate components like ProfileHeader, ProfileForm, and ProfileButton that each have a clear, focused responsibility.

3. Leverage Context API and Hooks

For components that need to share state, avoid prop drilling by using React’s Context API. This allows your components to access shared data without passing it through every level of the component tree.

Advanced Use Cases for the Composite Component Pattern

While the Composite Component Pattern works great for simple UIs, it can also be used to build complex, dynamic applications that require highly customizable layouts.

1. Reusable Dashboard Widgets

In a dashboard application, you might have multiple widgets (charts, graphs, data tables, etc.). Using the Composite Component Pattern, each widget can be its own independent component, and the dashboard itself can be composed dynamically by combining different widgets.

2. Customizable Modal Dialogs

If you need to create modals with varying content (like confirmation modals, alert modals, or forms), you can create a generic Modal component that accepts children, so it can be dynamically populated with different content.

Conclusion

The Composite Component Pattern allows us to build clean, maintainable, and scalable UIs by breaking down complex components into smaller, reusable building blocks. By composing these blocks together, we can create flexible and dynamic UIs with ease.

In this example, we demonstrated how to use this pattern to build a blog page in Next.js with TypeScript and Tailwind CSS. We showed how the Header, PostCard, and Pagination components were combined to create a fully functional blog page.

By following the Composite Component Pattern, you can:

• Improve reusability by creating smaller, more focused components.

• Keep your code clean and maintainable.

• Make your app scalable and easy to extend.

Feel free to experiment with this in your own applications and explore how you can make your UI more modular and flexible.

Call to Action

If you found this blog post informative and valuable, we encourage you to visit other blogs on our page for more development tips, tutorials, and best practices.

Remember, writing code with the design pattern like this is an essential component of successful software development, especially in team environments. By embracing the right practices, you can set your team up for long-term success and deliver high-quality software that meets the evolving needs of your users.

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

Looking back to move forward: lessons from life and code

Chhakuli Zingare — Mon, 30 Dec 2024 02:58:28 +0000

The First Project and Unexpected Lessons

Back in January and February, I was working on delivering my first real industry project at CreoWis. It was a big milestone for me, and honestly, a bit nerve-wracking too. Looking back, it wasn’t just about coding or technology. It taught me so much about myself.

The project came with its share of challenges. There were tight deadlines, tricky bugs, and moments where I felt stuck. But those struggles taught me patience and perseverance. One funny moment I still remember is how much patience it took to fix a single bug — it felt endless! But that’s exactly what I needed to learn.

The best part? At the end of the project, my company surprised me with a thoughtful gift and a note that said:

"Hey Chhakuli, this is for your excellent work on BMS. Keep rocking, girl! We are extremely proud to have you at CreoWis. Let's win #buildCreoWis from CreoWis."

I can’t explain how happy that made me. It felt like all my hard work was truly appreciated.

And then, February rolled around, and I was recognized as a star at work — yes, a star! I was awarded the “Sense of Accountability” trophy for February 2024. It was a digital trophy that made me smile from ear to ear, but more than that, it reminded me that hard work, patience, and taking ownership really do pay off.

Sharing Knowledge and Growing Together

At CreoWis, we believe in sharing knowledge with the community — I deeply value it. The goal isn’t just to grow as individuals but to help the entire developer community grow. So here I had the opportunity to share my experiences and what I had learned with others.

I got to contribute to this mission by writing blogs and publishing them on both the CreoWis website and Dev.to. It felt amazing to be able to share the lessons I was learning along the way. Some of the posts I wrote covered topics like mastering coding best practices, improving team productivity, and even diving deep into NextJS and data visualization.

On top of that, we also at CreoWis share “Tech Bytes” on our social media channels like LinkedIn and Twitter, Monday to Friday. These bite-sized tech pieces are a way to share quick insights, tools, and tips from our daily work. Each week, I write 2-3 tech bytes and trust me, these aren’t just random posts. They are little knowledge shots you can read every morning to kickstart your day.

Sharing knowledge is at the heart of growth — and the more we share, the more we all benefit.

AI Hackathon with Arnab: A Journey of Innovation

In July Arnab Chatterjee (My colleague at CreoWis) and I had the incredible opportunity to participate in the Hashnode "AI for Tomorrow" Hackathon, and we secured a spot in the Top 10 Special Category Prizes with our project, Codecompass.ai! 🚀

Codecompass.ai is an AI-powered tool we built to help development teams understand and navigate their codebases with ease. Whether it's onboarding new team members or breaking down complex code structures, this tool aims to make collaboration and productivity smoother than ever. It was such a rewarding experience to work on something that could truly make a difference in how teams work together.

Satvic Fest: A Journey of Inspiration and Growth

For the past four years, I’ve been following the Satvic Movement, and attending their Satvic Fest was always something I dreamed of. This year, I finally had the chance to go to Bangalore for the first time and experience it all in person.

First I attended a yoga session at the fest, something I’ve always enjoyed, and it was such a peaceful and rejuvenating experience. Afterwards, I attended a panel discussion where founders shared their stories, struggles, and the lessons they’ve learned along the way.

As someone who loves exploring products and learning about how founders work, it was an incredible opportunity to meet some of the founders behind organic products. I’ve always been curious about the journey of bringing natural products to the market, and this fest gave me the chance to connect with people who are doing just that.

One of the most enlightening moments for me came from the founder of Cosmix, who shared a powerful insight. She said that many investors often suggest adding more ingredients to products to increase profits. But she told that we should always come back to the core values we started with.

CreoConnect: Our First In-Person Meet

From December 6th to 8th, something truly special happened—our very first in-person meet at CreoWis, lovingly called #creoconnect. It was more than just a corporate event; it was a celebration of teamwork, achievements, and the amazing people who make up CreoWis.

For someone who’s been working remotely, meeting my colleagues face-to-face for the first time was an unforgettable experience. The energy in the room was electric, and the three days were packed with moments that I’ll treasure forever.

One of the highlights for me was receiving a trophy, a CreoWis t-shirt, and some gifts. But honestly, what I took home wasn’t just material things—it was the memories we created together. The laughter, the stories we shared, and the bond we built made me feel so much more connected to the team.

#creoconnect wasn’t just a meet-up; it was a reminder of why I love being part of CreoWis. It’s not just about work; it’s about the people, the shared vision, and the culture that makes this place feel like a second home.

If you’d like to see what it was like, check out some glimpses of #CreoConnect on CreoWis’ YouTube and Instagram. You’ll see the energy, the fun, and the spirit of what makes CreoWis truly unique.

This meet wasn’t just an event; it was a milestone, a reminder of how far we’ve come and the exciting road ahead. I couldn’t be prouder to be part of this journey!

A Touch of Festivity with #CreoSecretSanta

We ended the year on a festive note with our first-ever Secret Santa exchange, #CreoSecretSanta. This wasn’t just about gifts; it was about creating connections and spreading joy.

As the host of the event, I was thrilled to organize everything. We started by sending an email with a fun twist — a button that revealed the name of the child assigned to you. This interactive feature added excitement to the process. Based on the selections, we carefully chose thoughtful gifts for the children under 500 RS, making it an even more meaningful experience.

On December 26th, the big gift revelation happened, and it was such a fun moment to see everyone’s reactions! 😊

What made the experience even more special for me was my Secret Santa — my cofounder and our UX designer. He gave me exactly what I wanted.

#CreoSecretSanta wasn’t just a fun activity; it was a heartwarming way to end the year, strengthening our bonds as a team and spreading festive cheer.

This is my gift from my Santa Nirmal Kumar.

And a gift from me to my child Prachi Sahu.

Reflecting on 2024

As I look back on 2024, it feels like a year full of growth, learning, and amazing memories. From delivering my first project to sharing knowledge, building something innovative, and celebrating with my team, every moment made the year special.

I’ve learned that challenges help us grow, sharing knowledge makes us stronger, and being part of a supportive team is everything. Here’s to an unforgettable 2024 and all the exciting adventures ahead!

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

Building a React Text Comparison Tool - From POC to NPM Package

Chhakuli Zingare — Fri, 11 Oct 2024 02:04:11 +0000

Hey everyone! 👋 Chhakuli here. Today, I want to walk you through an exciting task I received at work: researching and building a text comparison tool. This tool’s job is to compare two pieces of text, highlight the differences, and present them in a visually intuitive way.

The need for this feature can arise in various contexts, such as document versioning, code reviews, or any application requiring a side-by-side comparison of text content. While it may sound straightforward, I quickly learned that building this feature comes with its own set of challenges.

In this post, I’ll share my research, the initial implementation I came up with, and how I transformed it into an NPM package. If you're ever tasked with something similar, I hope this will help you!

Understanding the Requirements

The initial brief seemed simple enough. Here’s what my tech lead outlined as the goals for the tool:

Side-by-side view: Show both original texts side by side (easy peasy, right?)
Combined version with highlights:

Common words should be shown in normal text.
Words present in the original but missing in the updated text should appear in red (as if removed).
Words added in the updated version should be shown in green (as if added).

At first glance, it might seem like a small task. But as I started thinking through the details, I realized there were quite a few considerations. For example:

Should we compare word-by-word or character-by-character?
How do we handle larger texts, where slight variations might occur throughout paragraphs?
Are there any existing packages that could streamline the process, or should we build a custom solution from scratch?

Exploring Available Solutions

My first step was researching what existing libraries or tools are available for text comparison. I came across several options:

diff-match-patch: Google’s open-source library for comparing text.
jsdiff: A lightweight JavaScript library designed for diffing text and objects.
diff2html: A visual diff tool for displaying changes between text or code.

Each of these libraries offers powerful capabilities, but I wanted to take a hands-on approach to better understand the logic behind text comparison. That led me to think: Why not build a custom implementation?

Building a Custom Implementation

If you're like me and love getting into the nitty-gritty, building a custom solution offers more control and a deeper understanding of the problem space. To start, I knew I wanted a word-by-word comparison, which is relatively simple with JavaScript's split() method.

Here's the initial implementation:

const compareTexts = (t1: string, t2: string) => {
  const words1 = t1.split(' ');
  const words2 = t2.split(' ');

  const result: JSX.Element[] = [];
  let i = 0;
  let j = 0;

  while (i < words1.length || j < words2.length) {
    const word1 = words1[i];
    const word2 = words2[j];

    if (word1 === word2) {
      // Both words are the same, add as common (black)
      result.push(<span key={`common-${i}`} className="text-black">{word1} </span>);
      i++;
      j++;
    } else {
      // Word exists in text1 but not in text2 (removed from text2)
      if (i < words1.length && (!words2.includes(word1) || word1 !== words2[j])) {
        result.push(<span key={`removed-${i}`} className="text-red-500">{word1} </span>);
        i++;
      }

      // Word exists in text2 but not in text1 (added in text2)
      if (j < words2.length && (!words1.includes(word2) || word2 !== words1[i])) {
        result.push(<span key={`added-${j}`} className="text-green-500">{word2} </span>);
        j++;
      }
    }
  }

  return result;
};

Let’s take a deeper dive into the logic. The function starts by breaking the two texts into words (using spaces as delimiters) and loops through both word arrays. For each word, the function checks if the word is present in both texts. If a word exists in one text but not the other, it is marked accordingly.

How It Works

Text Splitting: Both strings (t1 and t2) are split into arrays of words using .split(' ').
While Loop: The loop runs as long as there are words left to compare in either words1 or words2.
Word Comparison:
- If the words at the current index (i, j) match, they are added as common words with a black color.
- If a word is present in words1 but not in words2, it’s marked as removed (red).
- If a word is present in words2 but not in words1, it’s marked as added (green).

This function effectively highlights differences between the two pieces of text, which you’re rendering directly in your React component.

The Visual Representation

Once the comparison logic was set, the next task was to integrate it into a presentable UI. Using JSX and Tailwind CSS made this part relatively easy. Here’s how I structured the output:

return (
  <div className="p-4 bg-gray-100 rounded-lg shadow-md w-[60rem] ml-4 mt-4">
    <h2 className="text-xl font-bold mb-4 text-black">Text Difference Comparison</h2>
    <div className="grid grid-cols-2 gap-4">
      <div className="bg-white p-3 rounded">
        <h3 className="font-semibold mb-2 text-black">Output 1:</h3>
        <p className="text-black font-medium">{text1}</p>
      </div>
      <div className="bg-white p-3 rounded">
        <h3 className="font-semibold mb-2 text-black">Output 2:</h3>
        <p className="text-black font-medium">{text2}</p>
      </div>
    </div>
    <div className="mt-4 bg-white p-3 rounded">
      <h3 className="font-semibold mb-2 text-black">Difference:</h3>
      <p className="font-medium">{compareTexts(text1, text2)}</p>
    </div>
  </div>
);

Why Tailwind CSS Rocks

I used Tailwind CSS for styling, which made my life so much easier. It’s a utility-first CSS framework that lets you style elements right in your JSX, without needing to maintain separate style sheets. It’s perfect for quickly putting together components with a clean, modern look.

The Final Output of Initial Implementation

Here is your full component of the initial implementation.

import React from 'react';

const TextDiffComponent = () => {
  const text1 = "A beautiful day starts with a fresh cup of coffee and a clear mind to conquer the world";
  const text2 = "A productive morning begins with a strong cup of coffee and the determination to change the world";

  const compareTexts = (t1: string, t2: string) => {
    const words1 = t1.split(' ');
    const words2 = t2.split(' ');

    const result: JSX.Element[] = [];
    let i = 0;
    let j = 0;

    while (i < words1.length || j < words2.length) {
      const word1 = words1[i];
      const word2 = words2[j];

      if (word1 === word2) {
        // Both words are the same, add as common (black)
        result.push(<span key={`common-${i}`} className="text-black">{word1} </span>);
        i++;
        j++;
      } else {
        // Check if the word is missing from text2 (added in text1)
        if (i < words1.length && (!words2.includes(word1) || word1 !== words2[j])) {
          result.push(<span key={`removed-${i}`} className="text-red-500">{word1} </span>);
          i++;
        }

        // Check if the word is missing from text1 (added in text2)
        if (j < words2.length && (!words1.includes(word2) || word2 !== words1[i])) {
          result.push(<span key={`added-${j}`} className="text-green-500">{word2} </span>);
          j++;
        }
      }
    }

    return result;
  };

  return (
    <div className="p-4 bg-gray-100 rounded-lg shadow-md w-[60rem] ml-4 mt-4">
      <h2 className="text-xl font-bold mb-4 text-black">Text Difference Comparison</h2>
      <div className="grid grid-cols-2 gap-4">
        <div className="bg-white p-3 rounded">
          <h3 className="font-semibold mb-2 text-black">Output 1:</h3>
          <p className="text-black font-medium">{text1}</p>
        </div>
        <div className="bg-white p-3 rounded">
          <h3 className="font-semibold mb-2 text-black">Output 2:</h3>
          <p className="text-black font-medium">{text2}</p>
        </div>
      </div>
      <div className="mt-4 bg-white p-3 rounded">
        <h3 className="font-semibold mb-2 text-black">Difference:</h3>
        <p className="font-medium">{compareTexts(text1, text2)}</p>
      </div>
    </div>
  );
};

export default TextDiffComponent;

Output:

Transforming It into an NPM Package 🛠️

The text-compare package is available as an open source project. You can use it for free and also make meaningful contributions to it. Please find the repository here: https://github.com/CreoWis/text-compare

After the initial implementation, my tech lead suggested packaging this logic as an NPM module so that it could be reused across projects. I took on the task of generalizing the logic, ensuring it could handle various text comparison scenarios, and wrapping it into a package.

The result? The text-compare package is now available for the public! 🚀 It not only highlights the differences between texts but also gives you a matching percentage to quantify how similar two pieces of text are.

Using the NPM Package

To get started with the package in your projects, install it via NPM:

npm install text-compare

Then, in your JavaScript or TypeScript file:

import { compareTexts } from 'text-compare';

const originalText = "A beautiful day starts..."
const updatedText = "A productive morning begins..."

const result = compareTexts(originalText, updatedText);
console.log(result); // Returns the comparison with highlighted differences

Enhancements: Customization and Similarity Calculation

In the initial version of the useTextComparison hook, we compared two text inputs word by word and displayed the differences using a simple color-coding mechanism for common, added, and removed words. In this enhanced version, we've incorporated additional features that offer more flexibility and provide more detailed insights into the text comparison.

Key Improvements:

Customizable Colors: We introduced an optional customColors object, allowing users to specify their own colors for common, removed, and added words. This improves the flexibility of the hook by enabling better visual representation based on different use cases. If no custom colors are provided, the comparison will default to gray for common words, red for removed words, and green for added words.
Handling Edge Cases We added logic to handle null or undefined inputs more gracefully. If either text is empty, the function will return an empty result with a similarity of 0%.
Similarity Percentage Calculation: In this version, the hook also calculates the similarity between the two texts as a percentage. This metric provides an additional layer of insight into how closely the two texts match. The formula considers the number of matching words over the total number of words in the longer text, yielding a straightforward similarity score.
Whitespace-Aware Comparison: The text is split using a regular expression that accounts for multiple spaces, ensuring that words are separated appropriately, even if they are followed by multiple spaces.

Here’s the enhanced code:

interface ComparisonColors {
  commonColor?: string;
  removedColor?: string;
  addedColor?: string;
}

const useTextComparison = (t1: string, t2: string, customColors?: ComparisonColors) => {
  const { commonColor = 'black', removedColor = 'red', addedColor = 'green' } = customColors || {};
  const words1 = t1.split(/\s+/);
  const words2 = t2.split(/\s+/);

  const result: JSX.Element[] = [];
  Let i = 0, j = 0.

  while (i < words1.length || j < words2.length) {
    const word1 = words1[i];
    const word2 = words2[j];

    if (word1 === word2) {
      result.push(<span key={`common-${i}`} style={{ color: commonColor }}>{word1} </span>);
      i++;
      j++;
    } else {
      if (i < words1.length && (!words2.includes(word1) || word1 !== words2[j])) {
        result.push(<span key={`removed-${i}`} style={{ color: removedColor }}>{word1} </span>);
        i++;
      }

      if (j < words2.length && (!words1.includes(word2) || word2 !== words1[i])) {
        result.push(<span key={`added-${j}`} style={{ color: addedColor }}>{word2} </span>);
        j++;
      }
    }
  }

  const similarity = (words1.filter(word => words2.includes(word)).length / Math.max(words1.length, words2.length) * 100;

  return { result, similarity };
};

This version enhances the visual representation while providing a similarity score, giving developers flexibility and insights when comparing texts.

How to Use:

To use this updated hook in your React component, simply pass in the two texts you want to compare along with the optional customColors to modify the appearance:

const options = {
  customColors: {
    commonColor: '#1E90FF',    // DodgerBlue for common words
    removedColor: '#FF6347',   // TomatoRed for removed words
    addedColor: '#32CD32',     // LimeGreen for added words
  }
};

const { comparisonResult, similarity } = useTextComparison(text1, text2, options);

With these new features, the useTextComparison hook provides more robust text comparison capabilities and an enhanced user experience. Whether you're creating a text diff viewer, comparing documents, or simply highlighting changes, this updated logic offers both clarity and flexibility.

Wrapping Up

What started as a "quick POC" turned into a full-brain exercise. But you know what? I love days like this. They remind me why I got into coding in the first place—solving puzzles and making cool stuff.

Remember, the key to becoming a better developer isn’t just about writing code; it’s about understanding the problems you're solving and mastering the tools and technologies you're using to solve them. It's about continuous learning, experimenting, and collaborating. That’s the beauty of being a developer!

Now, here's the exciting part—this component is part of our open-source project! 🎉 You can check out the Creowis Text Compare GitHub repository for the full codebase. Feel free to explore, fork, and contribute. Whether you find bugs, improve the code, or suggest new features, your contributions are highly valued, and we’d love to have you join our open-source journey. Open-source is all about learning together and building better software for everyone.

Feel free to play with this tool, break it, tweak it, and most importantly, make it your own. Coding is all about creativity and collaboration, and I’d love to see what you build with this tool. Drop your GitHub repos, share your projects, or connect with me on social media. Let's keep this conversation going, learn from each other, and grow as a community of developers!

Stay curious, keep experimenting, and most importantly, keep having fun with it. Coding is a journey, and every line you write brings you closer to mastering your craft.

If you found this article helpful, don't forget to share it with your fellow dev friends.

Happy coding, everyone! 💻✨

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn**, and follow her work on the GitHub.

Mastering the Developer's Journey: From Challenges to Confidence

Chhakuli Zingare — Wed, 25 Sep 2024 03:04:20 +0000

Every coding journey is unique, shaped by experiences, challenges, and the desire to create something impactful. Becoming a confident developer doesn’t happen overnight—it’s a mix of learning, practice, and mindset shifts. Whether you’re a beginner or a growing developer, there are key principles that can help you build your skills, boost your confidence, and ultimately, create projects that truly matter.

In this blog, we’ll explore actionable strategies, and mindset tips to guide you on your path to becoming a confident, competent developer. By the end of this, you'll feel empowered to make decisions, write clean code, and grow as a problem solver.

Start with Clarity and Focus

One of the biggest challenges for any developer is knowing where to begin when faced with a project or problem. The key is to start with clarity. Before jumping into coding, take a few moments to get a complete understanding of what needs to be done.

Define the core task: Always begin with the most important feature or problem to solve. This sets the foundation for everything else.
Break it down: Take that core task and break it into smaller, digestible chunks. This keeps you moving forward with a sense of accomplishment.
Prioritize effectively: Not all tasks are equally important. Rank your tasks by their impact on the project. Focus on the ones that deliver the most value or remove the largest blockers first.

When you begin with focus and clarity, you’ll move forward with confidence, knowing that you’re solving the right problem the right way.

Learn to Think Like a Developer

It might sound simple, but the best developers are those who don’t rush into code without a plan. They think through the problem, design the solution, and only then start writing code. Here’s how you can adopt this mindset:

Visualize the solution: Whether it’s sketching a flow on paper or mapping out logic in your head, thinking about the architecture before coding can save you hours of rework.
Think about edge cases: Always ask yourself, “What could go wrong?” Thinking about edge cases makes your code more robust.

Examples of edge cases:

What if a user enters an invalid email?
What happens if a form is submitted with empty fields?
How will the system respond if an external API fails?

Building error handling into your code from the start saves you headaches down the road.

3.Plan for scalability: Will your solution work if the data set grows from hundreds to millions of records? Try to foresee how your code will need to scale and design accordingly.

By thinking first and coding second, you’ll not only write more robust code but also feel more in control of your work.

The Power of Asking Questions

No developer knows everything, and that’s okay. What makes someone truly grow is their willingness to ask questions and seek help when needed. Don’t fall into the trap of thinking that asking for help is a weakness—it’s a strength that leads to better solutions.

How to Ask the Right Questions:

Ask early, avoid problems later: Don’t wait until you’ve spent hours stuck on a problem before asking for help. Whether it’s clarifying a project requirement or a tricky bug, asking early saves time and frustration.

Example: If you’re unsure about a specific API integration, it’s far better to clarify with your team before diving into code that might not be aligned with the project’s expectations.
Frame questions correctly: When you ask for help, be specific. Instead of saying, “This isn’t working,” explain what you’ve tried, what you expected, and what actually happened.

Good example: “I’m trying to fetch data from the API, but I’m getting a 404 error. Here’s the URL I’m using and the method. Could this be an issue with the endpoint?”

This way, you’ll get more useful answers faster.
Research before asking: Before approaching someone with a question, do your due diligence. Sometimes, spending 15 minutes researching or testing different approaches can help you find the solution on your own.

By asking the right questions, you not only speed up your development process but also learn faster and become more independent.

Make Decisions with Confidence

Every day as a developer, you make decisions. Some are small, like naming a variable, while others are bigger, like choosing between different libraries or architectures. Making decisions with confidence can elevate your development skills.

Tips for Making Confident Choices:

Understand trade-offs: There’s no perfect solution in programming. Every decision has its trade-offs, so weigh them carefully. Is performance more important than ease of implementation? Will a particular library speed up development but lock you into certain limitations later on?
Don’t chase perfection: Sometimes, “good enough” is better than “perfect.” Aim to deliver solutions that solve the current problem and can be improved later if needed.

By understanding the reasoning behind your decisions, you’ll build a stronger sense of ownership over your code, allowing you to make more impactful contributions.

Work with the Big Picture in Mind

Being a great developer isn’t just about writing efficient code; it’s also about understanding why the code exists. Always try to keep the larger context in mind—whether it’s the business needs, the user experience, or the project goals.

Understand the product’s vision: Why are you building this feature? How does it tie into the broader goals of the application or business?
Empathize with users: Think about how your code will impact the end-user. Is the feature intuitive? Does it solve their problem efficiently? By focusing on the user experience, you’ll create more impactful features.
Communicate your ideas: Don’t be afraid to share your thoughts with stakeholders. If you believe a different approach might serve the project better, voice it.

Having this big-picture view helps you think strategically and align your technical decisions with the long-term success of the product.

Mastering Collaboration

No matter how technically skilled you are, the ability to work well with others is critical in software development. Collaboration, whether within a team or with cross-functional partners like designers and product managers, ensures that the final product is stronger.

How to Be a Better Collaborator:

Communicate proactively: Always keep your team informed about your progress, challenges, and decisions. Lack of communication leads to misalignment and delays.

Example: When working on a feature, regularly update the team with your progress during standups or through project management tools.
Give and receive feedback graciously: Code reviews are essential for growth. When giving feedback, focus on the quality of the code rather than the coder. When receiving feedback, avoid being defensive—use it as a learning opportunity.

Tip: Frame feedback as questions or suggestions, such as, “Have you considered using a different data structure here for efficiency?”
Help others: When a teammate is struggling, offering help not only builds rapport but also strengthens the overall team. Sharing knowledge elevates everyone.

Good collaboration ensures that everyone is aligned, tasks are completed efficiently, and the product delivered meets the highest standards.

Embrace Growth Through Failure

Failure is part of the development process. Whether it’s bugs, crashes, or missteps in design, every failure offers an opportunity for growth. The key is to learn from these mistakes, adapt, and come back stronger.

How to Leverage Failure for Success:

Don’t fear mistakes: View every mistake as a learning experience. Instead of focusing on the error itself, ask yourself: What can I learn from this?.

Example: If your code causes a major bug in production, investigate why it happened and implement safeguards (like more thorough testing) to prevent similar issues in the future.
Share your failures: By sharing mistakes with your team, you help prevent others from making the same misstep. This fosters a collaborative learning environment.
Celebrate resilience: The real success is not avoiding mistakes, but how quickly you recover from them. Each failure is a step towards becoming a more resilient, resourceful developer.

Keep Your Confidence in Check

As you grow in your development career, it’s important to build your confidence, but equally important to stay humble. The more you learn, the more you realize how much there is to learn. This humility is a trait that will serve you well in your career.

Celebrate small wins: Every successful project, bug fix, or new feature you implement is a win. Take a moment to recognize your progress.
Stay curious: There will always be something new to learn—whether it’s a new language, framework, or methodology. Never stop being curious.
Help others: Sharing your knowledge with less experienced developers helps solidify your own understanding and makes the community stronger.

Balancing confidence with curiosity ensures you remain open to new ideas while staying motivated to tackle bigger challenges.

Wrapping Up: Take Action, Build Confidence

To truly grow as a developer, it’s not just about absorbing knowledge; it’s about putting it into practice. After reading this, take some time to reflect on the points discussed here. Are there areas in your coding journey where you can improve? Maybe you need to focus more on asking the right questions, or perhaps you’re ready to start thinking more strategically about the decisions you make.

Here's your next step: pick one strategy from this blog and apply it to your work today. Whether it’s communicating more with your team, planning before you code, or approaching problems with curiosity, make it a point to turn these insights into habits.

With every project, bug, and decision, you’ll build confidence. Over time, these small steps will lead to massive growth, transforming you into not just a competent developer but a great one.

If this blog inspired you, don’t keep it to yourself! Share it with fellow developers who might be on the same path.

And if you’re reading this on Dev.to through CreoWis, leave a comment below, and let’s discuss your experiences. Your voice matters, and your story could help someone else push through their own coding struggles. We would love to hear your thoughts, answer your questions, or explore any challenges you're facing.

Let’s build a stronger developer community together, one line of code at a time. Remember, this is just the beginning—your journey has limitless potential!!

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.

Supercharge team productivity with Husky, ESLint, and Prettier

Chhakuli Zingare — Fri, 20 Sep 2024 13:55:35 +0000

Introduction

In the ever-evolving world of software development, maintaining code quality and consistency is crucial for successful team collaboration. As projects grow in complexity and involve multiple developers, the risk of introducing bugs, inconsistent coding styles, and maintainability issues increases. Fortunately, modern tools and practices have emerged to address these challenges, enabling teams to work more efficiently and deliver high-quality code.

In this blog post, we'll explore the power of tools like Husky, ESLint, Prettier, and more, and how they can enhance your team's development workflow.

The Importance of Code Quality and Consistency

Code quality and consistency are essential for any software project, but they become even more critical when working in a team environment. Poorly written or inconsistent code can lead to increased technical debt, making it harder for developers to understand, maintain, and extend the codebase over time. This, in turn, can significantly impact team productivity and project timelines.

Overlooked errors and style inconsistencies can also introduce bugs and make it challenging to collaborate effectively. Imagine a situation where one developer follows a specific coding style, while another has a different approach. This can make code reviews more time-consuming and increase the risk of merge conflicts, ultimately slowing down the development process.

Fortunately, automated tools can help teams enforce coding standards, identify potential issues, and maintain a consistent codebase across the entire project.

Introducing Husky: The Pre-Commit Hook Powerhouse

Husky is a powerful tool that allows you to run scripts before committing code or pushing changes to a remote repository. It's particularly useful for enforcing code quality checks and preventing developers from accidentally committing code that doesn't adhere to the team's coding standards.

With Husky, you can define pre-commit hooks that run specific scripts before each commit. For example, you could set up a pre-commit hook that runs ESLint (a code linting tool) and Prettier (a code formatting tool) to ensure that your code is free of errors and follows consistent styling conventions.

Setting up Husky in Your Project

# Using npm

npm install husky --save-dev

# Using yarn

yarn add husky --dev

By using pre-commit hooks with Husky, you can catch potential issues early in the development process, reducing the risk of introducing bugs and maintaining a clean, consistent codebase.

Enforcing Code Quality with ESLint: The JavaScript Linting Powerhouse

ESLint is a powerful tool for identifying and fixing problems in JavaScript code. It can help teams enforce coding standards, detect potential bugs, and promote best practices, ensuring that the codebase remains maintainable and easy to understand.

Setting up ESLint in Your Project

# Using npm

npm install eslint --save-dev

# Using yarn

yarn add eslint --dev

ESLint provides a wide range of rules that can help you catch potential issues, such as unused variables, missing semicolons, inconsistent naming conventions, and more. By enforcing these rules across your codebase, you can maintain a consistent coding style and prevent common coding mistakes, ultimately improving code quality and maintainability.

Ensuring Code Consistency with Prettier: The Code Formatting Guru

While ESLint focuses on code linting and identifying potential issues, Prettier is a tool designed specifically for code formatting. It helps teams maintain a consistent coding style by automatically formatting code according to predefined rules.

Integrating Prettier into Your Workflow

# Using npm

npm install prettier--save-dev

# Using yarn

yarn add prettier --dev

module.exports = {
  semi: true,
  singleQuote: true,
  trailingComma: 'all',
  printWidth: 80,
  // Add more rules as needed
};

By enforcing consistent code formatting across your codebase, Prettier reduces the cognitive load for developers when reading and reviewing code. It also helps eliminate unnecessary code style discussions during code reviews, allowing teams to focus on more important aspects of the codebase.

Combining Husky, ESLint, and Prettier: The Ultimate Team Development Trifecta

While each of these tools is powerful on its own, combining them can create a seamless and efficient development workflow that ensures code quality and consistency at every step.

By combining these powerful tools, you can create a streamlined development workflow that promotes code quality and consistency from the very beginning, reducing technical debt and making it easier for team members to collaborate and maintain the codebase over time.

Additional Tools and Best Practices

While Husky, ESLint, and Prettier are powerful tools for enforcing code quality and consistency, they are just a few examples of the many tools and practices that can enhance your team's development workflow.

Here are a few additional tools and best practices to consider:

TypeScript: TypeScript is a superset of JavaScript that adds static typing to the language. By using TypeScript, you can catch type-related errors during development, improving code quality and maintainability.
Tailwind CSS: Tailwind CSS is a utility-first CSS framework that can help teams maintain consistent styling across their projects. It provides a set of pre-defined utility classes that can be used to style components, reducing the need for custom CSS and promoting a more consistent UI.
Folder Structure and Organization: Maintaining a well-organized and consistent folder structure is crucial for large projects with multiple team members. By following best practices for folder structure and organization, you can make it easier for developers to navigate and understand the codebase.
Pair Programming: Pair programming is a practice where two developers work together on the same code, taking turns as the "driver" (who writes the code) and the "navigator" (who reviews and provides guidance). This practice can help catch issues early, promote knowledge sharing, and ensure that code is written following agreed-upon standards and best practices.
Version Control: Using a version control system like Git is essential for team collaboration and maintaining a clear history of code changes. By following best practices for branching strategies, pull requests, and merge workflows, teams can ensure that code changes are reviewed, tested, and merged consistently.

Real-World Applications and Benefits

The benefits of using tools like Husky, ESLint, and Prettier, and implementing best practices for code quality and consistency are not just theoretical; they have been proven time and again in real-world projects.

At @CreoWis , we developed an open-source template repository using Next.js, TypeScript, Tailwind CSS, Husky, Prettier, and ESLint. This repository serves as a starting point for new projects, ensuring that they follow best practices and have a solid foundation for code quality and consistency from the very beginning.

You can check the repository to set up a scaffold for your project using this template repository. 👉 next-js-launchpad

By incorporating these tools and practices into our development workflow, we've experienced significant improvements in code maintainability, reduced technical debt, and increased developer productivity.

Additionally, the combination of pre-commit hooks, code linting, and formatting has significantly reduced the time spent on code reviews, as many potential issues and style inconsistencies are caught and addressed before the code is even committed.

Conclusion

Maintaining code quality and consistency in team development environments is crucial for long-term project success. By leveraging tools like Husky, ESLint, and Prettier, and implementing best practices such as code reviews, and pair programming, teams can streamline their development workflow, reduce technical debt, and ensure a consistently high standard of code quality.

The benefits of these practices are not limited to just improved code maintainability and developer productivity. They also contribute to a more collaborative and efficient team environment, where developers can focus on delivering high-quality features without being bogged down by inconsistencies or preventable issues.

We encourage you to explore these tools and practices in your own projects.

Call to Action

If you found this blog post informative and valuable, we encourage you to follow our blog for more development tips, tutorials, and best practices.

Remember, code quality and consistency are not just nice-to-haves; they are essential components of successful software development, especially in team environments. By embracing the right tools and practices, you can set your team up for long-term success and deliver high-quality software that meets the evolving needs of your users.

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Chhakuli Zingare, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on the GitHub.