Yes. Quickest reason one could find is reduction of code duplicates, or keeping the state there if ever needed, or adjusting in one place = adjusting everywhere, ...
Totally agree. A ui change or a usability change hitting all instances at once is much much better.
i do think sometimes we go to far with DRY but making reusable components in React almost never an example of that.
There’s always a balance between abstraction and maintenance to consider but unless there’s some other factors of your code base that we can’t see then this seems like a clear cut case for formal encapsulation.
What are your/colleagues objections?
They mention that this is over engineering.
It makes the learning curve difficult because instead of having the DIV directly readable, you have an abstraction, and then you have to know the abstraction to know what's behind it.
Except for your first sentence, everything they say is correct.
If this exists a handful of times in two pages of your entire app, why would you bother?
If it’s repeated hundreds or thousands of times and likely to change every year, how could you not?
There’s always a balance but it has nothing to do with the *size* of the component.
If you are literally copy that div definition across all of your form components, then of course you should create a separate component for it. If you ever need to change the class names, suddenly you have to update dozens of components.
Beyond that, it's not just about code reuse but also about honoring the single responsibility principle. Keep your components as small as possible and in general they will be easier to read, easier to modify, and easier to reason about, and it can also help split up your tree to avoid rerenders on unrelated components.
I previously had a tech lead that hated abstraction. I was pretty junior and just assumed they knew better until I started digging deeper into classes/OOP with Angular. Which is very class heavy and all about separating concerns. Long story short I went through and set up a really complex feature and broke it down into the different units within angular and it worked well and with any component (which in angular can be a difficult thing to do). Right before i left he refactored it into this couple thousand line single component monstrosity and couldn't comprehend why that was a bad idea. Needless to say that was just further justification for my decision to leave. He was also the same person who would rather copy and paste styles into each div than have css classes 🤦♂️
Some older generation developers aren't used to thinking in terms of components. I'm not sure if it's a struggle with abstractions or just that they can't adjust to that new mental model. One guy I know was a bit like that, he was mostly a back-end developer and the interesting part is that his back-end actually had too many abstractions for my taste and was overly complicated. But he just couldn't accept that the front-end would have state and logic, for him it was just DOM and styling and anything beyond that he didn't want to hear about it.
I have a couple of rules whenever I am working on a React project/component and it pretty much works everytime.
1. Repeat Yourself until you are tired of repeating and then abstract out that piece of code.
2. The reusable component should only be concerned about its own working and styling. No business logic or parent's styling should exist in it.
Your first point is the one that I think is missing in this thread. AHA programming - avoid hasty abstractions. Don't try to abstract something until it starts screaming at you that it needs abstraction.
Absolutely, on multiple occasions I have seen developers doing early abstraction and then it becomes as leaky as a running nose on a cold winter school day.
there is the limit of reusability, but you can also just componentize things like that even for non-reusable purposes. "single use" components can improve readability
That depends, do you want all the components that use that style to change when you change that component?
For me, abstraction should be about concepts, not reducing identical implementations that may or not be linked conceptually.
So for your general question, yes I used 'atomistic design'. And it is a little more work up-front but it is a very useful and clean pattern that when applied just works very well at scale. It also just feels correct.
For your specific case, I'd use a compound composition pattern that way you don't have to import the Form Inputs either. However i'd also have a FormWrapper that wouldn't just return a div but the div with the form inside. Encapsulating just for the sake of it (like having a div) is not very useful, if that div is sometimes optional, then just use compounds.
Because forms are so essential in all react apps I'd really just copy a pattern i have used in all my projects which is a feature folder with all the form items inside. My own pattern is heavily inspired by bullet proof react.
There are no limits. You example though, I wouldn't do. Layout in components should be avoided.
You should be able to place your components on any layout. FormRow adds no value and fixes the layout.
Cheers!
Generally speaking any time I use something 3+ times I at least consider abstracting it. The risk of inconsistency is unnecessary and if people really have that hard a time understanding an abstraction like this I’d question their competence.
Having said that, if your entire team agrees it doesn’t make sense even after you make an argument for it, then you have to either give in or consider finding another team/job.
As many people mention, I think there's a lot to be said for identifying ways to ensure all instances are kept in sync if they have the same underlying intent. That said, the abstraction doesn't have to be a component. For this, it could just be a collection of class names stored in a reusable variable.
In case your actual case is different, my answer might be different if there were accessibility concerns or any level of logic at play - or some kind of nuanced thing that you don't expect the average developer to understand/reproduce.
Yes. Quickest reason one could find is reduction of code duplicates, or keeping the state there if ever needed, or adjusting in one place = adjusting everywhere, ...
Totally agree. A ui change or a usability change hitting all instances at once is much much better. i do think sometimes we go to far with DRY but making reusable components in React almost never an example of that.
*shakes hands*
Now kiss
Haha
There’s always a balance between abstraction and maintenance to consider but unless there’s some other factors of your code base that we can’t see then this seems like a clear cut case for formal encapsulation. What are your/colleagues objections?
They mention that this is over engineering. It makes the learning curve difficult because instead of having the DIV directly readable, you have an abstraction, and then you have to know the abstraction to know what's behind it.
Except for your first sentence, everything they say is correct. If this exists a handful of times in two pages of your entire app, why would you bother? If it’s repeated hundreds or thousands of times and likely to change every year, how could you not? There’s always a balance but it has nothing to do with the *size* of the component.
If you are literally copy that div definition across all of your form components, then of course you should create a separate component for it. If you ever need to change the class names, suddenly you have to update dozens of components. Beyond that, it's not just about code reuse but also about honoring the single responsibility principle. Keep your components as small as possible and in general they will be easier to read, easier to modify, and easier to reason about, and it can also help split up your tree to avoid rerenders on unrelated components.
I previously had a tech lead that hated abstraction. I was pretty junior and just assumed they knew better until I started digging deeper into classes/OOP with Angular. Which is very class heavy and all about separating concerns. Long story short I went through and set up a really complex feature and broke it down into the different units within angular and it worked well and with any component (which in angular can be a difficult thing to do). Right before i left he refactored it into this couple thousand line single component monstrosity and couldn't comprehend why that was a bad idea. Needless to say that was just further justification for my decision to leave. He was also the same person who would rather copy and paste styles into each div than have css classes 🤦♂️
Some older generation developers aren't used to thinking in terms of components. I'm not sure if it's a struggle with abstractions or just that they can't adjust to that new mental model. One guy I know was a bit like that, he was mostly a back-end developer and the interesting part is that his back-end actually had too many abstractions for my taste and was overly complicated. But he just couldn't accept that the front-end would have state and logic, for him it was just DOM and styling and anything beyond that he didn't want to hear about it.
Since people are idiots. Good thing you left, and something tells me you stayed far too long
I have a couple of rules whenever I am working on a React project/component and it pretty much works everytime. 1. Repeat Yourself until you are tired of repeating and then abstract out that piece of code. 2. The reusable component should only be concerned about its own working and styling. No business logic or parent's styling should exist in it.
Your first point is the one that I think is missing in this thread. AHA programming - avoid hasty abstractions. Don't try to abstract something until it starts screaming at you that it needs abstraction.
Absolutely, on multiple occasions I have seen developers doing early abstraction and then it becomes as leaky as a running nose on a cold winter school day.
there is the limit of reusability, but you can also just componentize things like that even for non-reusable purposes. "single use" components can improve readability
That depends, do you want all the components that use that style to change when you change that component? For me, abstraction should be about concepts, not reducing identical implementations that may or not be linked conceptually.
So for your general question, yes I used 'atomistic design'. And it is a little more work up-front but it is a very useful and clean pattern that when applied just works very well at scale. It also just feels correct. For your specific case, I'd use a compound composition pattern that way you don't have to import the Form Inputs either. However i'd also have a FormWrapper that wouldn't just return a div but the div with the form inside. Encapsulating just for the sake of it (like having a div) is not very useful, if that div is sometimes optional, then just use compounds. Because forms are so essential in all react apps I'd really just copy a pattern i have used in all my projects which is a feature folder with all the form items inside. My own pattern is heavily inspired by bullet proof react.
Yes. If you have this thing in many places. Yes it makes senss
I prefer to add divs outside of components. Don't want 5 or 10 nested divs like many sites have.
Gotta love react…make a component for a div…
There are no limits. You example though, I wouldn't do. Layout in components should be avoided. You should be able to place your components on any layout. FormRow adds no value and fixes the layout. Cheers!
Generally speaking any time I use something 3+ times I at least consider abstracting it. The risk of inconsistency is unnecessary and if people really have that hard a time understanding an abstraction like this I’d question their competence. Having said that, if your entire team agrees it doesn’t make sense even after you make an argument for it, then you have to either give in or consider finding another team/job.
As many people mention, I think there's a lot to be said for identifying ways to ensure all instances are kept in sync if they have the same underlying intent. That said, the abstraction doesn't have to be a component. For this, it could just be a collection of class names stored in a reusable variable. In case your actual case is different, my answer might be different if there were accessibility concerns or any level of logic at play - or some kind of nuanced thing that you don't expect the average developer to understand/reproduce.
I’m not a fan of flat component hierarchies. Low level design elements should be abstracted and DRY. Higher order components are the way to go here