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.

 

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).

 

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.

Classic DEV Post from Jan 3

Conversation with an Author - Ali Spittel

Malik and Dan sit down to talk shop with Ali Spittel

Tiago Suzukayama