Stop Making Your React Components Reusable | React Design

In the React realm, the pursuit of reusability has transformed from a recommended practice to a rigid doctrine. From the onset, we are inundated with the mantra of DRY (Don't Repeat Yourself). Should you duplicate a button, you've failed. Should you duplicate a layout block, you're deemed a novice. However, this fixation on early abstraction is inadvertently eroding our codebases.

This phenomenon, dubbed "componentitis," involves over-abstracting UI components in anticipation of hypothetical future demands that seldom come to fruition. The consequence is the emergence of the "God Component," a component that begins as a straightforward Card and morphs into a labyrinthine structure of conditional props. Initially, it might look like this:

```

Card

showIcon = { true }

isHeaderCompact = { false }

disableShadow = { true }

hasWarningBorder = { status === "pending" }

variant = "primary"

size = "md"

// ...and 15 more props

```

This is not thoughtful design; it's convoluted configuration. Each new boolean prop introduces an exponentially growing matrix of untested UI states. With five boolean props, you're not just handling five features; you're navigating 32 distinct states. Most of these states are untested and unused, leading to debugging nightmares. This epitomizes a "God Component," a fragile, monolithic entity that instills fear and hesitation among developers.

The root cause lies in designing for a future that has yet to materialize. We often strive to construct a universal component capable of handling every conceivable edge case. This approach conflicts with the principle of YAGNI (You Aren't Gonna Need It). When we enforce reusability where it's inappropriate, we heighten cognitive load for all team members.

To leverage a component, developers must peruse extensive prop-types definitions or TypeScript interfaces, attempting to discern which flag combination will yield the desired UI.

To counteract this, we should adopt a pragmatic taxonomy, classifying components into three categories:

1. Universal Primitives: These are foundational elements. They are highly reusable, minimally styled, and maintain consistent behavior. Examples include Button, Input, Checkbox, or Typography. These components should be highly configurable due to their narrowly defined scope.

2. Global Patterns: These are application-specific constraints. They manage intricate interactions that need to remain consistent across the entire application. Examples include Modal, Navigation, or ToastContainer. These components are reusable but bound by your application's unique design system.

3. View Components: These are feature-specific components. They are intended for singular use. If you require a UserDashboardProfileCard, construct it for the dashboard. If a similar card is needed for the Settings page, duplication is acceptable. Refactoring should only be considered once reuse becomes evident.

The golden rule is to favor composition over configuration. When flexibility is required, shun additional props. Instead, leverage React’s children prop and dedicated slots (passing components as props). These features allow for behavior and structure injection into parent components without cluttering their API. By compartmentalizing feature-specific code and embracing duplication as a temporary state, we maintain lean, testable components, prioritizing maintainability above all.

The next time you're tempted to append a prop to appease a "what if" scenario, pause. Experiment by building the component twice, observe its evolution, and only abstract when the pattern becomes indisputable. Your future self—and your colleagues—will undoubtedly appreciate this approach.