<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/don-t-build-the-reusable-component-yet-qva1bdc6k" -->

---
title: Don’t Build the Reusable Component Yet | daily.dev
description: Merging three similar-looking UI workflows into one reusable component can cost more than the duplication it removes. A developer describes combining...
canonical: https://daily.dev/posts/don-t-build-the-reusable-component-yet-qva1bdc6k
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Don’t Build the Reusable Component Yet | daily.dev
og:description: Merging three similar-looking UI workflows into one reusable component can cost more than the duplication it removes. A developer describes combining...
og:url: https://daily.dev/posts/don-t-build-the-reusable-component-yet-qva1bdc6k
og:image: https://api.daily.dev/og/posts/QvA1BdC6K.png
og:image:alt: Don’t Build the Reusable Component Yet
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Don’t Build the Reusable Component Yet

**[Stack Overflow Blog](https://daily.dev/sources/stackov)** · 7 min read · 0 upvotes · 0 comments

## Summary

Merging three similar-looking UI workflows into one reusable component can cost more than the duplication it removes. A developer describes combining 'approve', 'change' and 'move' item actions into a single ItemAction component, which grew flags like mode, variant, showDetails and onSpecialCase as edge cases piled up. Eventually any change required sign-off from all three workflow owners. The fix: follow the 'rule of three' (credited to Don Roberts via Martin Fowler's Refactoring) and only abstract once the same code changes for the same reason three times, while still sharing stable primitives, design tokens, accessibility behavior and standards-driven code from day one.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://stackoverflow.blog/2026/11/05/don-t-build-the-reusable-component-yet>

## Questions this post answers

### When should I abstract duplicated UI code into a shared component instead of leaving it duplicated?

Wait until the same pattern repeats three times for the same underlying reason for change, a guideline known as the 'rule of three' attributed to Don Roberts in Martin Fowler's 'Refactoring'. Before that, duplicated code is cheaper to maintain than a wrong abstraction, since premature sharing forces unrelated workflows to coordinate every change.

_Weighing when to DRY up a component? daily.dev surfaces discussions on abstraction trade-offs like this one._

### How can I tell if two pieces of identical-looking code are true duplication or just coincidentally similar?

Ask who you'd consult if the requirement changed and whether all copies would need to change at the same time. If the answer varies between the copies, such as a submit call that changes with approval policy versus one that changes with validation rules, it's a coincidence, not true duplication, and should stay separate.

_Debugging a messy shared component? daily.dev collects real-world refactoring lessons like this test._

### What kinds of frontend code are safe to abstract into a shared component right away, before any duplication occurs?

Primitives like buttons, text inputs and layout containers, design tokens like colors and spacing, accessibility behavior such as focus trapping and keyboard navigation, and anything driven by an external standard like date or currency formatting. These are safe because their shape is stable or defined externally, not based on guesses about future requirements.

_Deciding what to componentize early? daily.dev tracks practical frontend architecture guidance like this._

## Similar posts on daily.dev

- [The React Component Pyramid Scheme: An Over-Engineering Crisis](https://daily.dev/posts/the-react-component-pyramid-scheme-an-over-engineering-crisis-zhsxznqk3) · The New Stack · 74 upvotes · 4 comments
- [How I Learned to Structure React Projects Around Change, Not Folders](https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn) · Medium · 121 upvotes · 4 comments
- [Designers already think in React](https://daily.dev/posts/designers-already-think-in-react-rbce4lfse) · thoughbot · 6 upvotes · 1 comments
- [Build Wide, Ship Narrow](https://daily.dev/posts/build-wide-ship-narrow-ubltyfimm) · Hacker News · 1 upvotes · 0 comments
- [Using Rovo Dev multi‑stage prompts for refactoring UI components](https://daily.dev/posts/using-rovo-dev-multi-stage-prompts-for-refactoring-ui-components-0u9gsoz0w) · Atlassian · 0 upvotes · 0 comments

---

Tags: [#react](https://daily.dev/tags/react), [#frontend](https://daily.dev/tags/frontend)

[View this post on daily.dev](https://daily.dev/posts/don-t-build-the-reusable-component-yet-qva1bdc6k)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Don’t Build the Reusable Component Yet","url":"https://daily.dev/posts/don-t-build-the-reusable-component-yet-qva1bdc6k","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/don-t-build-the-reusable-component-yet-qva1bdc6k"},"datePublished":"2026-11-05T16:14:24.332Z","dateModified":"2026-11-05T16:22:21.134Z","description":"Merging three similar-looking UI workflows into one reusable component can cost more than the duplication it removes. A developer describes combining...","image":"https://media.daily.dev/image/upload/s--P4t4XyoV--/f_auto/v1722860399/public/Placeholder%2001","thumbnailUrl":"https://media.daily.dev/image/upload/s--P4t4XyoV--/f_auto/v1722860399/public/Placeholder%2001","isAccessibleForFree":true,"articleSection":"Stack Overflow Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Stack Overflow Blog","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/003e14873238469caea60ebdd34508ae","url":"https://daily.dev/sources/stackov"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/don-t-build-the-reusable-component-yet-qva1bdc6k","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"react,frontend","timeRequired":"PT7M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Stack Overflow Blog","item":"https://daily.dev/sources/stackov"},{"@type":"ListItem","position":3,"name":"Don’t Build the Reusable Component Yet"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/don-t-build-the-reusable-component-yet-qva1bdc6k#faq","mainEntity":[{"@type":"Question","name":"When should I abstract duplicated UI code into a shared component instead of leaving it duplicated?","acceptedAnswer":{"@type":"Answer","text":"Wait until the same pattern repeats three times for the same underlying reason for change, a guideline known as the 'rule of three' attributed to Don Roberts in Martin Fowler's 'Refactoring'. Before that, duplicated code is cheaper to maintain than a wrong abstraction, since premature sharing forces unrelated workflows to coordinate every change. Weighing when to DRY up a component? daily.dev surfaces discussions on abstraction trade-offs like this one."}},{"@type":"Question","name":"How can I tell if two pieces of identical-looking code are true duplication or just coincidentally similar?","acceptedAnswer":{"@type":"Answer","text":"Ask who you'd consult if the requirement changed and whether all copies would need to change at the same time. If the answer varies between the copies, such as a submit call that changes with approval policy versus one that changes with validation rules, it's a coincidence, not true duplication, and should stay separate. Debugging a messy shared component? daily.dev collects real-world refactoring lessons like this test."}},{"@type":"Question","name":"What kinds of frontend code are safe to abstract into a shared component right away, before any duplication occurs?","acceptedAnswer":{"@type":"Answer","text":"Primitives like buttons, text inputs and layout containers, design tokens like colors and spacing, accessibility behavior such as focus trapping and keyboard navigation, and anything driven by an external standard like date or currency formatting. These are safe because their shape is stable or defined externally, not based on guesses about future requirements. Deciding what to componentize early? daily.dev tracks practical frontend architecture guidance like this."}}]}
```

