DEV Community: Norbert Madojemu

[Boost]

Norbert Madojemu — Wed, 27 May 2026 00:11:06 +0000

Norbert Madojemu

May 26

I Built a Screenshot-to-React Generator in 3 Hours

#react #go #ai #webdev

3 min read

I Built a Screenshot-to-React Generator in 3 Hours

Norbert Madojemu — Tue, 26 May 2026 23:58:35 +0000

I got tired of translating Figma screens and UI screenshots into JSX before I could touch any real frontend work — routing, state, architecture, the stuff that actually matters. So I built a tool to do it for me.
Drop a screenshot. Get a live, rendered React + Tailwind component. Streaming. In your browser. No build step.
Here's how it works and what broke along the way.

The Stack

Next.js 14 — frontend, split-panel UI
Go — backend, image compression, SSE streaming
Claude API (claude-sonnet-4-5) — vision + code generation
Babel Standalone + Tailwind CDN — zero-build iframe preview
localStorage — conversion history

How It Works
Screenshot → Go (compress + resize) → Claude Vision (streaming) → SSE → Next.js → iframe preview

The Go backend compresses the image to under 5MB, base64 encodes it, and opens a streaming connection to Claude's API. Each text delta gets forwarded to the browser as a JSON SSE event:

data: {"delta":"import"}
data: {"delta":" React from 'react';"}

The frontend accumulates the stream into a code string. Once generation finishes, the code gets injected into an iframe using document.write() — React, Babel, and Tailwind loaded via CDN. The component renders instantly with no build step.

The Bugs That Hurt
Chunk concatenation. Claude streams tokens. import and React arrive as separate events. Early on I was joining them naively and getting importReact from 'react' — which Babel rejects. Fix: wrapped each delta in a JSON object on the Go side, read obj.delta on the frontend. JSON preserves whitespace exactly.

Import statements in the iframe. The iframe loads React via CDN. If the generated code also has import React from 'react', Babel throws. Fix: stripped all imports and replaced export default before injecting:

const clean = code
  .replace(/^import\s+[\s\S]*?from\s+['"][^'"]*['"];?\s*$/gm, "")
  .replace(/^export\s+default\s+/m, "const __Component__ = ")
  .trim();

Image media type mismatch. Screenshots saved as .png sometimes contain JPEG bytes. Claude rejects the mismatch. Fix: since the Go compressor always outputs JPEG, I hardcoded image/jpeg as the declared media type regardless of the input format.

The Prompt That Works
You are an expert React and Tailwind CSS developer.
Generate a complete, production-ready React functional component
that faithfully reproduces the screenshot's layout, spacing,
colors, and typography.

Tailwind utility classes only — no inline styles
Realistic placeholder text, not Lorem Ipsum
Mobile-first responsive classes
Hover and focus states on interactive elements
Return ONLY the component code, no markdown fences
Self-contained, no required props "No markdown fences" is critical — without it Claude wraps output in triple backticks and Babel chokes on them.

What It Actually Produces
Tested on a Personal Details mobile screen, a dark SaaS landing page, and an analytic dashboard. All three came back with correct layout structure, color palette, component hierarchy, and interactive states. Light tweaking needed, but production-usable as a starting point.
What it doesn't nail: exact hex colors (approximates to nearest Tailwind value), complex animations, data-driven elements.

Cost
Under $5 total — including every debug run and demo conversion during the build.
Each conversion is ~500–800 prompt tokens + image tokens + ~2000 generation tokens. A few cents per screenshot. The tool replaces 30–60 minutes of manual JSX work per screen.

The Point
This doesn't replace frontend engineering. It removes the part that doesn't need one — translating static visuals into boilerplate markup. Get the structure from the screenshot, then spend your time on architecture, state, performance, and the interactions that actually require expertise.
Three hours to build. $5 to run. Every hour saved after that compounds.

Code
Full source on GitHub: github.com/norbertose/screenshot-figma-to-react
Stack: Next.js · Go · Claude API. Clone it, swap in your ANTHROPIC_API_KEY, and run.
The $5 subscription is still active.

I Got Tired of Rebuilding Admin Dashboards, So I Made One Installable

Norbert Madojemu — Thu, 25 Dec 2025 16:55:32 +0000

Every admin dashboard I worked on looked different on paper — but structurally, they were the same.

Same sidebar.
Same header.
Same colors.
Same responsiveness problems.

Yet for every new project, we rebuilt the layout from scratch.

That changed the day I spent several minutes debugging a slightly “off” dashboard width in a new project and realized something was wrong with our process, not the layout.

The Moment I’d Had Enough

I was collaborating with a colleague on a new internal project. He built the initial admin layout, and when I opened it, something felt… off.

The width wasn’t right.

Not obviously broken. Just wrong enough to be annoying.

So I spent several minutes digging through the layout:

container widths
padding
sidebar calculations
Tailwind classes stacked on Tailwind classes

Eventually I found the issue, but the real question hit me harder:

Why are we still debugging dashboard layouts in 2025?

We had already solved this problem before. Multiple times.

The Real Problem (It Wasn’t the Layout)

The real issue wasn’t that dashboards are hard to build.

It was that:

We kept rewriting the same TailwindCSS
We copied files between projects and fixed breakages
We re-tested mobile responsiveness every time
Minor inconsistencies kept creeping in across projects

All this before writing a single line of business logic.

That’s when the idea became obvious:

What if the dashboard itself was just… installable?

The Idea: A Reusable Dashboard as an npm Package

Instead of rebuilding or copying layouts, I wanted to:

Install a package
Get a consistent admin dashboard structure
Skip layout and responsiveness setup
Focus purely on features and logic

Not a design system.
Not a full-blown framework.

Just a solid dashboard foundation.

Building the Dashboard (The Comfortable Part)

I started fresh and rebuilt the dashboard using:

React
TypeScript
TailwindCSS

It intentionally mirrored what we already used internally:

Same color palette
Same font face
Same sidebar/header/content structure
Same responsive behavior

This part was easy. Familiar. Almost relaxing.

Then I decided to package it.

That’s where things got… spicy.

Turning It into an npm Package (The Humbling Part)

I genuinely thought this would be straightforward.

It wasn’t.

I actually gave up halfway through the first attempt.
Then came back.
Then almost gave up again.

But a new project landed — one that needed the exact same dashboard — and I refused to rebuild it from scratch.

So I pushed through.

“Why Is My Design Broken?” — The Debugging Saga

I packaged the dashboard, installed it into a host project, and…

The layout broke.

Spacing was off.
Styles were missing.
Everything looked almost right — which is the worst kind of wrong.

After a lot of back-and-forth, I realized two key issues:

The styles weren’t being bundled correctly
The host project wasn’t resolving the style paths properly

This led to a painful loop:

fix
build
publish
install
notice something else broke

The package went through several versions.

I think we’re currently on version 8 — the first one I’d confidently call “stable”.

What Finally Worked

Once I slowed down and treated this like a real library (not a side hack), things clicked.

The final approach looked like this:

Build and test the dashboard normally with React + TypeScript
Set React as a peer dependency

it is very important to note that you don’t ship React with your library, you share the host app’s React instance

Clean up the project structure
Properly bundle styles so they work in consuming apps
Add a build step
Publish to npm

Simple in theory. Unforgiving in practice.

A Tiny Usage Example

Once installed, using the dashboard looks something like this:

import { DashboardLayout } from "admin-dashboard";

function App() {
  return (
    <DashboardLayout>
      <h1>Dashboard Overview</h1>
      {/* Your actual features live here */}
    </DashboardLayout>
  );
}

export default App;

That’s it.

Sidebar.
Header.
Responsive layout.

Handled.

Why This Was 100% Worth It

Now, when I start a new project:

I install the package
I get a familiar, consistent dashboard instantly
Mobile responsiveness is already solved
Styling is no longer a recurring discussion

Most importantly, I get to focus on functionality, not layout déjà vu.

This wasn’t about building a “cool npm package”.

It was about:

Saving time
Reducing cognitive load
Enforcing consistency
Treating internal tooling like a first-class citizen

Final Thoughts

If you’ve rebuilt the same admin dashboard more than twice, this isn’t a motivation problem.

It’s a systems problem.

And sometimes, the most impactful solution isn’t a new feature —
it’s packaging the thing you’re already tired of rebuilding.

If this sounds familiar, maybe your next productivity win isn’t another refactor…

Maybe it’s your first npm package.