How I Added Unlayer’s Drag-and-Drop Email Editor to Next.js in Under 15 Minutes

I was experimenting with Unlayer's SDK to see what it could do. I discovered it could embed a drag-and-drop email editor, so I tried it in a Next.js app. I found I could export HTML, save designs as JSON, and get responsive output—all in minutes.

I kept testing and found it handled the email rendering quirks I'd normally avoid. Here's what I learned, and why it might be useful for other developers.

What I Discovered

Unlayer is like Stripe for email editing. It handles the rendering quirks so you can focus on your app.

What I Found:

• Client-side JavaScript wrapper that embeds a drag-and-drop editor
• Generates production-ready, cross-client compatible HTML
• Exports both JSON (for storage/editing) and clean HTML (for sending)
• React wrapper available out of the box
• No backend dependency—runs entirely in the browser

I kept playing with it and realized this could save weeks of work on email rendering. Here's how I integrated it:

Step 1: Installation

npm install react-email-editor

Step 2: The Component Setup

Here's the core implementation:

'use client'

import { useRef } from 'react'
import dynamic from 'next/dynamic'

// Critical: Dynamic import with SSR disabled
// react-email-editor relies on browser APIs like 'window'
// that aren't available during server-side rendering
const EmailEditor = dynamic(
  () => import('react-email-editor').then((mod) => mod.EmailEditor),
  { ssr: false }
)

export default function Home() {
  const emailEditorRef = useRef<any>(null)

  const exportHtml = () => {
    if (emailEditorRef.current) {
      emailEditorRef.current.editor.exportHtml((data: any) => {
        const { design, html } = data

        // Store JSON in your database for later editing
        console.log('Design JSON:', design)

        // Use HTML for sending emails
        console.log('Exported HTML:', html)

        // Download the HTML file
        const blob = new Blob([html], { type: 'text/html' })
        const url = URL.createObjectURL(blob)
        const link = document.createElement('a')
        link.href = url
        link.download = 'newsletter.html'
        link.click()
        URL.revokeObjectURL(url)
      })
    }
  }

  return (
    <div className="flex flex-col h-screen">
      <header className="bg-gray-900 text-white px-6 py-4 flex justify-between items-center">
        <h1 className="text-2xl font-bold">Newsletter Builder</h1>
        <button
          onClick={exportHtml}
          className="bg-blue-600 hover:bg-blue-700 text-white px-6 py-2 rounded-lg"
        >
          Export HTML
        </button>
      </header>

      <div 
        className="w-full" 
        style={{ height: 'calc(100vh - 73px)' }}
      >
        <EmailEditor
          ref={emailEditorRef}
          style={{ height: '100%', width: '100%' }}
        />
      </div>
    </div>
  )
}

The Hurdle: SSR and Hydration

The Problem: On first run, I hit a hydration error. The editor tried to access window during server-side rendering.

The Solution: I used Next.js dynamic import with { ssr: false }. This ensures the editor only renders on the client, avoiding hydration mismatches.

This is a common pattern for browser-only libraries in Next.js.

Key Implementation Details

1. Ref Management: useRef gives access to the editor instance to call methods like exportHtml().
2. Height Calculation: The editor container uses calc(100vh - header height) to fill the viewport.
3. Dual Export: The SDK provides both JSON (for storage) and HTML (for sending).

The Result

In about 15 minutes, I had:

• A drag-and-drop email editor
• Export functionality for both JSON and HTML
• Responsive, production-ready email HTML
• No custom rendering engine to maintain

What I Loved:

• Speed: Integration took minutes, not months
• Zero Backend: Runs entirely client-side
• Clean API: Simple ref-based access to editor methods
• Production-Ready Output: HTML works across major email clients

The Trade-offs:

• SSR Handling: Requires dynamic import (minor setup)
• Bundle Size: The SDK adds to your bundle (acceptable for the functionality)
• Styling: Some customization needed for full-height layouts

---

Build vs. Buy

When evaluating whether to build a custom email editor or use Unlayer, here's how the trade-offs break down:

Factor	Build Your Own	Use Unlayer SDK
Initial Development Time	4-6 months (full-time)	15 minutes - 2 hours (integration)
Email Client Compatibility	You maintain compatibility matrix for Outlook, Gmail, Apple Mail, etc.	Handled by Unlayer (tested across 50+ clients)
Responsive Design	Write custom media queries + table-based layouts	Built-in responsive engine
Dark Mode Support	Custom CSS and testing required	Automatic dark mode compatibility
Maintenance Burden	Ongoing: Update when email clients change rendering rules	Minimal: SDK updates handle compatibility
Custom Blocks/Extensibility	Full control, but you build the infrastructure	Built-in extensibility API (React/Vue components)
HTML Output Quality	Depends on your implementation	Production-ready, battle-tested HTML
State Management	Build your own JSON schema and parser	JSON schema provided, easy to store/load
Bundle Size	You control it (but you build everything)	~500KB (includes full editor)
Learning Curve	Steep: Email HTML quirks, rendering engines	Minimal: React component with simple API
Time to Market	6+ months to production-ready	Ship in a sprint
Technical Debt	High: Legacy email HTML, browser quirks	Low: Abstracted away
Cost (Engineering Hours)	~800-1200 hours initial + ongoing maintenance	~2-4 hours integration + minimal maintenance
Risk	High: Unknown rendering issues in production	Low: Proven in production by thousands of apps

So here's my take:

Build if:

• You have 6+ months and a dedicated team
• You need extreme customization that Unlayer can't provide
• Email editing is your core product (not a feature)

Buy (Unlayer) if:

• Email editing is a feature, not your product
• You need to ship quickly
• You want to focus engineering resources on core business logic
• You need reliable cross-client compatibility without the maintenance burden

For most SaaS applications, the math is clear: Buy. The time saved on rendering engine maintenance alone pays for the integration many times over.

Why Not Just Use a Rich Text Editor?

You might ask: "Why not use Tiptap or Quill?"

Rich text editors are great for documents, but they break for email layouts. Users need:

• Multi-column layouts
• Responsive images
• Buttons that work across clients
• Structured templates

Unlayer provides a layout builder that guarantees mobile-friendly output and saves designs as JSON for programmatic editing.

In production, you'd:

1. Store the JSON design in your database
2. Load saved designs with editor.loadDesign(designJson)
3. Integrate with your email sending service
4. Add custom blocks for your domain (e.g., product listings, user data)

Conclusion

Unlayer abstracts away email rendering complexity. If you need an email editor in your app, this SDK is worth evaluating. The time saved on rendering engine maintenance alone justifies the integration.

Sometimes the best code is the code you don't have to write ;)
I'm looking forward to exploring more and sharing with you!

---