SUMMARY:
Discover how creating a centralized React component library can eliminate code duplication, streamline maintenance, and significantly accelerate your team’s development workflow.
Table of contents
Introduction
We had five of them. Five different button components.
Each button used the same hex code, rounded corners, and hover state. Still, they sat in different parts of our codebase, with no connection between them.
At first, it didn’t seem like a problem. If someone needed a button for a new module, they just built one. It was quick, it worked, and we moved on. But when we had to update the hover animation everywhere, that’s when we paid the price. We felt the impact of every duplicate.
That was the moment we decided we’d had enough. We saw it was time to stop reinventing the wheel and start building a shared foundation.
The Problem That Creeps Up on You
Code duplication rarely announces itself. It creeps in slowly—a button here, a modal there, a loading spinner that looks just like another one a few folders away.
At first, each choice seems fine. But over time, you end up with a maintenance headache that slowly wears down your team. For us, fixing one bug meant tracking down every version of that component. Adding a new feature meant repeating the same work again and again.
We didn’t just need better code; we needed a single source of truth.
Our plan was simple: Build a central React library on top of Material UI, where every reusable UI component could live. We named it ogm-react-shared.
Suddenly, the workflow changed. Instead of writing 50 lines of CSS and JSX for a basic input field, we just did this:
import { Button, TextInput } from '@MensWearhouse/ogm-react-shared';
That single line replaced entire files. It lets the team focus less on building text boxes and more on creating a great user experience.
Using Atomic Design to Keep the Chaos Away
A shared library only helps if people can find what they need. To keep things organized, we used Atomic Design. This gave us a clear structure:
- Atoms: The tiny essentials. Buttons, labels, spinners.
- Molecules: Small groups. Think of a search bar (input + button) or a form field group.
- Organisms: Complex sections. Dashboard headers, data tables, or full lookup forms.
This structure made it easy for everyone, including new hires, to jump in and see exactly where each component belonged.
Shipping it as a Package
To make it official, we published it as an internal NPM module. That changed everything for us.
We no longer had to copy and paste folders between repositories. If a team wanted the latest UI, they just ran npm install. Now we had version control, so we could push updates without breaking other projects. Every team was finally working from the same foundation.
What Actually Changed?
The change was instant. Building a new screen went from taking half a day to just an afternoon. With the components already built and tested, we could focus on the logic and layout.
The app also started to feel like a single, unified product. The best part was maintenance. When we updated our button accessibility standards, we made the change in the library once. Every project got the fix with their next update. No more searching or wondering if we missed something.
A Piece of Advice: Don’t Wait
A shared component library isn’t a flashy architectural achievement. It’s the behind-the-scenes work that makes your daily life easier. It removes extra steps, stops duplication, and helps you move faster.
If you notice the same UI patterns showing up in different places, take that as your sign. You don’t need a perfect or detailed plan to begin. Start small, gather the components you already use, and put them in one place.
Your future self (and your sanity) will thank you.
Please contact us for more information.
Ready to stop reinventing the wheel and start building more efficiently? Explore our Application Development services to see how we can help your team modernize your development workflow and scale your digital experiences.