One of the easiest traps in frontend development is over–engineering your shared components. You start with one neat reusable button, next thing you know, your shared folder has 40 components, half of which only get used once.
The real skill is knowing when to abstract and when to leave a component exactly where it is.
Here’s a simple, practical way to think about it.
When You Should Abstract a Component
1. The UI pattern shows up everywhere
If you keep recreating the same button style, card layout, dropdown, or modal logic across modules, abstract it. Shared UI components help maintain a tight and consistent visual identity, avoiding copy-paste chaos.
2. The component has clean inputs and outputs
Think of things like: app-button, app-card, app-avatar, app-loader. These don’t rely on any external state and don’t care which module they’re in. That’s exactly what a shared component should look like.
3. You want to avoid future refactor pain
Shared components act like a central control point. Update it once, and every feature automatically benefits. This is especially important as your app grows or when you’re building multiple frontends within the same project.
When You Should Not Abstract a Component
1. It belongs to a specific feature
If your component interacts directly with a feature-specific service, relies on domain logic, or only makes sense within a specific part of the app, keep it local.
2. The abstraction isn’t stable yet
A big mistake is abstracting too early, before you fully understand the pattern. Build the feature first. Let that pattern show up two or three times. Then extract the reusable part.
This prevents you from building a super-generic shared component that tries to solve every problem and ends up solving none.
3. It will introduce unnecessary complexity
Sometimes forcing something into a shared folder actually makes the code harder to work with. You start adding extra inputs, optional behaviors, workarounds, and conditionals, all because you tried to make one component do too much. If the component becomes more complicated after abstraction, that’s a red flag.
A Practical Guideline You Can Use Today
- If a component is UI-only, stateless, and used repeatedly, put it in a shared ui folder.
- If a component contains business logic or is tied to a specific feature, keep it inside the feature module.
- If a component is unique, experimental, or hasn’t shown a clear repeatable pattern, don’t abstract it yet, wait until the pattern actually repeats.
Keeping your shared architecture simple doesn’t just make your Angular project clean. It also makes you faster, reduces bugs, and keeps your team from fighting unnecessary over-abstraction.
Top comments (0)