The most useful React components are not the ones with the most props. They are the ones that make a product decision explicit.
A button component is rarely just a button. It carries hierarchy, disabled behavior, loading treatment, icon alignment, focus state, and whether the action is destructive. A card component often decides how much information a list item can carry before it needs a detail page.
Reuse is a side effect
Teams often start with reuse as the goal. That usually creates prop-heavy components that can look like anything. The better target is a boundary:
- What decision does this component own?
- Which states are valid?
- Which states are impossible?
- What data shape does it need?
- What interaction contract does it expose?
Once those answers are clear, reuse tends to happen naturally.
Prefer explicit variants
Boolean flags are tempting because they feel fast. They also create multi-mode components where combinations are hard to reason about.
type ProjectCardTone = "featured" | "standard" | "quiet";
type ProjectCardProps = {
tone: ProjectCardTone;
title: string;
summary: string;
tags: string[];
};
This is not ceremony. It is a small contract that tells the next engineer what the design system actually supports.
Boundaries make reviews easier
When a component has a clear product boundary, review changes become concrete. You are not arguing about taste in every pull request. You are asking whether the new state belongs to the component, whether the data model still fits, and whether the visual hierarchy still matches the user's job.
That is where front-end architecture starts to feel like product work.