I argue against overly generic components.
I worked on multiple enterprise applications where the sole approach to front-end engineering was to "make it as generic as possible". This approach created unmaintainable front-end code monstrosities that took days on end to debug the simplest flows. Multiple engineers could not figure out where in the chain of state that passed through 20 or 30 generic components the bug occurred.
After surviving a few of these companies, I decided to strictly apply for Backend/Data/DevOps positions, and my life has been easier since.
The goal is to find a balance between over-generalizing your components to the point of technical debt or creating specific components for different scenarios. Some components should be coded for specific use cases, there is no way around that.
Edit: Next time please use code blocks instead of images, they are much easier to read !
Sure, I understand your point. The key word for me here is not generic: it's composition.
I found lots of components which are coupled to the use case they solve, which in some cases could work just fine (e.g. a very specific component you know that it's going to be used just in one place). But, If you have a component that you'll probably use in more that one place (e.g. a dropdown component), making it composable it's the approach that I'd recommend.
Right, I agree. The conclusion I think we both will agree on is that components that logically should be generic should be generic (e.g. a dropdown menu). With that being said, specific components should not be generic, and one should not chase generality as a development goal, but be logical, and efficient.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I argue against overly generic components.
I worked on multiple enterprise applications where the sole approach to front-end engineering was to "make it as generic as possible". This approach created unmaintainable front-end code monstrosities that took days on end to debug the simplest flows. Multiple engineers could not figure out where in the chain of state that passed through 20 or 30 generic components the bug occurred.
After surviving a few of these companies, I decided to strictly apply for Backend/Data/DevOps positions, and my life has been easier since.
The goal is to find a balance between over-generalizing your components to the point of technical debt or creating specific components for different scenarios. Some components should be coded for specific use cases, there is no way around that.
Edit: Next time please use code blocks instead of images, they are much easier to read !
Sure, I understand your point. The key word for me here is not generic: it's composition.
I found lots of components which are coupled to the use case they solve, which in some cases could work just fine (e.g. a very specific component you know that it's going to be used just in one place). But, If you have a component that you'll probably use in more that one place (e.g. a dropdown component), making it composable it's the approach that I'd recommend.
Thank you very much for the feedback :)
Right, I agree. The conclusion I think we both will agree on is that components that logically should be generic should be generic (e.g. a dropdown menu). With that being said, specific components should not be generic, and one should not chase generality as a development goal, but be logical, and efficient.