Building React Components: Turning UI Designs Into React Components
Learn how to design and architect React Components based on User Interface Designs of Components and Pages. (5 minutes)
You’ve probably seen User Interface Designs, especially if you're not working alone.
When creating a new page or screen in large companies and organizations, we first receive mockups and wireframes outlining the desired look and feel.
As Senior React Engineers, it’s crucial to translate these mockups into feasible React components and pages so the UI designers and stakeholders are happy.
If you do it right, you increase your impact, and you’re seen as a reliable engineer who can get the job done.
In this article, I’ll share my approach to breaking down UI Designs into reusable React components and explore two use cases.
The Importance of Translating UI Designs Into React Components
you can save your and your team’s time by reusing React components in many places
you get a more flexible codebase because of the granularity of the components
consistent look and feel across different pages
good reusable components mean a manageable and understandable codebase
creating a positive impact on the team and the company
My Approach: Divide and Conquer
In my experience, I’ve found the Divide and Conquer technique to work pretty well for breaking down a complex design into reusable React components.
The idea is to divide a large problem, page, or design into smaller parts that are easier to handle.
When it comes to React components, this means creating multiple smaller, self-contained components, each doing one thing well, so you can combine them to create bigger components and pages.
Let’s get more practical and see what this means in the real world and projects.
Translating Component Design Into React Components
Let’s begin with the easier job - turning a design of a UI element into a React component.
That’s an example of a real project I’ve worked on in the past.
The screenshot illustrates a <Card /> component.
Let’s break it down.
<Card />, <CardHeader />, <CardBody />, and <CardFooter />
By following the divide and conquer algorithm, we can break down the design into at least least 3 main parts - Header, Body, and Footer.
The <Card /> component will contain the other three components and main styles.
How do I know?
We can’t break it any further, except the Header. So let’s continue with it.
Breaking <CardHeader/> Into <CardTitle /> and <CardSubtitle />
Ask Questions to Clarify Requirements
Depending on the design requirements, we might want to clarify whether the Title and Subtitle will appear always together inside the Header or we might have only the Title.
However, sometimes designers might not be aware of the future use cases and how the design will evolve, so it all depends on our judgment and expertise.
Remember: Embrace Software Entropy.
In our case, I decided to split the Title and Header into two components because the additional work of doing it is not a lot but the benefits are higher.
I get a more flexible Card Header with/without Subtitle for the cost of a few extra lines.
Do We Need All Components
The short answer is no, we don’t.
However, if we put everything inside one big <Card /> component, we lose flexibility and reusability.
Our component won’t be flexible enough to fulfill other use cases like:
Card without Header
Card without Footer
Card without Subtitle
Card with only Body
etc.
It’s important not to over-engineer the components while making them flexible enough to adapt to the changing requirements.
The balance is thin, so think twice before moving one.
Now, let’s move to a more complex design - the one of a page.
Translating Page Design Into React Components
The approach is the same.
We will break down the page into multiple parts by following the Divide and Conquer principle until we can’t break it further.
The only difference is that we might end up with more reusable components.
Start From The Outside to The Inside
By following the divide and conquer technique, we broke down the page into 3 main parts:
<DiscoveryLayout />, representing the whole page
<Hero />, representing the hero and CTA section
<Feature />, representing the features section
Breaking Down the Hero Section
We break the <Hero /> into two columns, so we’re flexible with the responsiveness of the page.
On the left side, column 1, we can split it further into 3 sections.
It’s not necessary to create separate reusable components if they won’t be reused across other pages.
We can only split it semantically, so it’s easier to follow, navigate and understand the bigger component (<Hero />).
On the right side, column 2, we can reuse the <Card /> component with only Body.
That’s the beauty of creating multiple reusable components.
We’re flexible enough to tackle different use cases and requirements.
Breaking Down the Feature Section
For this section we can follow a similar approach.
I believe you grasped the idea and the approach
📋 Recap
being able to translate a UI design into reusable and flexible React components can save your and your team’s time
use Divide and Conquer technique to break down complex designs into smaller pieces
start from the outside of the design to the inside of it
ask questions to clarify and understand the requirements
keep components flexible so you can adapt to the constant changing requirements and use cases
That's all for today. I hope this was helpful.
How do you approach UI Designs? Share your experience and process in the comments 👀
How I can help you further?
Become the React Architect at your company! 🚀
👋 Let’s connect
You can find me on LinkedIn, Twitter(X), or Bluesky.
I share daily practical tips to level up your skills and become a better engineer.
Thank you for being a great supporter, reader, and for your help in growing to 17.4K+ subscribers this week 🙏
You can also hit the like ❤️ button at the bottom to help support me or share this with a friend. It helps me a lot! 🙏
This shows for me the difference between consumer vs producer (in this case for frontend development). A producer looks further than the rest of the people into how something is made
This is a great breakdown of the overall approach, Petar!
> It’s important not to over-engineer the components while making them flexible enough to adapt to the changing requirements.
This is where time can be lost, especially if multiple developers have different opinions. Sometimes, I felt we were talking too much about how detailed we should go instead of just shipping the thing. How would you decide when you feel the conversation isn't paying off anymore?