Frontend Architecture: When to Abstract vs When to Duplicate

Architecture on the frontend is mostly a set of decisions: where to put state, when to abstract shared code, when to duplicate, and where to draw boundaries between layers (UI, data, API). Getting these right keeps the app simple to work in and easy to optimize. This post covers how to think about it.

When to abstract

• Rule of three (or two): When the same pattern appears in two or three places and you feel the pain of changing it in each place, consider extracting a component, composable, or util. One abstraction, one place to fix and optimize.
• Clear contract: The abstraction has a clear responsibility and a small, stable API. If the "shared" code is full of conditionals for each caller, the abstraction may be premature—either narrow it or keep the call sites separate.
• Testing and reuse: Abstracted logic (e.g. in a composable) is easier to unit test and reuse; that can justify the extra indirection.

When to duplicate

• Different reasons to change: If two pieces of code look similar but will evolve for different reasons (e.g. "user profile card" vs "user row in a table"), duplicating and letting them diverge is often better than one "flexible" abstraction that gets harder to understand.
• Not yet stable: Before the third use case, copying and pasting is fine. Abstract when the shape of the problem is clear; avoid "we might need this elsewhere" until you do.
• Abstraction is heavier than the duplication: If the shared code requires lots of options, slots, or context to cover all cases, the cost of the abstraction may exceed the cost of a few duplicated lines. Prefer duplication when the abstraction would be complex or brittle.

Boundaries: UI, data, API

Draw clear boundaries so that each layer has a single job: