How to Build Faster with Reusable UI Components in React
For updated use-cases on building with React components read:
We all know that React components let you divide your UI into sharable design elements (button, form, form-field, table, spinner etc).
These reusable components are self-contained and have well-defined interfaces. As such, they can be reused to build more than one UI instance. Meaning, they can be shared and reused next time you build your application’s UI, or even a brand new application.
This saves time as you write less code, faster development, simpler codebase maintenance and less bytes which end up being moved from place to place.
But…
Actually reusing these components is easier said than done. It starts with the way you think, goes through component design, the tooling and platform you use to share and discover components, and down to the way you use them.
In this post, I’ll suggest some principles, methods and tools that can help your team share and reuse your components to build new apps faster. Let’s jump in.
Design for Composition
Before even trying to design a reusable components, we should ask ourselves: what is the smallest level of components that should be considered reusable?
Atomic design tells use that components can be divided and composed to create larger things. In software, much like in biology and physics, this means you can develop and change what you build much faster.
“Components let you split the UI into independent, reusable pieces, and think about each piece in isolation.”
But, should every level of the design be reusable?
For example, a table component is a great reusable molecule. But, a table-row might not be able to “live” outside of a table. While clear that “table” should be made reusable, should “table-row” also be designed for reusability?
Here’s my answer: can you reuse “table-row” when implementing a new table component tomorrow? can your friends use it in other parts of the app?
Probably not. Still, you should aim to design it in a way that can be used in a more than the specific table component you’re building right now. It’s good to aspire and think in reusability in a way abstract enough to contain both the smallest and the largest of structures.
Here are a few useful guides for designing reusable components in React:
- Atomic design with React and Bit: Simplify a Complex UI
- Designing Reusable React components
- Reusable Components in React- A Practical Guide
- Simple Code Reuse with Rect Hooks
- Reusing HOC with React
Share a Component “Lego Box” to Build Faster
So, we wrote some reusable React components, and even composed them in an application we’re building. Does that mean we now have a set of reusable components at our command? Not yet.
We still need to make our components reusable by sharing them to an outside source from which our team can find and use them to build more projects.
As the way we build components advanced, so did the ecosystem around it.
Today, tools built for component like Bit (open source) provide a much faster and more effective way to share, discover and reuse components between people, project and applications.
Built for components, Bit brings 3 things into your workflow which make it much easier to share and build with your components:
- Low overhead: You can share 100 components in a few seconds- as no code changes or refactoring are needed to make components reusable.
- Discoverability is brought to a whole new level with component collections, search, playground, isolated testing and more.
- Consumption is dynamic and flexible, as you can install components with NPM/Yarn -or- bring their actual source code into a new project to update changes, so that components can evolve over time.
Together, these component-specific advantages provide a faster workflow for sharing, finding and building applications with reusable components. You can think of it as sharing music with iTunes compared to using CD-Roms.
Creating a component collection your team can share and choose from means that everyone on your team can now access your joined component “Lego box” and use these pieces as composable parts when building something new.
You’re really Building a Design System…
Most teams work hard to create a design system to achieve better consistency, reduce user confusion, increase satisfaction and brand recognition.
Components have the power to create both a consistent UI and consistent UX.
Turning UI components into a bunch of Lego pieces provides more than just faster development: it creates your design system, your consistent UX/UI look and feel, and eventually your recognizable brand.
Then, this UI design system ends up being implemented as a React library which developers are asked to install it in every project they’re building. Common examples are Uber, Pinterest, Airbnb, Shopify, Walmart, Atlasssian and many others.
The things is, when you build with shared components, you don’t want to bring in the whole box when all you need is one piece. You also don’t want to work very hard to find the pieces you need, and make changes when needed.
Instead, you want to breed collaboration between your designers and developers, making your components a common ground to design, develop, evolve and use components when and where ever needed.
You can learn more about this workflow and balance here:
Thinking Components is an Everyday Strategy
I recently read a great post by Walmart Labs, describing their journey towards achieving reusability with React components.
They describe reusability not as a set of tools and standards, but rather as a development strategy which goes far beyond technical aspects.
In their experience, striving towards reusability means wiring the organization itself, or at least its R&D team, to think of everything they build as something that can serve other people and parts of the product.
This “API First” approach means that every team has the responsibility and commitment to create modular software which can work with other parts of your codebase, and can be used to compose more than one product or feature.
If you design reusable components it’s not enough. If you share them in a collection so that everyone can find and use them you might be 90% there, but it’s still not enough. You also need to communicate.
In our own codebase, we use components everywhere. We share over 300 components (using Bit) in our Node.js microservices. We have a collection of dozens of React UI components used in our apps. We even designed a search feature based on components, which lets us easily add new algorithms.
We ask people in our team to think in components, design components to be reusable in every part of our stack, share the components they build with others and talk to each other to make sure we collaborate to build faster.
This isn’t only a faster workflow, it’s a culture, a development strategy and a thinking process which should become part of everyday’s life.
Conclusion
The future of the composition of software through smaller components is unfolding before us, through modular thinking. We see this in libraries like React and Vue in the frontEnd, through GraphQL and Apollo in the middle, and through Node.js and even Docker in the backend.
React, its philosophy and capabilities have the potential to make the development of our application a bit more like building with reusable Lego pieces: faster, simpler and easier to develop.
In the end, I hope you’ll be able to create a collection of your reusable components, and use them as building blocks to build the apps you imagine. That will be a great step in to the future, or at least a beginning.
