Stop 19 · Frontend System DesignTopics · 6/13

Reusable Components

Part of the Frontend Developer Roadmap

In short

Copy-pasting a component and tweaking it feels fast, until a bug needs fixing in seven places. Reusable components let you fix it once.

Designing components to be generic and composable enough to be used in multiple contexts, instead of copy-pasting near-duplicate components everywhere.

The jaadu pours hot water from one kettle into chai, coffee and a bowl of noodles.

Think of it like this

One kettle, many drinks

The same kettle makes chai, coffee or Maggi water. It doesn't care what you're making, it just heats water well. A good reusable component does one job well and lets you decide what goes inside it.

Watch it happen

Composing a Card

CourseTile
Card
Card.Image
Card.Title
Badge

1/5CourseTile is the specific piece your page needs.

The big ideas

What you need to know

Composition over options

Accept children or slots for content instead of adding a prop for every possible layout.

Pass through native props

Extend the HTML element's props so things like onClick, disabled and aria-label just work.

Data in, events out

Take data through props and report changes through callbacks. Don't fetch inside a generic component.

Rule of three

Duplicate once if you must. When the third copy appears, that's the time to extract a shared component.

See it in code

Walk through the code

tsx
1// Bad: a prop for every case2<Card title="Course" showImage showPrice showBadge badgeText="New" />3 4// Good: compose what you need5<Card>6  <Card.Image src={course.image} alt={course.name} />7  <Card.Title>{course.name}</Card.Title>8  <Badge>New</Badge>9</Card>

1/3The prop-heavy way: every layout option becomes another prop.

The composed version handles layouts the author never planned for. Each sub-part stays small and easy to test.

Save yourself the pain

Common mistakes

Oops

Making a component reusable before a second use case even exists.

Do this instead

Build it for the one case you have. Extract and generalise when a real second or third use shows up.

Oops

Boolean props like isLarge, isSmall and isTiny on the same component.

Do this instead

Use one size prop with fixed options, like size="sm" | "md" | "lg".

Your mission

Refactor a copy-paste mess

~30 min

Quick check

Your Modal component has props for title, subtitle, footerButtons, showClose and iconLeft, and keeps growing. What's a better design?

Go deeper

  1. 1Find a duplicated component in a project and merge it into one reusable version.
  2. 2Practice designing a component's prop API before writing its implementation.
  3. 3Balance flexibility (many props) against simplicity — too many props hurts usability.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge