Stop Making Your React Components Reusable | React Design

The Reusability Trap: Why Your React Components Are Becoming Unmaintainable

In the modern React ecosystem, "reusability" has been elevated from a best practice to a full-blown theology. We are taught from our first tutorial that DRY (Don't Repeat Yourself) is the ultimate virtue. If you write the same button twice, you’ve failed. If you copy-paste a layout block, you’re a junior developer.

But this obsession with premature abstraction is quietly killing our codebases. In our relentless quest for perfect React component design, we have fallen victim to "componentitis"—the tendency to abstract UI elements for hypothetical future needs that, nine times out of ten, never actually materialize.

The Symptom: The "God Component"

We have all seen it. A component that starts its life as a simple Card eventually morphs into a fragile, sprawling web of conditional props. It starts with showIcon, then adds isHeaderCompact, then disableShadow, until you are staring at an API that looks like this:

<Card 
  showIcon={true} 
  isHeaderCompact={false} 
  disableShadow={true} 
  hasWarningBorder={status === 'pending'}
  variant="primary"
  size="md"
  // ...and 15 more props
/>

This is not component design; this is configuration. Every new boolean prop you add creates an exponential matrix of untested UI states. When you have five boolean props, you don't just have five features; you have 32 potential combinations of states. Most of those combinations are never tested, never used, and eventually, they break in ways that are impossible to debug. This is the definition of a "God Component"—a fragile, monolithic entity that everyone is afraid to touch.

The Root Cause: Solving Problems That Don't Exist

The core issue is that we are designing for a future that hasn't happened yet. We are trying to build a "universal" component that can handle every possible edge case, just in case we need it later. This violates the core principle of YAGNI (You Aren't Gonna Need It).

When we force reusability where it doesn't belong, we increase the cognitive load for every other developer on the team. To use a component, they now have to read through a massive prop-types definition or TypeScript interface to understand which combination of flags will render the specific UI they need.

The Solution: A Pragmatic Taxonomy

Instead of striving for maximum reusability, we should aim for appropriate reusability. I suggest categorizing your components into three distinct buckets:

1. Universal Primitives

These are your building blocks. They are highly reusable, contain minimal styles, and share core behavioral logic. Think Button, Input, Checkbox, or Typography. These components are allowed to be highly configurable because their scope is narrow and well-defined.

2. Global Patterns

These are app-specific constraints. They handle complex interactions that need to be consistent across the entire application. Think Modal, Navigation, or ToastContainer. These are reusable, but they are bounded by your application's specific design system.

3. View Components

These are your feature-specific components. They are strictly non-reusable. If you need a UserDashboardProfileCard, build it for the dashboard. If you need a similar card for the Settings page, do not try to merge them. Let them be "duplicate" and simple. If you find yourself needing to reuse them later, that is the perfect time to refactor—not before.

Favor Composition Over Configuration

When you do need flexibility, stop reaching for more props. Instead, favor composition. React’s children prop and dedicated "slots" (passing components as props) are powerful tools that allow you to inject behavior and structure without polluting the parent component's API.

By keeping feature-specific code in its own folder and embracing duplication as a temporary state, you keep your components lean, testable, and, most importantly, maintainable. The next time you find yourself adding a prop to a component to satisfy a "what if" scenario, stop. Build it twice, see how it evolves, and only abstract when the pattern is undeniable.

Your future self (and your teammates) will thank you.