Angular Anti pattern — Creating too many components
Introduction
Breaking down an App screen or state components into smaller ones introduces complexity.
Ideally, the parent component should manage all API requests.
It sends the object to be manipulated to the child component that modifies it and passes back another object through a function call. This function runs an API request such as insert, update or delete.
Principles
Principles to cater for:
- Avoid side effects e.g. modifying shallow copy objects references the original ones
- One function does one thing
- Declarative and self descriptive codes
- Loose coupling
- DRY (Don’t Repeat Yourself)
The aim of these principles is to be able to change codes relatively easily without regressions.
Complexity
At the end of the day, experience trumps theory.
For example, in Angular (and React) it’s recommended to break elements into child components.
However, in doing so, a huge amount of complexity is introduced for simple CRUD operations.
A child component is basically a function that should be doing only one and one thing. It’s not supposed to deal with API requests. Otherwise, if a screen has 100 elements, you make at least 100 API get requests on load while in reality the parent should be doing only 1 and either pass through each component as needed or use a central store like ngrx.
Anti-Pattern
I consider this amount of complexity as an anti-pattern in Angular.
Unless an element is going to be reused, it’s simpler to avoid creating a child component. But as in YAGNI (You Aint Gonna Need It), most of the times, you are not going to reuse it.
And if a screen has too many elements, the design is bad.
Ideally, it should have 5 to 7 major elements.
