Angular - How many components is too many components?

So, how should I divide my Angular/React components? Should a single input be considered a component? Is it worth it? Does it improve the code readability?

Comments

[Antonin J. (they/them)]

It depends on a few things:

1. What's the longevity of the project? Is it a long-term project or a one-off?
2. What's the expected growth of the application? Is this a small application or a big SPA?

At my job, we've been growing an AngularJS app (and subsequently an Angular rewrite/hybrid) and found a ton of use in having a separate input component. Why? Because you might want to tack on additional functionality/logic/styling that you'll want across the site. Eg:

1. What if you want your input to have a help icon that explains the purpose of the input? (eg. a freeform "username" field that explains what the username is for, or what the limitations are)
2. What if you want to optionally pass typeahead hints to your input field? (eg. a free form text field that gives you hints based on previous entries elsewhere)
3. What if you want to add validation across the site? eg. validation that checks for HTML tags

And so on.

In fact, we have a separate component for a dumb input, for an input that features a typeahead as hints, for an input that features typeahead as options, for an input that can only have numbers, and so on.

But would this be helpful on a smaller app? Probably not. Would we have built this out if the longevity of the app was only a few months? Maybe, but it's no guarantee.

[TheSlider2]

In our current project we've got this period component containing two date inputs, start and end. We're using it across the entire project in various situations and sometimes need to declare specific validators for some of the work-flows.
The problem is that this component is starting to require so many conditional validators and each of them is a complex check that we're now asking ourselves if it was a good idea to create it instead of having independent start/end inputs in each parent component with their own validators.

So yeah, it's nice to cut your project into small pieces but when one of your smaller piece starts getting bloated with unnecessary conditional code, then you know you've went too far.

[Antonin J. (they/them)]

Oh yeah! Absolutely. But that's when I'd split it based on functionality. Conditionals usually indicate that you're trying to force one thing to fulfill the role of many.

You can also invert the validation and have the parent be responsible (just like you mentioned).

In Angular, you could just do:

<MyInputComponent
(validate)="validateInput($event)"
[isValid]="isInputValid">
</MyInputComponent>

On change, the input component would emit the change for the validateInput to run and the parent component will then let the input know if it's valid or not. :)

[Fabian Holzer]

I personally prefer components to be small and dumb and absolutely do not bother having a lot of them. A components in Angular is merely a class, annotated with some meta-data. So all object oriented design principles and rules can and should be applied.

Components which do too much and which deal with multiple layers of abstractions have in my experience often turned out to be a lot more problematic than small ones. Even if the latter come at the - in my opinion negligible - cost of writing a little bit more of boiler plate code (which mostly concentrates in your NgModules).

[Dinesh Pandiyan]

I think it all comes down to reusability.

IMO, if you think a piece of code doesn't have any value standing on its own, then it doesn't need to be a component (arguably).

Input could be a component when

1. You could style your input the way you need and reuse it throughout your code.
2. You compose your input with validation or any other functional need and expose it as a single reusable component.

Input need not be a component when
You don't have the need to reuse it and will probably need it only once in your code (very unlikely scenario for input but you get the point).

I would suggest breaking down your code into as many components as possible because it will make your code look clean and readable but at the same time over componentizing everything is not recommended.