Turning Figma Designs Into Reusable React Components
TIL that building each screen straight from its Figma frame produced pixel-accurate but unreusable components — the fix was designing the component API from the design system's tokens, not from any one screen.
The Problem #
Early screens on Clonify.io were built by opening each Figma frame and translating it directly into a one-off component — accurate to that screen, and structured in a way that made the next visually-similar screen a copy-paste-and-tweak job instead of a reuse of the first one.
Context #
The design had a real, if implicit, system behind it — consistent spacing scale, a small set of button and card variants — but each Figma frame presented that system pre-baked into pixel values rather than as named tokens.
What I Tried #
Kept building screen-specific components, reading exact pixel values (padding, font sizes, colors) off each frame as I went.
What Went Wrong #
Two visually similar cards on different screens ended up with slightly different padding values because I'd read them off two different frames rather than one shared source, and a later brand color tweak meant hunting down every hardcoded hex value across a dozen components instead of changing it in one place.
The Solution #
Before building more screens, extracted the actual design tokens (spacing scale, color palette, typography scale) from the Figma file into a shared theme, and built components against those tokens instead of against any individual frame's pixel values.
const theme = {
spacing: { sm: 8, md: 16, lg: 24 },
colors: { primary: "#0f172a", accent: "#38bdf8" },
};
// Component reads from the token system, not a specific screen's pixels
<Card padding={theme.spacing.md} accentColor={theme.colors.accent} />Why It Works #
A design file is usually a consistent system that individual frames merely express — reading pixel values per-frame reconstructs that system indirectly and inconsistently, while extracting the tokens once and building against them keeps every component provably consistent with the same source, and makes a system-wide change a token edit instead of a hunt-and-replace.
Lessons Learned #
"Pixel-accurate to this screen" and "reusable across screens" aren't the same goal, and optimizing for the first one first (which felt like the obviously correct order) actively worked against the second.
What I Would Do Differently #
I'd extract the token system from the design file before building the first component, not after noticing the same spacing value hardcoded slightly differently in three places.
Related Concepts #
Design tokens, theming systems, component APIs vs. screen-specific implementations.
Related content
Using Framer Alongside a Development Workflow, Not Instead of One
TIL that building the Clonify Framer plugin taught me Framer is a genuinely different target than a normal web build — its plugin runtime and code-component model don't map 1:1 onto React conventions.
Designing a Dispatch Management Dashboard for Real Operations, Not a Generic Admin Panel
TIL that a dispatch dashboard built around 'show all the order fields' overwhelmed the person actually using it — the redesign that worked started from what a dispatcher needs to decide, not what data exists.
useOptimistic auto-reverts on failure — a hand-rolled optimistic hook doesn't
TIL why React's useOptimistic hook doesn't need explicit rollback code when a server call fails, while a manual optimistic-update hook built on plain useState does.