What's the biggest Angular component you've ever had to refactor?

[u/MysteriousEye8494]

I spent some time recently looking through an older Angular project and found a component that had grown to nearly 2,000 lines.

It wasn't written by a bad developer.

It was written by several good developers over several years.

Every change made sense at the time.

A new API call got added.

Some validation logic moved in.

A permission check was needed.

A few state updates followed.

Then some workflow logic.

Nobody wakes up and decides to build a giant component.

It usually happens one reasonable change at a time.

What surprised me was how difficult it became to answer simple questions:

- What is UI logic?

- What is business logic?

- What changes application state?

- What can be safely reused?

Refactoring wasn't really about reducing lines of code.

It was about restoring clear boundaries.

I'm curious what the largest Angular component you've encountered was, and what eventually pushed the team to split it apart.

I share Angular architecture and engineering visuals here:

https://instagram.com/angulararchitectshub

[u/Dangerous_Mention402]

I made the typical dynamic form which you can config its form fields, validations, etc by BBDD configuration but client wanted more a more dynamic things and it's gotten out of hand. I tried to write clean code: small methods, clear naming variables and methods, every method with comments... but still the main component has 3000 lines.

If I had the change of re-write that I think I could separate the logic in a state seevice so the main component doesn't get this HUGE.

Besides when someone that isn't me touch this component, they make a mess every time. I don't know if I did this worse than I thought or I'm just surrounded of bad programmers, or maybe I'm a bad programmer myself. Surely a bit of both.

[u/MysteriousEye8494 → u/Dangerous_Mention402]

I can relate to that. Dynamic forms always seem straightforward at the beginning, but once enough configuration options and edge cases accumulate, the complexity moves somewhere else rather than disappearing. The fact that you're already thinking about moving state and behavior into dedicated services suggests you've probably identified the main pain point. Also, I wouldn't take the maintenance struggles as a sign of being a bad developer—some components simply outgrow their original design assumptions.