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?
For further actions, you may consider blocking this person and/or reporting abuse
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?
For further actions, you may consider blocking this person and/or reporting abuse
alexandre-emmanuel -
Jai Bhullar -
Guddu Patel -
Rizèl Scarlett -
Top comments (5)
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
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:
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: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)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.
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.
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:
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. :)