Converting Figma designs into production-grade React components sounds straightforward, but it consistently breaks down in real engineering workflows.
The reason is simple: Figma describes a UI visually, while React applications are built on architectural, behavioral, and project-level decisions that the design file doesn’t contain.
That gap is why every approach – plugins, code exporters, even MCP-powered tools produces output that looks correct but never matches the structure of an actual React codebase.
Teams still end up rewriting component boundaries, fixing styling, reorganizing files, and re-implementing logic that the design could never express.
This post breaks down why traditional Figma-to-React methods fail in production environments, and why a project-aware approach like Kombai finally closes the gap.
Why Traditional Figma-to-React Tools Don’t Work
Most existing solutions follow the same pattern: read Figma, map layers to JSX, and apply styles. This works for demos and prototypes, but breaks down in real-world complex workflows.
1. Plugins Understand the Design, Not the Codebase
Plugins only have access to what exists inside a Figma file — layers, layout rules, styles, tokens, and component instances. That’s useful for generating isolated UI, but it leaves out the context that actually shapes a React application.
A design file doesn’t describe how components are organized in your codebase, how files are structured, which parts should be reused, or how data and interactions flow through the app.
Because that information isn’t available, the generated output ends up reflecting the visual layout rather than the project’s architecture.
The result is usually code that looks correct, but doesn’t fit. Developers often have to rewrite large parts of it just to make it align with existing patterns, naming, and data flow.
2. Figma MCP Improves Access, Not Interpretation
Figma’s MCP server provides a more structured and reliable access to design file data. It helps models read nodes, styles, and metadata more consistently.
However, MCP does not provide information about the engineering context of a project. It does not describe:
- how components relate to each other in the codebase
- which UI sections map to existing shared components
- how state, data, or interactions should be handled
- what responsive behavior does the project expects
- how routing or layouts are implemented
MCP makes the information of the design file more accessible, but it does not address how that design should map to the structure, patterns, or conventions of a specific React application.
The gap remains: the visual data is available, but the architectural context needed for production-ready components lives in the codebase.
What Teams Actually Need: Project-Aware React Code
When engineers integrate a new UI into an existing React codebase, they don’t want JSX that mirrors a Figma layer tree.
They want components that fit into their project seamlessly. That means:
- following the team’s folder structure
- using the correct design primitives or UI library
- respecting naming conventions
- mapping to existing data flow
- handling state the way the project expects
- generating code that feels like it was written by the team
Figma doesn’t know if you're using Tailwind, CSS Modules, custom tokens, or a component library.
It doesn’t know which elements should be split into components or which should stay inline. It doesn’t know what’s interactive or where data lives.
So traditional tools can't deliver production-ready code — not because they’re bad, but because the design file simply doesn’t contain the information needed.
The Modern Figma to React Workflow with Kombai
How Kombai Solves the Problem
Kombai approaches Figma-to-React with a focus on project context, not just the visual layout.
1. Kombai interprets design like an engineer
Kombai analyzes layout rules, spacing, constraints, variants, visibility, and design tokens to understand how the UI is intended to work — not just how it looks.
This lets Kombai generate component and layout structure based on how the design is meant to work, not just how it’s layered in Figma.
2. It works with real-world Figma files
Design files aren’t always consistent. Kombai handles common issues like mixed component versions, uneven spacing, unused layers, partial auto-layout, and naming drifts.
Kombai is built to work with the imperfect, messy files teams actually use every day.
3. Kombai understands your project before generating code
Before writing components, Kombai reviews your repo: existing components, folder structure, naming patterns, utilities, primitives, and layout conventions so the code integrates cleanly instead of introducing new patterns.
The result
Kombai aligns the design intent from Figma with the structure of your React codebase, producing components that feel native instead of making you start from scratch.
Setting up a React Project
Now, let's see this in practice and try converting a Figma design to a React project. First, open a React project or create a new one. For creating a new one, you can use the following command:
npm create vite@latest
This will scaffold a new React project with vite where we will generate React code from the Figma design.
Bringing Figma Designs into Kombai
To bring your design into Kombai, first you need to connect your Figma account to Kombai, and then you can provide the design link just as you do with any other tool.
Open Kombai and click the Figma icon at the bottom right:
Next, click the Connect Figma button as shown below. If you already have it installed, it will show Reconnect Figma for you:
Clicking the connect button will prompt you to open your Figma and give access to Kombai.
Complete the authentication, and you have Figma connected.
Next, copy the URL of your design file from Figma and add it to the Figma URL of the Kombai panel:
For our example, we will use this Figma template:
Guide Kombai with context (using Agents.md)
After adding your Figma design, the next step is helping Kombai understand how you want the project structured. Kombai reads this from an AGENTS.md file placed at the root of your repository.
Think of this file as a small set of project-level instructions. It tells Kombai:
- where pages and components should live
- which UI library or primitives to use
- naming conventions
- styling approach (e.g., CSS Modules, Mantine styles, Tailwind classes)
- layout or architectural expectations
- any patterns that should be consistently followed
You don’t need a long specification – just clear, high-level rules. You can also generate it using ChatGPT or Gemini by giving a screenshot of the design.
Once this file exists in your repo, Kombai automatically picks it up and applies these rules every time you generate code.
Configuring your Tech Stack
Once Kombai knows how your project is organized, the next step is to tell it what stack you want the generated code to use.
Kombai supports a variety of stacks, and the configuration is also simple.
For our example, the stack we are going to use is:
- Framework: React 19, JavaScript
- Styling: Tailwind v4
- Component Library: Mantine v8
To configure this, open the Kombai panel in your IDE and select the Tech Stack option from the bottom:
Choose your preferred stack and save the configuration.
Generating production-ready code
Now that everything is done, let’s generate React code from our design.
Here’s the prompt I used:
“Generate a React application from the provided design using Tailwind CSS. Make it fully functional.“
And here’s the result:
In the next section, we will evaluate Kombai’s output in detail
Analyzing Kombai’s output
Kombai maps Figma elements to React components
Kombai analyzed the design and abstracted all the important elements into their own reusable components.
This was our original design:
As you can see here, we have elements like Sidebar, stats cards, customers page, etc. Kombai mapped each of these elements to clean React components:
- Sidebar →
Sidebar.jsx - Top bar →
Header.jsx - Stats row →
StatsCards.jsx - Data table →
CustomerTable.jsx - Status badge →
StatusBadge.jsx
Kombai produces a clean data layer
Kombai didn’t hardcode any mock values into the UI. Instead, it created a dedicated mockData.js file with structured generators for customers, stats, and active users – exactly how a real dashboard separates data from presentation.
Customer data is clean, typed, and centralized.
The customer list isn’t hardcoded inside CustomerTable.jsx. Kombai created a clean base dataset:
{
id: 1,
name: 'Jane Cooper',
company: 'Microsoft',
phone: '(225) 555-0118',
email: 'jane@microsoft.com',
country: 'United States',
status: CustomerStatus.ACTIVE
},Then it expanded that into 32 records with variations like company, country, email, and even status logic:
allCustomers.push({
...baseCustomer,
id: i,
name: `${baseCustomer.name.split(' ')[0]} ${baseCustomer.name.split(' ')[1]} ${Math.floor((i - 1) / 8) + 1}`,
company: companies[companyIndex],
email: baseCustomer.email.replace('@', `${i}@`),
country: countries[countryIndex],
status: i % 3 === 0 ? CustomerStatus.INACTIVE : CustomerStatus.ACTIVE
});
This means the table actually behaves like a real data table (scrolling, paging, distribution of states) instead of repeating rows.
Stats aren’t hardcoded either — they’re generated
The KPI cards also don’t contain inline numbers or labels. Kombai gave them structured objects:
{
title: 'Total Customers',
value: '5,423',
trend: { value: 16, isPositive: true, label: '16% this month' },
iconType: 'users'
}
Even small UI blocks get their own dataset
Active users (avatars in the side widgets) live in their own function:
export const generateActiveUsers = () => {
return [
{ id: "1", avatarUrl: "/avatars/active-user-1.png", name: "User 1" },
{ id: "2", avatarUrl: "/avatars/active-user-2.png", name: "User 2" },
{ id: "3", avatarUrl: "/avatars/active-user-3.png", name: "User 3" },
{ id: "4", avatarUrl: "/avatars/active-user-4.png", name: "User 4" },
{ id: "5", avatarUrl: "/avatars/active-user-5.png", name: "User 5" },
];
};
A lot of generators would hardcode these right into the component, but Kombai didn’t.
Why this matters
Because your components — CustomerTable, StatsCards, Header, etc. — never touch raw strings or make up their own data. They only render.
All of the important logic is centralized in one place. That’s how real dashboards are built.
Kombai respects the requested stack
Kombai installed all the required packages correctly – React, TypeScript, Mantine.
Kombai didn’t just install Mantine; it actually built the app around it. The theme lives in a dedicated theme.js file using createTheme, with custom colors and typography:
const theme = createTheme({
fontFamily: 'Poppins, sans-serif',
primaryColor: 'purple',
colors: { purple: [...], green: [...], red: [...] },
});That theme is then applied correctly at the root:
<MantineProvider theme={theme}>
<Box className="flex h-screen bg-[#fafbff]">
<Sidebar ... />
<Box className="flex-1 overflow-auto">
<Stack gap={0}>
<Header ... />
<StatsCards stats={stats} />
<CustomerTable ... />
</Stack>
</Box>
</Box>
</MantineProvider>Inside the UI in components like CustomerTable, Mantine components are used consistently:
<Paper radius={30} p="xl" className="flex-1 min-w-[280px]">
<Group align="flex-start" gap="lg">
<Stack gap="xs">
<Text fz={14} fw={400}>{stat.title}</Text>
<Text fz={32} fw={600}>{stat.value}</Text>
</Stack>
</Group>
</Paper>As a result, you get a codebase that matches the requested stack with no unwanted and additional packages, styling, or framework drift.
Visual and functional fidelity
Kombai did a good job of matching the design. The layout from Figma shows up exactly how we expect it — the sidebar, header, stats cards, and table all look and feel like the original screen instead of a loose interpretation.
It also picked up the functionality in the design correctly. The search bar works, the filter correctly sorts the customers, and pagination shows the next set of content just as intended.
Conclusion
Kombai doesn’t try to guess your entire app from the design. It reads what the design expresses, learns what your project expects, and merges the two into components that work with your existing codebase instead of being isolated components.
If you build React applications from Figma designs, Kombai can move the process from slow, manual rebuilding to something far more aligned with how modern teams work.