Reusable components sound like the perfect solution for building any application: write once and use everywhere, with a single source of truth that we can use to make global changes by modifying just one component.
But when the project gets huge with lots of complexities, then managing that component will become a nightmare. That day, I learned that over-reusability can quietly destroy our codebase.
As a developer, we are often told to follow:
- Make components reusable
- Avoid duplication
- Keep things DRY ( Don't repeat yourself )
But at the end, instead of a reusable component, we end up with a "Universal component" that is becoming impossible to maintain.
Let's dive deeper into this.
Lets support we just started a project and we need a button with these basic features
- Have labels
- Each button has a different type of variation ( Filled, Outlined, text )
- Each button has a different type of color variants ( Primary, Secondary, Accent )
- Can have links
- Can be disabled
- Can be fullwidth
- May have a loading state
- Support adding an icon with icon position ( after/before text)
<BaseButton
label="Submit"
type="submit"
variant="primary"
size="large"
icon="check"
iconPosition="right"
loading="true"
disabled="true"
fullWidth
/>
It still looks manageable, as we already saw this type of button in UI library like material design. Till now i will be happy with what i achieved, it looks pretty good to me, we can do almost everything with our global button component.
Now lets move to the part where things get started dirty.
Now new requirements came up, and we started to modify our button component.
Requirement 1
A new screen introduced in the app using a completely new button with a different color, size, and icon position on top.
Now, instead of creating a new component, we decided to enhance our button component by introducing new props for custom color and custom classes. This will add a few more lines of code, which seems okay for now.
<BaseButton
color="#115eae"
class="h-48 px-20"
iconPosition="top"
/>
Requirement 2
A new feature of the floating button has been introduced, and we still decided to use the same button component
Now, for this, we need to add more conditions to remove the label and show the icon aligned centre. This will make the code messier and unmanageable.
More requirements will come, and we continue to enhance our existing button, and in the end, we end up with a monster component.
The hidden costs
Props Explosion
Too many props, which makes the component hard to read, easy to misuse by new devs and difficult to debug
Mixup of logic
Now it's hard to differentiate which part will handle the UI/basic features and which part stores the advanced functionality
Risk on Bugs
Now, when multiple things are connected to each other, then making the change in a small part may affect the overall implementation, which results in bugs in unrelated features
Slower Development
One component contains so many lines of code, which we need to go through every time we need to update something in this component
The Real problem in not reusable component but the mindset to handle everything with the same resualble component. Insetad of "Let’s make this reusable", we should avoid adding unrelated changes to resualbe component or making a different component by using existing features of the reusable component.
We don't need to make our resusable component too smart to manage everything by itself, instead stick with its basic feature. And one more thing I want to add is don't create resualbe component until we need to repeat someting 2 or more times and its purpose is clear to us.
The solution to the problem is splitting new features into multiple components instead of using the same component.
Instead of using the same button component, we can create different components like <FloatingButton> and <NotificationButton>.
A simple rule i follow is if a component needs more than 5-6 props, then its probabluty handing too many features all by itself. Reusable components are powerful and awesome if we use them in a proper manner because as the project grows, team changes, requirement changes and code evolves, and if we handle too much in the same component, then it's definitely gonna explode on us.;
