Frontend Quick Tips #3 Premature Generalisation - Story About One Fat Component
No one likes those big articles - that’s why we’re creating Quick Tips - short tips to change your developer's life from the moment you read them.
Those may be some patterns explained in JS code on real-life examples or some techniques for better code.
Problem?
A component takes so many properties that it's not clear what it actually does. It covers many use cases (in the below example, the component resolves 3 different cases).
There may be many reasons why your component takes so many props.
Maybe it was easy from the beginning but further changes from the client made it bigger?
Maybe there are a lot of cases to use this component?
Or perhaps you think it would be cool to have one component so you Don't Repeat Yourself (DRY)?
Solution?
For the above example - our component (ListOfIcons) tries to resolve all the issues which differ from each other.
It breaks the I from SOLID (Interface segregation principle) which means that we should create a simple component for each case, rather than use one big component for all cases.
Let's split this into:
By creating a feature-specific list, we ended up creating a simple component with only a few props (and it could be even more optimized!). All of our style-related props are now written inside styled components.
Now we only have to do so for another 2 cases and our code is much more readable.
Note:
What about DRY? Don't get me wrong, DRY is a good pattern, but when you have totally different issues, it's better to create separate solutions rather than extend the one-size-fits-all interface.
