Skip to main content

Component Reusability: The DRY Principle in React #13

📖 Introduction​

In our previous article, we learned how to create and nest components, and pass props between them. Now, we will explore a core software development principle that is central to React's philosophy: Component Reusability and the DRY Principle.

📚 Prerequisites​

Before we begin, please ensure you have a solid grasp of the following concepts:

  • Creating functional components in React.
  • Passing and receiving props.

🎯 Article Outline: What You'll Master​

In this article, you will learn:

  • ✅ Foundational Theory: What the DRY (Don't Repeat Yourself) principle is and why it's crucial in software development.
  • ✅ Core Implementation: How to identify repeated code and refactor it into a reusable component.
  • ✅ Practical Application: Building a reusable Button component and using it throughout an application.
  • ✅ Advanced Techniques: Thinking in components to design a more modular and maintainable application.
  • ✅ Best Practices & Anti-Patterns: How to create truly reusable components and avoid common pitfalls.

🧠 Section 1: The Core Concepts of DRY and Reusability​

DRY stands for Don't Repeat Yourself. It's a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.

In React, the primary way we apply the DRY principle is by creating reusable components. Instead of writing the same UI code in multiple places, we create a single component and reuse it wherever needed.

Key Principles:

  • Single Source of Truth: A reusable component becomes the single source of truth for that piece of UI. If you need to make a change, you only need to do it in one place.
  • Consistency: Reusable components ensure that your UI is consistent. All your buttons, for example, will look and behave the same way.
  • Efficiency: Reusability saves you time and effort. You write the code once and use it many times.

💻 Section 2: Deep Dive - From Repetition to Reusability​

Let's look at a common scenario where we might repeat code and see how we can refactor it into a reusable component.

2.1 - The "Wet" Code (Write Everything Twice)​

Imagine you have an application with several buttons:

// App.jsx

import React from 'react';

const App = () => {
  return (
    <div>
      <button style={{ backgroundColor: 'blue', color: 'white', padding: '10px 20px' }}>
        Login
      </button>
      <button style={{ backgroundColor: 'green', color: 'white', padding: '10px 20px' }}>
        Sign Up
      </button>
      <button style={{ backgroundColor: 'red', color: 'white', padding: '10px 20px' }}>
        Delete
      </button>
    </div>
  );
};

export default App;

This code works, but it's repetitive. The styling is copied for each button, and if we want to change the padding, we have to do it in three places. This is a classic violation of the DRY principle.

2.2 - The "Dry" Code (Don't Repeat Yourself)​

Let's refactor this into a reusable Button component.

// components/Button.jsx

import React from 'react';

const Button = ({ text, color, onClick }) => {
  const style = {
    backgroundColor: color,
    color: 'white',
    padding: '10px 20px',
  };

  return (
    <button style={style} onClick={onClick}>
      {text}
    </button>
  );
};

export default Button;

Now, we can use our Button component in App.jsx:

// App.jsx

import React from 'react';
import Button from './components/Button';

const App = () => {
  const handleLogin = () => alert('Logging in...');
  const handleSignUp = () => alert('Signing up...');
  const handleDelete = () => alert('Deleting...');

  return (
    <div>
      <Button text="Login" color="blue" onClick={handleLogin} />
      <Button text="Sign Up" color="green" onClick={handleSignUp} />
      <Button text="Delete" color="red" onClick={handleDelete} />
    </div>
  );
};

export default App;

Walkthrough:

  • We've created a Button component that accepts text, color, and onClick as props.
  • The styling is now defined in one place, inside the Button component.
  • Our App component is now much cleaner and easier to read. If we need to change the button styling, we only need to edit Button.jsx.

🛠️ Section 3: Project-Based Example: A Reusable Card Component​

Let's build a more complex reusable component: a Card that can display any content we pass to it.

The Goal: Create a Card component that provides a consistent wrapper (with a border and padding) for any content.

The Plan:

  1. Create a Card component that accepts a children prop.
  2. Use the Card component to wrap different types of content.
// components/Card.jsx

import React from 'react';

const Card = ({ children, title }) => {
  const style = {
    border: '1px solid #ccc',
    padding: '16px',
    margin: '16px',
    borderRadius: '8px',
  };

  return (
    <div style={style}>
      {title && <h2>{title}</h2>}
      {children}
    </div>
  );
};

export default Card;

Now, let's use this Card component in our App.jsx:

// App.jsx

import React from 'react';
import Card from './components/Card';

const App = () => {
  return (
    <div>
      <Card title="Welcome">
        <p>This is a simple card component.</p>
      </Card>

      <Card title="User Profile">
        <p>Name: John Doe</p>
        <p>Email: [email protected]</p>
      </Card>
    </div>
  );
};

export default App;

Walkthrough:

  • The Card component uses the special children prop. children contains whatever JSX is passed between the opening and closing tags of the component.
  • We can also pass other props, like title, to customize the card.
  • Now we have a consistent card style that we can reuse throughout our application for any type of content.

✨ Section 5: Best Practices and Anti-Patterns​

Best Practices:

  • Identify Repetition: Actively look for repeated JSX or logic in your application. This is a sign that you can create a reusable component.
  • Keep Components Generic: When creating a reusable component, try to make it as generic as possible. Use props to handle variations.
  • Start Small: You don't have to create reusable components for everything. Start with simple things like buttons, inputs, and cards.

Anti-Patterns (What to Avoid):

  • Over-engineering: Don't create a reusable component for something that is only used once. This can add unnecessary complexity.
  • Too Many Props: If your reusable component has a huge number of props, it might be a sign that it's trying to do too much. Consider breaking it down into smaller components.

💡 Conclusion & Key Takeaways​

The DRY principle and component reusability are at the heart of what makes React so powerful. By thinking in components and creating reusable pieces of UI, you can build applications that are more maintainable, scalable, and consistent.

Let's summarize the key takeaways:

  • DRY is Your Friend: "Don't Repeat Yourself" is a key principle for writing clean code.
  • Components are for Reusability: React's component model is designed for reusability.
  • Props Make Components Dynamic: Use props to customize your reusable components for different scenarios.

Challenge Yourself: Create a reusable Input component that can be used for text, password, and email inputs. It should accept type, placeholder, and value as props.

➡️ Next Steps​

We've now covered the basics of creating and reusing components. In the next article, "Class Components: A Look at the Past (Part 1)", we will take a step back and look at the older way of writing components. This is important for understanding legacy codebases and for a deeper appreciation of why functional components and Hooks are the modern standard.

Thank you for your dedication. Stay curious, and happy coding!

glossary​

  • DRY (Don't Repeat Yourself): A principle of software development aimed at reducing repetition.
  • Reusability: The ability to use the same component in multiple places with different data.
  • Abstraction: The process of hiding complex implementation details behind a simpler interface (in this case, a component and its props).

Further Reading​