Frontend Quick Tips #3 Premature Generalisation - Story About One Fat Component

Bernard Klatka

Apr 19, 2021 • 2 min read

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

Premature Generalisation

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:

Premature Generalisation

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.

Premature Generalisation

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.

More posts by this author

Bernard Klatka

Codestories Newsletter