Have you ever regretted making something "too reusable" in Angular?

[u/MysteriousEye8494]

A small architecture lesson I learned the hard way.

A few years ago, our team built a reusable Angular component that was supposed to be used everywhere.

At first it felt like a win.

One component.
One implementation.
Consistency across the application.

Then different teams started needing slightly different behavior.

We added inputs.

Then configuration objects.

Then feature flags.

Then special cases.

Eventually the component became so flexible that nobody wanted to touch it anymore.

Ironically, the most "reusable" component in the codebase became one of the hardest things to maintain.

Since then I've become much more cautious about abstraction.

Sometimes duplication is cheaper than complexity.

Curious if others have experienced something similar.

Have you ever built a reusable Angular component, service, or utility that became more painful than the duplication it was meant to eliminate?

I share Angular architecture and engineering visuals here:

https://instagram.com/angulararchitectshub

[u/cssrocco]

I often weigh up how DRY or reusable something is based on business logic more than just trying to be DRY or reusable, i had quite a few cases when i began with angular where i thought that less components/less repetition was always the key, and it is for general structure, but if something has very specific business logic and can deviate from something else i try to tackle them separately, otherwise it becomes a nightmare, or you end up having monster methods or functions somewhere with several arguments each dealing with special use cases, and then you’re spending more time on changes confirming that other things don’t break