DEV Community: CreoWis

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.

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.

Key Concepts in SRE: SLA, SLO, and SLI Explained

Arnab Chatterjee — Sun, 05 Jan 2025 13:43:43 +0000

Introduction to SLA, SLO, and SLI in Site Reliability Engineering (SRE)

In a world driven by always-on digital services, ensuring reliability isn’t optional—it’s foundational. Users expect consistent performance, minimal downtime, and fast recovery from incidents. Site Reliability Engineering (SRE) provides the framework to deliver this reliability by aligning engineering practices with business objectives. Central to this framework are three key components: Service Level Indicators (SLIs), Service Level Objectives (SLOs), and Service Level Agreements (SLAs).

SLIs measure service performance, SLOs define acceptable reliability thresholds, and SLAs formalize promises to customers. These concepts guide teams in prioritizing engineering efforts, managing risks, and making data-driven decisions about reliability. This blog dives into the practical application of SLIs, SLOs, and SLAs, providing a roadmap to integrate these practices into your SRE workflows to maintain user trust and meet business commitments effectively.

Foundational Concepts

Service Level Indicator (SLI)

A Service Level Indicator (SLI) is a quantitative metric that measures the reliability and performance of a service. These indicators are critical for understanding how a service behaves from a user’s perspective. Common SLIs include latency, availability, error rate, and throughput.

For example:

Latency: Measures the time taken to respond to a user request.
Availability: Tracks the percentage of time a service is operational (e.g., "The service was up 99.95% of the time last month").
Error rate: Calculates the percentage of failed requests out of the total requests.

Practical Tip: To identify meaningful SLIs, focus on metrics that directly impact the user experience. Start by analyzing user journeys and identify key points where performance issues could occur (e.g., API response time, login page load time). Ensure SLIs are measurable, actionable, and aligned with business goals.

Service Level Objective (SLO)

A Service Level Objective (SLO) defines the target performance or reliability level for a specific SLI. It sets a threshold that represents acceptable service performance from both technical and business perspectives. For instance, an SLO might state that 99.9% of API requests should respond within 300 milliseconds.

The Importance of Realistic SLOs:

Setting achievable SLOs ensures alignment with user expectations and avoids unnecessary stress on engineering teams.
Unrealistic SLOs can lead to frequent breaches and undermine trust.

Example: For an e-commerce platform’s checkout API:

SLI: API response time.
SLO: 99.95% of requests must respond within 500 milliseconds during business hours.

Practical Tip: Use historical data and system capabilities to establish SLOs. Start with internal SLOs before committing to user-facing agreements.

Service Level Agreement (SLA)

A Service Level Agreement (SLA) is a formal contract between a service provider and its customers, outlining the expected reliability and performance levels. Unlike SLOs, SLAs include legal and financial consequences for failing to meet the agreed-upon targets.

Key Differences:

SLOs are internal targets, whereas SLAs are external commitments.
SLAs often have financial implications (e.g., refunds or penalties), while SLOs are primarily used to guide internal improvements.

Example: A cloud service provider might offer an SLA guaranteeing 99.9% uptime per month. If downtime exceeds the allowed threshold, the provider refunds a percentage of the customer’s monthly fee.

Practical Tip: When drafting SLAs, ensure they are measurable, clear, and aligned with internal SLOs to avoid over-promising. Regularly review SLAs to account for changes in infrastructure or business needs.

Relationship Between SLA, SLO, and SLI

How SLIs Feed into SLOs and SLAs

At the core of reliability measurement is the Service Level Indicator (SLI)—the raw metric that quantifies a service's performance. Service Level Objectives (SLOs) build on SLIs by defining target thresholds for these metrics, ensuring they meet business and user expectations. Finally, Service Level Agreements (SLAs) formalize these objectives into commitments made to customers, often with defined penalties for breaches.

SLI → SLO: Example: "The API's response time (SLI) should remain under 300 ms for 99.9% of requests (SLO)."
SLO → SLA: Example: "The API guarantees 99.9% uptime, with refunds for any downtime exceeding this threshold (SLA)."

This hierarchy ensures that internal reliability goals align with external commitments while keeping teams focused on metrics that matter to users.

Practical Context

In an SRE workflow, SLIs help engineers monitor service health. SLOs prioritize efforts by highlighting areas that fall below expectations, and SLAs ensure accountability by linking performance to business outcomes. For instance, an SRE team might prioritize reducing latency for an API to meet an SLA that promises 99.95% availability to enterprise clients.

How SLIs Feed into SLOs and SLAs

At the core of reliability measurement is the Service Level Indicator (SLI)—the raw metric that quantifies a service's performance. Service Level Objectives (SLOs) build on SLIs by defining target thresholds for these metrics, ensuring they meet business and user expectations. Finally, Service Level Agreements (SLAs) formalize these objectives into commitments made to customers, often with defined penalties for breaches.

SLI → SLO: Example: "The API's response time (SLI) should remain under 300 ms for 99.9% of requests (SLO)."
SLO → SLA: Example: "The API guarantees 99.9% uptime, with refunds for any downtime exceeding this threshold (SLA)."

This hierarchy ensures that internal reliability goals align with external commitments while keeping teams focused on metrics that matter to users.

Practical Context

In an SRE workflow, SLIs help engineers monitor service health. SLOs prioritize efforts by highlighting areas that fall below expectations, and SLAs ensure accountability by linking performance to business outcomes. For instance, an SRE team might prioritize reducing latency for an API to meet an SLA that promises 99.95% availability to enterprise clients.

Practical Steps to Implement SLA, SLO, and SLI

Step 1: Identify Critical Services

Not all services have the same impact on users or business outcomes. Start by identifying the most critical services.

Example: An e-commerce platform should prioritize the checkout system over non-critical features like product recommendations, as downtime in checkout directly affects revenue.

Step 2: Define SLIs

Choose indicators that best represent user experience and service health.

Examples: Response time, availability, error rates, throughput.
Practical Tip: Use tools like Prometheus, Grafana, or Datadog to collect and monitor SLIs in real time.

Step 3: Set Realistic SLOs

Use historical performance data and industry standards to establish achievable targets. Strike a balance between ambitious and practical goals:

Example: For an API, an SLO might be "99.95% of requests should respond within 500 ms."
Practical Tip: Avoid setting overly ambitious SLOs that stress your team or infrastructure.

Step 4: Formalize SLAs

Work with stakeholders to draft agreements that align with business priorities and technical capabilities.

Example SLA: "The service guarantees 99.9% uptime, with a 10% refund for each hour of downtime exceeding the SLA."
Practical Tip: Ensure SLAs are specific, measurable, and aligned with internal SLOs to prevent over-promising.

Step 5: Monitor and Iterate

Reliability is a moving target. Regularly review your SLIs, SLOs, and SLAs to ensure they align with evolving business needs and user expectations.

Example: If user traffic increases during specific periods, adjust SLOs to reflect these changes.
Practical Tip: Implement automated monitoring and alerting to quickly identify and address issues that might impact your SLAs or SLOs.

These steps ensure that your reliability practices remain focused, actionable, and aligned with both technical goals and user expectations.

Challenges and Best Practices

Challenges

Aligning SLOs with Business Goals

Defining SLOs that reflect user expectations and align with broader business objectives can be challenging, especially when stakeholders have conflicting priorities.
Over-Promising in SLAs

Setting aggressive SLAs to win customer trust can backfire if they lead to frequent breaches, resulting in penalties and damaged reputation.
Monitoring SLIs in Complex Distributed Systems

In distributed architectures, collecting and analyzing SLIs across multiple services can become overwhelming, leading to gaps in visibility and delayed responses.

Best Practices

Start with Internal SLOs

Before formalizing SLAs, experiment with internal SLOs to ensure they are realistic and achievable.
Automate Monitoring

Use automated tools to continuously monitor SLIs and send alerts for potential breaches. This reduces manual errors and ensures real-time insights.
Establish Incident Response Plans

Define clear workflows for handling SLO breaches, including root cause analysis and mitigation steps, to minimize user impact and prevent recurrence.

Real-World Examples

How Google Uses SLOs to Manage Reliability in Gmail

Google, a pioneer in Site Reliability Engineering (SRE), relies heavily on SLOs to maintain user trust and ensure their services operate smoothly. For Gmail, one of their most critical applications, Google defines an SLO of 99.99% availability. This means that Gmail is allowed a maximum of roughly 4 minutes of downtime per month. By setting this SLO, Google’s SRE teams focus their efforts on preventing outages and mitigating issues that could cause downtime.

For example, if a server crashes, automated systems immediately alert the team to take action, minimizing user impact. This disciplined approach enables Google to proactively allocate resources for reliability while avoiding unnecessary over-engineering.
Hypothetical E-Commerce Platform’s SLA for Holiday Traffic

Imagine an e-commerce platform that experiences a surge in traffic during the holiday season. To meet customer expectations, the platform guarantees 99.95% availability during peak shopping days. This means the service can be unavailable for no more than 21.6 minutes per month.

If a critical service, such as the checkout system, goes down and the downtime exceeds the SLA threshold, the company might face financial penalties, such as refunding a percentage of fees to affected enterprise clients. For instance, if a B2B customer relies on this platform for their own holiday sales, the SLA ensures accountability and offers compensation for lost sales due to downtime.
Downtime SLAs in Cloud Providers (AWS, Azure, Google Cloud)

Cloud providers like AWS, Azure, and Google Cloud offer strict SLAs to their customers to maintain trust in their infrastructure. For example, AWS’s 99.99% uptime SLA for EC2 instances means that customers can expect no more than 4.38 minutes of downtime per month. If this SLA is breached, AWS compensates customers with service credits, such as a percentage of their monthly bill.

For businesses running mission-critical applications on the cloud, these SLAs provide a safety net. However, customers also rely on their own monitoring (using SLIs and SLOs) to ensure they meet their internal reliability targets, creating a cascading framework of accountability.

Tools and Technologies for SLA, SLO, and SLI

Monitoring Tools

Prometheus: Open-source monitoring and alerting toolkit, ideal for tracking SLIs like latency and error rates.
Datadog: Comprehensive monitoring platform with built-in dashboards for tracking SLOs and SLA compliance.
Grafana: Visualization tool to create dashboards and alerts based on SLIs.

Incident Management

PagerDuty: Automates incident response, ensuring rapid resolution of issues impacting SLOs.
Opsgenie: Provides centralized incident notifications and team collaboration tools.

SLA Management Tools

ServiceNow: Enterprise-grade tool for managing SLAs and tracking compliance.
SLAtracker: Lightweight solution for monitoring SLA breaches and generating reports.

Conclusion

SLA, SLO, and SLI are the foundation of reliable digital services, providing a clear framework to measure, target, and commit to performance. They help balance reliability with agility, ensuring user satisfaction without overburdening teams. Start small with critical metrics, refine internal objectives, and iterate based on feedback to build a scalable, user-focused reliability strategy that aligns with business goals.

If you have read so far, thanks! It means you care. Please feel free to share this article in your social circle. 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 software services & product experiences.

Want to work with us? Let’s connect:

This article is crafted by Arnab Chatterjee, a passionate developer at CreoWis. You can reach out to him on X/Twitter, LinkedIn, and follow his 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.

CreoConnect 2024 - From the Founder's Book

Tapas Adhikary — Thu, 19 Dec 2024 13:56:23 +0000

Indeed we love discussing technical matters and are encouraged to share our tech knowledge, but this one has to be different. Yes! let’s talk about our most celebrated event that we have concluded recently, CreoConnect.

Why is it important to talk about CreoConnect?

CreoWis being a startup in its infancy is as curious as any other human baby. It looks up to things with surprise, excitement, emotion, and enthusiasm to explore the new. Be it a service we provide to our customers, or a product that we incubate, the curiosity quotient always remains high.

Needless to say(but, still essential to mention), any organization, be it a small startup, midscale, or a big MNC is the collective of its people. Each skilled individual works with others in the organization to make it grow. For a remote company like CreoWis, we must not miss out on the opportunities to celebrate those individuals who are helping it to grow. Hence CreoConnect - an annual event to connect in person to know each other better, gain more trust, have fun, and understand what it takes to get things done together.

So, it is essential to talk about CreoConnect and get some insights on what went on to make it happen and how it might help us to do better in the future. If you are also a startup like us or with an entrepreneurial mindset, our learning may help you in doing something similar, or even bigger.

The Dream from Day One

In mid-2023 when my co-founder and I were digesting the fact that we will have a remote software company together, we were already dreaming about many other possibilities! One of them was celebrating work.

We didn’t have much idea of how much we would grow in a year, how big the team was going to be, and how many customers we would deal with. However, we were clear that we would have an annual event to celebrate our people, work, and achievements - that’s pretty much what CreoConnect is today. The first instalment of CreoConnect also marks the one-year completion of CreoWis with almost the same set of folks it had started with.

Before the event

The first thing we needed was a name for the event with a wish that we could repeat it on every occurrence. If you think, what’s in a name? I would say a lot. You start sinking into it, start liking it, living it. It may also create a brand for you. So, choose wisely!

In our case, it was a bit straightforward. We said, let’s poll, and we got CreoConnect.

An event like CreoConnect needs solid planning. You need to plan travels, stay, food, activities, logistics, itinerary, and many more tiny things that fulfil it. We, the founders, started the planning almost 3-4 months before to sketch out the timeline, budget, and necessities. A lot of research went into understanding what would be the “best” for all of us, or what most of us would be so proud about. Must say, we have thoroughly enjoyed the process of getting the dream closer to reality.

A month before the event, we announced it to the team on a Discord call. The outburst of happiness and excitement was sky-high. The team took the charge of making the event even more memorable. A daily dose of countdown on the CreoWis Discord server used to act like a positive catalyst, and was enough to create the adrenaline rush among us every morning.

As the day was coming near, we got the idea of shooting a video capturing what CreWis means to each of us, in our vision where do we want to see the company in a few years, and what are we expecting from the CreoConnect 2024? It was truly amazing to see each of us getting involved and bringing the best points out about those.

If you are interested, go over this 6-minute video, hoping you will enjoy it.

CreoConnect 2024 - The annual company event

Finally, it was the time. CreoConnect 2024 was a 3-day in-person event between the 6th to 8th December 2024. On the 6th, all our employees from the different parts of the geo gathered together in Bangalore, India to celebrate. For most of us, it was the first time when we had seen each other in person and got the warmth and the instant bonding we anticipated.

Do not miss this one(with audio ON): https://www.youtube.com/shorts/jVmhIK1h0bU

The first day was fun-filled with catching up with each other, sharing positive vibes, and spending a fantastic time together at the dinner. We connected so well there that it felt like we were meeting each other in person every day. A long walk together after the dinner had made things even more special.

The second day started with our team meeting called, Creo-Catchup. It is our monthly sync-up with company updates, but this time it was a bit different. We covered:

CreoWis formation history
Last 1 year
The future projections
Service Award
Star Award
A couple of minutes of short speech from everyone

Right after the meeting, it was a fun time. We caught up with a bunch of group activities, photos, food, games, and networking.

The last day was for us to return home. But before that, we spent a great time talking to each other, snapping some special moments, and making a point that the upcoming CreoConnect event is going to be even bigger.

Here are some moments we cherish together, hope you like them, too.

You can also catch up more about the event on our Instagram Page and YouTube Channel.

Key Takeaways

We have some key takeaways from the event that we believe going to strengthen our core values.

We work together best as friends, people, and humans, rather than resources.
The culture of a company may not be built in a day, but it gets seeded very early. The more we nurture it with the right ingredients, the better it blossoms.
When you are a team, behave like a team. Transparency is the key. Be open with your thoughts and articulation.
Treat others the way you want to be treated.
Last, but not least, the feeling of belongingness and ownership. This place is for me, I make it better. If things are not going well at times, I need to step up and fix them.

I am extremely proud of our team at CreoWis. I hope to write a bigger sequel of this post sometime in 2025 with some more faces getting added. Until then, Keep going.

Want to work with us? Let’s connect:

This article is crafted by Tapas Adhikary, Co-Founder at CreoWis. You can reach out to him on X/Twitter, LinkedIn, and follow his work on the GitHub and YouTube.

How to Use Playwright with Next.js - A Step-By-Step Guide

Prachi Sahu — Tue, 10 Dec 2024 11:27:51 +0000

Greetings from the Playwright universe! You've come to the right spot if you're searching for a robust, dependable, and developer-friendly platform to manage end-to-end (E2E) testing.

Microsoft created Playwright, a cutting-edge testing framework for end-to-end (E2E) testing. It is designed to provide quick, dependable, and adaptable testing for web applications and supports a variety of browsers, including Chrome, Firefox, and WebKit (Safari).

Why Playwright?

For each test, Playwright builds a separate browser context, guaranteeing independence without lag. To increase speed without compromising test isolation, it saves authentication states to avoid repeated logins.

The playwright eliminates the need to use arbitrary timeouts by using web-first assertions and auto-wait for components. To troubleshoot more quickly while testing, set up retries and take screenshots, videos, and traces.

Playwright integrates seamlessly with your tech stack thanks to its support for TypeScript, JavaScript, Python, .NET, and Java. Playwright is a great option for automating user interactions for UI testing.

Setting Up a Next.js Project

We will start by setting up a Next.js project using the Next.js Launchpad of our company, CreoWis. This Launchpad gives you the necessary tools, customizations, and best practices to optimize your development process with a hassle-free, pre-configured setup for Next.js applications. This configuration makes it easier to start a project and lets you concentrate on constructing instead of configuring.

Read more details about what this Launchpad provides here.

Create Project Folder:

Create a new folder for the project, here we will use PlaywrightNext as the project name.

mkdir PlaywrightNext
cd PlaywrightNext

Initialize Next.js with CreoWis Launchpad:

Next, use the CreoWis Launchpad template to set up your Next.js project or you can also use the standard npx create-next-app@latest command to create a new Next.js project.

npx create-next-app -e https://github.com/CreoWis/next-js-launchpad

Now we are all set to start with Playwright testing to make sure your app runs smoothly, we'll go ahead and use Playwright for end-to-end testing.

Playwright Setup

Let’s get started with installing Playwright, you can do so by using npm, yarn, or pnpm.

npm init playwright@latest

This command will prompt you to:

Choose test directory: This is required. If you press Enter without typing a directory, it will default to tests.
Add GitHub Actions workflow (y/N): Optional—choose "y" if you want automatic CI setup, or press Enter to skip.
Install Playwright browsers (Y/n): Required—press "y" or simply Enter to install the necessary browsers.

Choose each option according to your needs, and the Playwright will complete the setup.

In addition to setting up Playwright, running this command also creates an example test file, example.spec.ts automatically. A few sample tests that demonstrate basic Playwright features are included in this file, which can be used as a useful guide when you begin creating your tests.

Some Testing Terminologies

Before diving into writing our first Playwright test, let’s understand some basic testing terms and concepts.

Navigation:

The majority of tests start by visiting a URL. This can be done in Playwright by using page.goto(), which pauses until the page loads before proceeding. You can interact with the page's elements after it has loaded.

await page.goto('https://www.creowis.com');

Interactions:

Locators are used by the Playwright to interact with elements. These enable you to locate and take action on elements, such as filling out a form or clicking a button. Before taking any action, the playwright makes sure the element is ready for interaction.

Some built-in Locators:

page.getByText(): Locate by text content.
page.getByRole(): Locate by explicit or implicit accessibility attributes.
page.getByLabel(): Locate a form element by the text on its label.
page.getByPlaceholder(): Locate an input by its placeholder.
page.getByAltText(): Locate an element (usually an image) by its alt text.
page.getByTitle(): Locate an element by its title attribute.
page.getByTestId(): Locate an element based on its data-testid attribute.

Actions:

A variety of built-in actions are available in Playwright for interacting with elements. These consist of:

locator.click() – Click an element.
locator.fill() – Fill an input field.
locator.hover() – Hover over an element.
locator.check() – Check a checkbox.
locator.selectOption() – Select an option from a dropdown.

Assertions:

Conditions in your tests are validated by assertions. For assertions, Playwright offers the expect() function. Some common assertion examples are checking visibility, text existence, or element attributes.

await expect(page.getByText('Elevating ideas with')).toBeVisible();

some common examples of assertions:

expect(locator).toBeChecked(): Checkbox is checked.
expect(locator).toBeVisible(): Element is visible.
expect(locator).toContainText(): Element contains text.
expect(locator).toHaveText(): Element matches the text.
expect(locator).toHaveValue(): Input element has value.
expect(page).toHaveTitle(): Page has a title.
expect(page).toHaveURL(): Page has URL.

Fixtures:

Fixtures in Playwright are similar to reusable test sets. The environment is automatically set up before the test runs and cleaned up afterwards. To prevent tests from interfering with one another, Playwright, for instance, has an integrated page fixture that provides you with a new browser page for every test.

test('has title', async ({ page }) => {
  await page.goto('https://www.creowis.com/');
  const titleText = page.getByText('Elevating ideas with');
  await expect(titleText).toBeVisible();
});

Test Hooks:

This is for organizing tests and handling setup/teardown on a broader scale.

Setup: This describes the steps done to get the environment ready before a test run. For instance, starting a browser, going to a particular page, or initializing data.
Teardown: This describes the steps done to tidy up or reset the environment following a test run. This can involve erasing test data or shutting down the browser.

Here are a few of the important ones:

test.describe: Used to group related tests together
test.beforeAll: Runs once before all tests in a describe block, typically used for global setup.
test.afterAll: Runs once after all tests in a describe block, ideal for global cleanup.
test.beforeEach: Runs before each test, useful for setting up a clean state.
test.afterEach: Runs after each test, ideal for cleanup tasks.

Creating a basic test

Let’s dive right into creating a basic test using Playwright.

test('has subtitle', async ({ page }) => {
  await page.goto('https://www.creowis.com/');
  const subTitle = page.getByText('Crafting digital experience by');
  await expect(subTitle).toBeVisible();
});

Explanation:

test(): Specifies the test case, including an asynchronous function with the test logic and a description ('has subtitle’).
page.goto(): Opens the given URL (in this example, 'https://www.creowis.com/').
page.getByText(): Finds an element by its text that is visible. The subtitle 'Crafting digital experience by' is what it searches for here.
expect(): To establish an assertion and determine whether the element is displayed on the page.
toBeVisible(): An assertion that confirms the element is visible on the page.

The test verifies that the subtitle text appears on the page and is present.

To run the test, use the command:

npx playwright test

If everything is configured properly, the test run should yield a successful result!

It should appear as follows in vs code:

Since it runs on all three browsers for WebKit, Chrome, and Firefox, the count is 3.

The test can also be conducted in UI mode. To do so, execute the command:

npx playwright test --ui

Once your test is finished you also get a comprehensive report of all your tests. If some of the tests fail, the HTML report is automatically viewed by default. To view the report, run the following command:

npx playwright show-report

Bonus:

Try exploring and running the following command to see what Playwright can do:

npx playwright codegen https://www.creowis.com/

Execute this command to perform browser-based actions. Playwright makes it simpler to develop tests by automatically generating code depending on your interactions. Here URL is optional, it is always possible to run the command without the URL and then add the URL straight into the browser window.

Conclusion

With the help of Playwright, developers can easily and effectively automate end-to-end testing. It is an excellent option for testing web applications because of its versatility across many browsers, support for parallel execution, and sophisticated features like network interception.

With this guide, I hope you're ready to start experimenting with Playwright in your projects.

Happy coding!

Resources

Playwright Documentation

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 Prachi Sahu, a passionate developer at CreoWis. You can reach out to her on X/Twitter, LinkedIn, and follow her work on GitHub.

TanStack Table Explained: Everything You Need to Know

Prachi Sahu — Tue, 26 Nov 2024 07:59:18 +0000

Introduction

In the world of modern web development, displaying data effectively and efficiently is a common challenge. Whether it's a simple list of users or a complex financial report, tables are essential. While there are many libraries available to handle tables in React, few offer the flexibility, performance, and ease of use that TanStack Table does.

TanStack Table, previously known as React Table, has quickly become the go-to solution for developers needing powerful and customizable table components. TanStack is not only compatible with React but it also supports Angular, Lit, Qwik, Solid, Svelte, Vue, and also Vanilla JavaScript/TypeScript.

In this blog post, we'll dive into what makes TanStack Table stand out, explore its core features, and provide a hands-on example to get you started.

What is TanStack Table?

TanStack Table is a lightweight, highly customizable, and headless UI for building powerful tables & data grids. By "headless," we mean it comes with all the core functionality and logic for table operations without any user interface. This gives us total control over our table's appearance while also taking advantage of the built-in functionality.

Why choose the TanStack table?

Choosing a table library for your project can be confusing as so many options are available online. Here’s why TanStack Table might be the best fit for your next project:

1. Performance

When our dataset is large managing it efficiently becomes crucial as we also have to take performance into account. TanStack uses features like Virtualization and Tree shaking which are methods for optimising performance. It also optimizes rendering to ensure that even if there are tens of thousands of rows the performance is smooth.

Tree shaking is a process of optimising during final javascript bundling, it removes all the dead code or unused code from the bundle.

Virtualization or Windowing is a technique to improve performance by only rendering the items that are currently in view.

2. Adaptability

TanStack table supports headless architecture which allows us to be free from any built-in UI. Its high customizability lets us integrate it with any CSS framework or theme. This flexibility comes in very handy when design changes are required for almost every project.

3. Advanced Feature

TanStack Table supports a wide range of feature lists such as:

Sorting with customizable sort functions.
Built-in filters or custom filter logic.
Hide or unhide any column.
Built-in pagination logic.
Group rows by any criteria.
Dynamic resizing of columns.
Select rows with checkboxes or other UI elements.

4. Active Community and Support

TanStack Table is actively maintained and is supported by a great community. The documentation is precise and easy to understand.

Key challenges when using TanStack Table

Although TanStack Table offers many advantages, it also has some drawbacks.

Managing column width according to data length.
Making the table responsive for all screen sizes.
Debugging a custom build table using the TanStack table
Comprehensive documents can make it difficult to find quick answers.
The learning curve is steep.

Getting Started with TanStack Table

Let's start with a simple example. We'll create a basic table using TanStack Table.

Step 1: Install TanStack Table

First, let's install TanStack Table and its peer dependencies.

npm install @tanstack/react-table

Step 2: Set Up the Table

We'll start by setting up our table component. For this example, we’ll use a simple dataset of users.

import * as React from 'react';
import {
  createColumnHelper,
  flexRender,
  getCoreRowModel,
  useReactTable,
} from '@tanstack/react-table';

export type User = {
  id: number;
  name: string;
  age: number;
  email: string;
  country: string;
  subscription: string;
  wallet_balance: number;
};

export const users: User[] = [
  {
    id: 1,
    name: 'John Doe',
    age: 35,
    email: 'john.doe@example.com',
    country: 'United States',
    subscription: 'Premium',
    wallet_balance: 150.25,
  },
  {
    id: 2,
    name: 'Alice Smith',
    age: 28,
    email: 'alice.smith@example.com',
    country: 'Canada',
    subscription: 'Basic',
    wallet_balance: 50.75,
  }
];

const columnHelper = createColumnHelper<User>();

const columns = [
  columnHelper.accessor('name', {
    header: () => 'Name',
    cell: (info) => info.getValue(),
  }),
  columnHelper.accessor('age', {
    header: () => 'Age',
    cell: (info) => info.getValue(),
  }),
  columnHelper.accessor('email', {
    header: () => 'Email',
    cell: (info) => info.getValue(),
  }),
  columnHelper.accessor('country', {
    header: () => 'Country',
  }),
  columnHelper.accessor('subscription', {
    header: 'Subscription',
  }),
  columnHelper.accessor('wallet_balance', {
    header: 'Wallet balance',
  }),
];

const Table = () => {
  const [data, _setData] = React.useState([...users]);

  const table = useReactTable({
    data,
    columns,
    getCoreRowModel: getCoreRowModel(),
  });

  return (
      <table>
        <thead>
          {table.getHeaderGroups().map((headerGroup) => (
            <tr key={headerGroup.id}>
              {headerGroup.headers.map((header) => (
                <th
                  key={header.id}
                >
                  {header.isPlaceholder
                    ? null
                    : flexRender(
                        header.column.columnDef.header,
                        header.getContext()
                      )}
                </th>
              ))}
            </tr>
          ))}
        </thead>
        <tbody>
          {table.getRowModel().rows.map((row) => (
            <tr key={row.id}>
              {row.getVisibleCells().map((cell) => (
                <td key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </td>
              ))}
            </tr>
          ))}
        </tbody>
      </table>
  );
};

export default Table;

In the code above we have users data to populate the table. We are using createColumnHelper function to create columnHelper which is then used to define an array of columns. These columns decide how data will appear in the table. It creates columns according to the header we have provided. In this case, it is "Name," "Age," "Email," etc. We can customize cell rendering behavior by providing cell property. If it is not provided then it indicates that the default cell rendering behavior will be used.

useReactTable hook is used to set up a table component with data and column configurations. This configuration decides how data will be rendered in the table. We are using table.getHeaderGroups() and table.getRowModel().rows for generating the header and body of the table.

After some styling, the table would look like the below image:

Step 3: Customize accordingly

You can now start customizing the table according to your needs. You can add search, sorting, pagination, or any other features. TanStack provides the hooks and ease to add all this functionality. You can refer to their official documentation here.

Conclusion

TanStack's table could be a great option for your next table. Its headless UI makes design integration effortless and its rich feature set makes it simple to create pagination, sorting, filtering, and other features. For further clarity, explore additional examples in the documentation.

Happy coding!

Resources

TanStack Table Documentation

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.

Let's connect:

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