Reusable Components

Introduction

The last lesson introduced the idea of designing components deliberately. This lesson goes one level deeper: what specifically makes a component reusable in practice, versus one that merely looks reusable but breaks the moment it is used somewhere slightly different?

You will walk through a realistic evolution — starting with a button hardcoded for one specific use, and gradually reshaping it into a genuinely reusable Button component — while also learning when NOT to over-engineer reusability too early.

What Makes a Component Reusable

A component is not automatically reusable just because it is a function that returns JSX. Genuine reusability comes from a handful of concrete habits, all aimed at the same goal: letting the same component serve many different call sites without being edited each time.

Single Responsibility

A reusable component should be easy to describe in one short sentence: "renders a button," "shows a labeled input," "displays a card with a title and body." If describing a component requires the word "and" more than once, it is probably doing too much to reuse cleanly.

Sensible Default Props

Reusable components should work well out of the box with minimal props, while still allowing customization when needed. Default parameter values in the function signature are the standard way to achieve this in modern React.

function Button({ variant = 'primary', size = 'medium', children, ...rest }) {
  return (
    <button className={`btn btn-${variant} btn-${size}`} {...rest}>
      {children}
    </button>
  );
}

A caller who just needs a normal button can write <Button>Save</Button> with zero extra props, while a caller who needs something different can override variant or size explicitly.

Using children for Flexibility

A common mistake is accepting content as a text prop, like label="Save", which only works for plain text. Accepting children instead lets callers pass anything — plain text, an icon plus text, or even another component.

From One-Off Button to Reusable Button

Imagine a "Save" button that started life hardcoded for one specific form, with its color, size, and label all baked in directly.

function SaveButton() {
  return (
    <button style={{ background: 'blue', padding: '8px 16px', color: 'white' }}>
      Save
    </button>
  );
}

This works fine for exactly one screen. The moment another screen needs a red "Delete" button or a smaller "Cancel" button, this component cannot help — it would need to be copy-pasted and edited, creating duplicate, drifting code.

function Button({ variant = 'primary', size = 'medium', children, onClick }) {
  const variantStyles = {
    primary: { background: '#3b82f6', color: 'white' },
    danger: { background: '#ef4444', color: 'white' },
    outline: { background: 'transparent', color: '#3b82f6', border: '1px solid #3b82f6' },
  };

  const sizeStyles = {
    small: { padding: '4px 10px', fontSize: '13px' },
    medium: { padding: '8px 16px', fontSize: '15px' },
    large: { padding: '12px 22px', fontSize: '17px' },
  };

  return (
    <button
      onClick={onClick}
      style={{ ...variantStyles[variant], ...sizeStyles[size], border: variantStyles[variant].border || 'none', borderRadius: '6px' }}
    >
      {children}
    </button>
  );
}

export default Button;

<Button>Save</Button>
<Button variant="danger" onClick={handleDelete}>Delete</Button>
<Button variant="outline" size="small">Cancel</Button>

[blue] Save     [red] Delete     [outline, small] Cancel

The same Button component now serves every screen in the app. Callers only specify what actually differs — the variant, the size, the content, and the click handler — while the rest stays consistent automatically.

The Rule of Three

It is tempting to make every component maximally reusable from day one, adding props for every imaginable future use case. In practice, this often backfires: you end up guessing at flexibility you may never need, adding complexity for no real benefit. A simpler guideline is the "rule of three."

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

Genuine reusability is not about maximizing configuration options from day one — it is about single responsibility, sensible defaults, flexible content through children, and recognizing the right moment to extract a shared component. The rule of three offers a practical way to time that extraction well.

In this lesson, you learned the core principles behind reusable components, evolved a one-off Button into a properly reusable one, and weighed the tradeoffs between under- and over-engineering reusability. Next, you will apply these component-design skills to building and validating forms.