Creador de páginas Next.js con GrapesJS

GrapesJS proporciona el motor de edición visual. Next.js proporciona la arquitectura de la aplicación que lo rodea. A continuación se lee la misma lista dos veces: de qué está hecho un editor y quién acaba construyendo cada parte una vez que adoptas GrapesJS.

• Arrastrar y soltar — Núcleo GrapesJS
• Lienzo — Núcleo GrapesJS
• Árbol de componentes — Núcleo GrapesJS
• Selección y hover — Núcleo GrapesJS
• Bloques — Núcleo GrapesJS
• Estilo — Núcleo GrapesJS
• Edición responsiva — Núcleo GrapesJS
• Deshacer / volver a hacer — Núcleo GrapesJS
• Gestión de recursos — Núcleo GrapesJS
• Serialización — Núcleo GrapesJS
• Comandos — Núcleo GrapesJS
• Sistema de plugins — Núcleo GrapesJS
• Almacenamiento — Núcleo GrapesJS
• Proyectos de varias páginas — Plugin o extensión
• Biblioteca de plantillas — Plugin o extensión
• Usuarios y permisos — Tu app Next.js
• Publicación — Tu app Next.js

Dos de los diecisiete son tuyos. El resto o bien vienen con el editor o existen como un plugin que instalas.

La integración del motor de inicio React: GrapesJS montado desde un componente React, con los paneles estándar de bloque, capa y estilo.

GrapesJS necesita un navegador. Mide elementos, conecta oyentes y muta el DOM en el momento en que se inicializa, así que el editor pertenece dentro de un Client Component y su configuración dentro de un efecto. Esa es toda la restricción: todo lo demás es React ordinario.

'use client';

import { useEffect, useRef } from 'react';
import grapesjs, { type Editor } from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';

export default function GrapesEditor() {
  const containerRef = useRef<HTMLDivElement>(null);
  const editorRef = useRef<Editor | null>(null);

  useEffect(() => {
    if (!containerRef.current) return;

    // Runs only in the browser: effects never execute during SSR.
    const editor = grapesjs.init({
      container: containerRef.current,
      height: '100vh',
      storageManager: false,
      blockManager: {
        blocks: [
          {
            id: 'section',
            label: 'Section',
            content: '<section class="py-16"><h2>Headline</h2></section>',
          },
          { id: 'text', label: 'Text', content: '<p>Edit me</p>' },
        ],
      },
    });

    editorRef.current = editor;

    // Strict Mode mounts twice in development; without this you get two editors.
    return () => {
      editor.destroy();
      editorRef.current = null;
    };
  }, []);

  return <div ref={containerRef} />;
}

import GrapesEditor from '@/components/GrapesEditor';

// A Server Component. It renders the Client Component; it never touches
// the editor instance, and no 'use client' is needed here.
export default function EditorPage() {
  return <GrapesEditor />;
}

Por qué el ejemplo se ve así

Eso es un editor funcional. El resto de esta página trata sobre las cuatro cosas que añades a continuación: dónde se almacena el proyecto, qué pueden arrastrar los usuarios, qué ocurre cuando publican y cuáles de esas no tienes que escribir tú mismo.

// components/GrapesEditor.tsx
'use client';
// …useRef + useEffect + grapesjs.init()

// app/editor/page.tsx — stays a Server Component
import GrapesEditor from '@/components/GrapesEditor';
export default function Page() {
  return <GrapesEditor />;
}

import dynamic from 'next/dynamic';

// In the Pages Router every page is a client entry point, so ssr: false
// is allowed here — and skips the prerender pass entirely.
const GrapesEditor = dynamic(() => import('@/components/GrapesEditor'), {
  ssr: false,
  loading: () => <p>Loading editor…</p>,
});

export default function EditorPage() {
  return <GrapesEditor />;
}

Si estás migrando, no lleves el envoltorio dinámico() a través de él. En el App Router o falla directamente dentro de un Server Component o duplica el trabajo que ya hace el 'use client'.

Server Components es donde debe estar el trabajo alrededor del editor. Obtienen datos, ejecutan lógica del lado del servidor y proporcionan el shell de la aplicación. El Client Component inicializa GrapesJS, es dueño de su ciclo de vida y gestiona todas las interacciones del navegador. Los props cruzan el límite; la instancia del editor nunca lo hace.

import GrapesEditor from '@/components/GrapesEditor';

export default async function EditorPage({
  params,
}: {
  params: Promise<{ projectId: string }>;
}) {
  const { projectId } = await params;

  // Server side: auth, permissions and data fetching stay here.
  const res = await fetch(`${process.env.API_URL}/projects/${projectId}`, {
    cache: 'no-store',
  });
  const initialProject = await res.json();

  // The Client Component receives plain, serialisable props.
  return <GrapesEditor projectId={projectId} initialProject={initialProject} />;
}

Mantén el editor en el lado del cliente mientras usas Server Components para la aplicación que lo rodea.

Sí, pero el editor en sí debería inicializarse en el cliente porque depende del navegador APIs y del DOM.

La versión útil de esa respuesta es más específica, porque las dos mitades fallan de forma diferente.

Esto es lo más útil que se puede hacer bien al principio y lo más fácil de equivocarse. El editor es un entorno de autoría. La página publicada puede usar tu propia arquitectura de renderizado Next.js — generación estática, streaming, revalidación, caché de bordes, todo.

// The public route. GrapesJS is not imported here, so the editor
// bundle never reaches a visitor.
export const revalidate = 3600;

export default async function PublishedPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const res = await fetch(`${process.env.API_URL}/published/${slug}`, {
    next: { revalidate: 3600 },
  });

  // Already sanitised on the way in — see the publish route below.
  const { html, css } = await res.json();

  return (
    <>
      <style dangerouslySetInnerHTML={{ __html: css }} />
      <div dangerouslySetInnerHTML={{ __html: html }} />
    </>
  );
}

GrapesJS envia adaptadores de almacenamiento local y remoto y te permite registrar los tuyos propios. Un adaptador personalizado suele ser la opción correcta, porque pone cada lectura y escritura detrás de una ruta que controlas y puedes autenticar.

const editor = grapesjs.init({
  container: containerRef.current,
  storageManager: {
    type: 'nextjs-api',
    autosave: true,
    stepsBeforeSave: 5,
  },
  plugins: [
    // Registered as a plugin so the adapter exists before the first load.
    (editor) => {
      editor.Storage.add('nextjs-api', {
        async load() {
          const res = await fetch(`/api/projects/${projectId}`);
          return res.ok ? res.json() : {};
        },
        async store(project) {
          await fetch(`/api/projects/${projectId}`, {
            method: 'PUT',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify(project),
          });
        },
      });
    },
  ],
});

import { NextResponse } from 'next/server';

// Your own persistence layer — Postgres, MySQL, Mongo, S3, a headless CMS.
// GrapesJS never talks to it; it only ever talks to this route.
import { loadProject, saveProject } from '@/lib/projects';
import { requireProjectAccess } from '@/lib/auth';

export async function GET(
  _request: Request,
  { params }: { params: Promise<{ projectId: string }> },
) {
  const { projectId } = await params;
  await requireProjectAccess(projectId);

  return NextResponse.json(await loadProject(projectId));
}

export async function PUT(
  request: Request,
  { params }: { params: Promise<{ projectId: string }> },
) {
  const { projectId } = await params;
  await requireProjectAccess(projectId);

  const project = await request.json();
  if (typeof project !== 'object' || project === null) {
    return NextResponse.json({ error: 'Invalid project' }, { status: 400 });
  }

  await saveProject(projectId, project);
  return NextResponse.json({ ok: true });
}

• Carga: el load() del adaptador funciona en init y restaura el proyecto en el que el usuario estaba trabajando la última vez.
• Guardar: store() recibe todo el proyecto como JSON. Devuelve una promesa rechazada para mostrar un fallo en el editor.
• Guardado automático: el guardado automático con stepsBeforeSave agrupa los cambios para que no escribas en cada pulsación.
• Borradores: mantén el proyecto borrador y la salida publicada en columnas separadas, para que la edición nunca altere lo que ven los visitantes.
• Versionado: los datos del proyecto son un documento JSON — una tabla de versiones solo para añadir cuesta un inserto y compra rollback.
• Publicación: un endpoint separado con su propia comprobación de permisos, no una bandera en la ruta de guardado.

Ejemplo: almacenar proyectos con Supabase

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!, // server only — never NEXT_PUBLIC_
);

export async function loadProject(projectId: string) {
  const { data } = await supabase
    .from('projects')
    .select('project')
    .eq('id', projectId)
    .single();

  return data?.project ?? {};
}

export async function saveProject(projectId: string, project: unknown) {
  await supabase
    .from('projects')
    .upsert({ id: projectId, project, updated_at: new Date().toISOString() });
}

Esto implementa el límite loadProject y saveProject que importa la ruta anterior. Cambia el cuerpo por Prisma, Drizzle, Mongo, DynamoDB o una llamada REST a un backend existente y nada más en la página cambia.

Ejemplo: conectar almacenamiento de proyecto a un despliegue Vercel/Next.js

Publicar escribe HTML y CSS que tu ruta pública lee de vuelta. La revalidación, el almacenamiento en caché y la estrategia de renderizado siguen siendo preocupaciones habituales de Next.js: el editor no está en la ruta de solicitud.

Puedes conectar GrapesJS a cualquier backend o base de datos. Nada en el editor sabe ni le importa cuál elegiste.

De fábrica, el lienzo ofrece a los usuarios HTML genérico. Los tipos de componentes personalizados son la forma en que el editor empieza a producir el marcado de tu producto — las mismas secciones que tu app Next.js ya renderiza, solo con las propiedades que decides exponer.

// Your design system, expressed as something users can drop in,
// edit and style — but not break.
editor.Components.addType('pricing-table', {
  isComponent: (el) =>
    el.tagName === 'SECTION' && el.classList.contains('pricing'),

  model: {
    defaults: {
      tagName: 'section',
      classes: ['pricing'],
      // Structure the user cannot accidentally dismantle.
      droppable: false,
      // Fields exposed in the Settings panel.
      traits: [
        { name: 'plan', label: 'Plan name', type: 'text' },
        { name: 'price', label: 'Price', type: 'text' },
        { name: 'billing', label: 'Billing period', type: 'select',
          options: [
            { id: 'month', label: 'Monthly' },
            { id: 'year', label: 'Yearly' },
          ] },
      ],
      components: [
        { type: 'text', tagName: 'h3', content: 'Starter' },
        { type: 'text', tagName: 'p', content: '$19 / month' },
        { type: 'link', content: 'Choose plan', attributes: { href: '#' } },
      ],
    },
  },
});

Construir una biblioteca de bloques

Los bloques son lo que aparece en el panel desde el que el usuario arrastra. Registrar uno cuesta unas líneas una vez que existe el tipo de componente.

// A block is what the user drags. A component is what it becomes.
editor.Blocks.add('pricing-table', {
  label: 'Pricing table',
  category: 'Marketing',
  media: '<svg viewBox="0 0 24 24" width="24" height="24">' +
    '<rect x="3" y="4" width="18" height="16" rx="2" fill="currentColor"/></svg>',
  content: { type: 'pricing-table' },
});

• Secciones reutilizables — Hero, características, testimonios, pie de página
• Bloques de marketing — tablas de precios, muros de logotipos, llamadas a la acción
• Bloques de disposición — columnas, separadores, contenedores
• Formularios — contacto, inscripción, varios pasos
• Bloques de comercio electrónico — cuadrículas de productos, resúmenes de carritos, indicaciones de pago
• Bloques de aplicación — sea lo que haga tu producto y que una página debería poder mostrar

Gestionar imágenes y activos

El Asset Manager se encarga de la selección e inserción. Dónde están los archivos, quién puede subirlos y qué se permite es tu parte del contrato.

assetManager: {
  // The library the user already has, loaded from your backend.
  assets: initialAssets,

  uploadFile: async (event) => {
    const files = event.dataTransfer
      ? event.dataTransfer.files
      : (event.target as HTMLInputElement).files;
    if (!files) return;

    const body = new FormData();
    Array.from(files).forEach((file) => body.append('files', file));

    // Your route authenticates the user and validates type and size
    // before anything is written to storage.
    const res = await fetch('/api/assets', { method: 'POST', body });
    const { urls } = await res.json();

    editor.AssetManager.add(urls);
  },
},

• Sube a través de tu propio gestor de ruta para que se apliquen la cookie de sesión, el límite de tasa y el registro de auditoría.
• Permite URLs externas para equipos que ya alojan imágenes en otros sitios.
• Precarga la biblioteca existente del usuario para que el selector se abra en sus assets, no en un panel vacío.
• Valida el tipo MIME y el tamaño en el servidor. La entrada del archivo del editor es una sugerencia, no un control.
• Sirve desde un CDN y guarda la URL de CDN en el proyecto, así las páginas publicadas nunca llegan a tu origen para el medio.
• Paginar grandes bibliotecas — el panel de recursos intentará renderizar diez mil miniaturas encantado.

El editor produce dos cosas diferentes y no son intercambiables. Guardar la incorrecta es el error que convierte "editar tu página" en "empezar de nuevo".

// Project data — the editable source. This is what you store.
const project = editor.getProjectData();

// HTML and CSS — the rendered output. Generate this when you publish.
const html = editor.getHtml();
const css = editor.getCss();

// Reopening an editing session needs the project data, not the HTML:
editor.loadProjectData(project);

Guarda los datos del proyecto para editar. Genera HTML/CSS cuando necesites publicar o renderizar contenido.

GrapesJS proporciona el motor de edición. Los plugins añaden la funcionalidad especializada que necesita un producto específico — y la mayoría de lo que un creador de páginas sigue faltando después de la primera semana ya existe como tal.

• BloquesSecciones listas y primitivas de diseño para el panel de arrastre.
• PlantillasPresets iniciales completos — un editor que abre en algo, no en un lienzo en blanco.
• AlmacenamientoAdaptadores de persistencia, guardado automático y recuperación de bloqueos.
• RecursosSube widgets, bibliotecas multimedia e integraciones CDN.
• PáginasProyectos de varias páginas, árboles de páginas y enlaces internos.
• ExportaciónExportación ZIP, convertidores HTML/CSS y ganchos de despliegue.
• Correo electrónicoMJML y presets del boletín para la salida de correos del mismo lienzo.
• FormulariosComponentes de forma, entradas y embeds de terceros.
• IAGeneración de copias, generación de imágenes y edición asistida.
• UIExtensiones para el gestor de estilo, reglas, paletas y editor Chrome.

Listados en directo del catálogo GJS.Market, agrupados según la pregunta que un equipo de Next.js haga tras montar el editor.

Integración de React y Next.js

Starters y capas UI para equipos que montan GrapesJS desde un componente React.

Navegar categoría

GrapesJS React Demo — Starter Integration for React Developers

Una integración funcional de React para leer antes de escribir la tuya propia.

GratisVista

React UI for GrapesJS

Reconstruye los paneles del editor como tus propios componentes React alrededor del lienzo.

GratisVista

Hero React Component GrapesJS

Un componente React renderizado como un bloque editable — el patrón para el tuyo propio.

GratisVista

GrapesJS Shadcn

Una carcasa de editor completa rediseñada a un sistema de diseño moderno React.

999,99 US$Vista

Almacenamiento y recuperación

Todo lo que va entre "el usuario editó algo" y "sigue ahí mañana".

Navegar categoría

Grapesjs Project Manager

Listado, creación y cambio de proyectos sin escribir el CRUD.

GratisVista

Autosave & Restore — Crash Recovery for GrapesJS

Recupera la sesión tras una pestaña cerrada o una conexión perdida.

12,00 US$Vista

IndexedDB Storage

Persistencia local con capacidad de conexión sin conexión, útil como capa de borrador delante de tu API.

GratisVista

Cloud Firestore

Un backend de persistencia alojado si prefieres no ejecutar uno.

GratisVista

Bloques, páginas y plantillas

Qué arrastran los usuarios, dónde están las páginas y qué muestra el editor.

Navegar categoría

Plugin Basic Blocks

El bloque de arranque se configuró para que el panel de arrastre no estuviera vacío el primer día.

GratisVista

Pages Manager

Proyectos de varias páginas con un árbol de páginas en el editor.

25,00 US$Vista

Templates Manager

Una biblioteca de plantillas desde la que los usuarios pueden empezar y tú puedes seleccionar.

39,00 US$Vista

Plugin Blocky for Tailwind CSS

Bloques nativos de Tailwind para equipos que ya están estilizando con Tailwind.

59,00 US$Vista

Recursos, exportación y correo electrónico

Manejo de medios y los formatos de salida en los que crece un constructor de páginas.

Navegar categoría

Grapesjs Cloudinary

Cloudinary como backend de activos, con transformaciones incluidas.

GratisVista

Grapesjs Uppy

Un widget de subida de grado de producción conectado por cable al Asset Manager.

GratisVista

Export Zip

Descarga un proyecto como un paquete listo para desplegar de HTML y CSS.

GratisVista

MJML Preset

Convierte el mismo lienzo en una salida de correo responsiva.

GratisVista

Usa el núcleo GrapesJS para el editor y añade solo las capacidades que tu producto realmente necesite.

Capacidad por capacidad, lo que te vas a inscribir para escribir. "Extensible" significa que la biblioteca proporciona la interfaz y el predeterminado, y espera que lo apuntes a tu propio backend.

Verificado en comparación con el GrapesJS API publicado en 2026-09-02.

Dos listas que merecen la pena leer antes de que el primer usuario real abra el editor, no después.

Casi todos los fallos de integración reportados para esta pila son uno de los siguientes siete.

• ✕Error

  Inicialización de GrapesJS dentro de un Server Component

  Server Components no tiene ganchos, ni efectos ni DOM. La importación puede resolverse, pero no hay dónde montar el editor.

  ✓Solución

  Usa un Client Component — pon 'use client' en la parte superior del módulo que posee el editor.

• ✕Error

  Inicialización antes de que exista el DOM

  Llamar a init() durante el renderizado, o contra una referencia que sigue siendo nula, falla porque el elemento contenedor aún no se ha creado.

  ✓Solución

  Inicializa después de la montura, dentro de useEffect, y vigila que la referencia esté presente.

• ✕Error

  Ejecutar GrapesJS durante SSR

  Cualquier llamada a init() que llegue al servidor lanza el documento ReferenceError: no está definido. La importación por sí sola es inofensiva.

  ✓Solución

  Mantén la inicialización del editor en el lado del cliente. Un efecto es suficiente; las importaciones dinámicas son una optimización, no la solución.

• ✕Error

  Poner la instancia del editor en estado React

  El editor es un objeto grande y mutable que cambia constantemente. Almacenarlo en programas de estado se vuelve a renderizar sin lograr nada.

  ✓Solución

  Usa un ref. Guarda el estado de las cosas que realmente renderiza el UI, como un indicador de guardado.

• ✕Error

  Volver a renderizar el editor innecesariamente

  Un re-renderizado padre que recrea los objetos o vuelve a montar el contenedor desmonta y reconstruye todo el lienzo.

  ✓Solución

  Mantén el ciclo de vida del GrapesJS separado del renderizado normal del React — monta una vez y luego pasa por su propio API.

• ✕Error

  Almacenar solo HTML

  HTML es la salida, no la fuente. Reabrir un proyecto desde HTML pierde tipos de componentes, traits y estado del editor, así que la siguiente edición comienza desde una página aplanada.

  ✓Solución

  Persiste los datos del proyecto si los usuarios necesitan seguir editando. Genera HTML al publicar.

• ✕Error

  Ejecutando GrapesJS en todas las páginas públicas

  Enviar el runtime del editor a los visitantes que no pueden editar nada cuesta tamaño del paquete, memoria y Core Web Vitals sin devolución.

  ✓Solución

  Separar el tiempo de ejecución del editor del contenido publicado — renderiza las páginas publicadas como HTML y CSS simples.

Tres miras, cada una sumándose a la anterior. La mayoría de los equipos se pasan en la primera y se sorprenden con la tercera.

1. 1Semana uno

   MVP

   Demuestra que la experiencia de edición es la adecuada antes de construir algo alrededor de ella.

   • GrapesJS montado en un componente cliente
   • Un puñado de bloques básicos
   • Almacenamiento local o de un solo proyecto
   • Publicación sencilla en una sola vía
   Empieza aquí
2. 2Primeros usuarios reales

   Producción

   Todo lo que convierte una demo en algo en lo que un cliente pueda confiar.

   • Autenticación en cada ruta de editor
   • Almacenamiento en el backend detrás de tu propio API
   • Subidas de activos y una biblioteca multimedia
   • Componentes personalizados que se ajustan a tu sistema de diseño
   • Permisos aplicados en el lado del servidor
   • Versionado y un flujo de trabajo de publicación
   Consulta la sección de almacenamiento
3. 3Comercial

   SaaS

   La capa de producto alrededor del editor, que es por lo que realmente cobras.

   • Organizaciones y equipos
   • Límites de facturación y planes
   • Editor de marca blanca UI
   • Un conjunto de plugins seleccionado para tus usuarios
   • Una biblioteca de plantillas
   • Analítica en páginas publicadas
   Creador de páginas SaaS

El camino desde el prototipo hasta el producto comercial pasa por tu aplicación, no por el editor.