PageKit: el creador de sitios GrapesJS autoalojado, con el código fuente incluido. Obtener acceso anticipado
Crea un editor visual de correo electrónico para tu SaaS, CMS, plataforma de marketing o herramientas internas. Deja que los usuarios creen correos responsivos con bloques de arrastrar y soltar mientras tu equipo controla componentes, plantillas, almacenamiento, salida y publicación.
Tus usuarios crean los correos electrónicos de forma visual. Tu aplicación controla la experiencia.
Este es un editor GrapesJS real ejecutándose en esta página: no es un vídeo ni una captura de pantalla. Arrastra un bloque desde la derecha, selecciona cualquier elemento para volver a darle estilo, cambia al ancho de móvil y después lee el marcado generado. La cabecera y el pie de página están bloqueados, que es el mismo patrón que explica la sección de más abajo.
Lo que puedes hacer aquí
Un generador de correos electrónicos de arrastrar y soltar es un editor visual que permite a los usuarios crear diseños de correo electrónico a partir de componentes reutilizables en lugar de escribir manualmente tablas HTML y CSS específicos para correos electrónicos.
La diferencia está en quién tiene que conocer las reglas. Sin un constructor, quien escribe el correo debe saber que el diseño se hace con tablas anidadas, que la mayoría del diseño tiene que ser en línea y que un margen disperso puede colapsar el diseño en un solo cliente. Con un constructor, esas reglas se codifican una vez — por ti — en bloques y componentes, y los demás simplemente las organizan.
Sin un generador visual
Alguien escribe a mano el marcado de tabla y luego lo revisa manualmente. Cada correo nuevo empieza con una copia del anterior.
<table role="presentation" cellpadding="0" cellspacing="0" width="600">
<tr>
<td style="padding:32px;font-family:Arial,sans-serif">
<h1 style="margin:0 0 12px;font-size:26px">Welcome</h1>
<p style="margin:0;font-size:15px;line-height:1.6">Y Nuestro contenido... </p>
</td>
</tr>
</table>Con un generador de arrastrar y soltar
Alguien organiza los bloques. El marcado de tabla se genera a partir de componentes que definiste y revisaste una vez.
El constructor no está para facilitar el correo electrónico. Está para tomar las partes difíciles que sea decisión de otra persona — tuya, tomada una vez, a nivel de componente.
Una página web se ejecuta en un navegador sobre el que puedes razonar en términos generales. Un correo electrónico se ejecuta dentro del cliente en el que el destinatario lo abrió, y ese cliente puede reescribir tu marcado, eliminar tus estilos o configurarlo con un motor completamente diferente. Por tanto, un creador de correo electrónico debe limitar lo que los usuarios pueden producir, no solo hacer que la producción sea agradable.
Donde tu correo electrónico tiene que sobrevivir
Gmail
Las aplicaciones web, Android e iOS se comportan de forma diferente entre sí, y el cliente web procesa tus estilos antes de renderizar.
Outlook
Escritorio, web y el cliente más reciente de Windows son, en la práctica, renderizadores diferentes. Las compilaciones de escritorio en Windows han sido históricamente el objetivo más estricto.
Apple Mail
El más permisivo de los clientes comunes, lo que lo convierte en un mal sustituto: un correo que parece aquí aún puede romperse en otro sitio.
Yahoo Mail
Otro cliente de webmail con sus propias reglas de sanitización para estilos y marcado.
Clientes móviles
Ventanas de visualización estrechas, escalado agresivo de texto y manejo en modo oscuro que varía según la app y la versión del sistema operativo.
Todo lo demás
Puertas de entrada corporativas, proveedores regionales y clientes antiguos que nunca aparecen en una matriz de pruebas típica.
Lo que eso obliga al constructor
La disposición es tablas, no flexbox ni grid
Tus columnas, espaciadores y separadores deben ser componentes de tabla. Los usuarios nunca deberían poder soltar un div suelto en el lienzo.
El soporte para CSS es parcial e irregular
Limita el Style Manager a propiedades que realmente hayas probado, en lugar de exponer todo el conjunto del navegador.
Los estilos son más seguros en línea
O bien escribes con un preajuste que se inicie al exportar, o ejecutas un inliner en tu propio pipeline antes de que el correo salga de tu backend.
Las consultas de los medios no son universalmente reconocidas
Diseña para que el respaldo de una sola columna ya sea aceptable, y trata las reglas responsivas como una mejora en lugar de un requisito.
Las imágenes suelen estar bloqueadas por defecto
Exige texto alternativo en cada componente de la imagen y nunca dejes que un bloque dependa de que una imagen sea legible.
El modo oscuro puede cambiar el color de tu correo electrónico
Algunos clientes invierten o cambian de color automáticamente. Evita diseños que dependan de que un fondo específico se mantenga exactamente de ese color.
Las fuentes web a menudo no se cargan
Envía una pila de respaldo real en cada componente de texto y revisa el correo con la opción de respaldo en lugar de la cara prevista.
Los scripts no se ejecutan y la interactividad es limitada
Cualquier cosa dinámica debe estar detrás de un enlace. Un constructor que ofrece bloques interactivos a los usuarios les ofrece algo que no funcionará.
El correo comercial conlleva requisitos legales
La identidad del remitente y un mecanismo de baja son obligaciones, no decisiones de diseño. Fíjalos en la plantilla en lugar de confiar en una lista de comprobación.
No estás construyendo un editor que produzca un HTML hermoso. Estás construyendo un editor que no puede producir un HTML peligroso.
El comportamiento del cliente cambia con los lanzamientos y modos de renderizado, así que esta página indica que no hay matriz de soporte por cliente. Valida contra los clientes y funciones que realmente utiliza tu propia audiencia. Última revisión de 2026-09-03.
GrapesJS es un framework de web builder de código abierto (BSD-3-Clause), actualmente 0.23.6, con aproximadamente 26k+ estrellas en GitHub. Te da las partes de un editor que son caras de construir y aburridas para diferenciar, y se aparta para las partes que realmente son tu producto.
Un lienzo iframe con selección, objetivos de arrastre, indicadores de soltado, redimensionamiento y una barra de herramientas de componentes: la capa de interacción que tarda meses en hacerse bien y por la que nadie compra tu producto.
Define un componente seguro para el correo electrónico una vez, y luego exponlo como un bloque que los usuarios arrastran. Los componentes tienen sus propias reglas: qué aceptan, qué se puede editar, qué se puede estilizar.
Un panel de estilo que puedes restringir a las propiedades que realmente soporta el email, y un panel traits para los ajustes que no son CSS — un destino de enlace, un texto alternativo, un campo de fusión.
Un árbol de estructuras para tablas anidadas que son difíciles de seleccionar con clic, y un gestor de activos al que puedas señalar tu propia biblioteca multimedia.
Todo el estado del editor se serializa para proyectar JSON. Apunta el Storage Manager a tu API y al editor deja de importarle dónde están los datos.
Cada acción del editor es un comando con nombre que puedes llamar, sobreescribir o añadir — que es como los presets, exporters y los plugins 100+ en GJS.Market lo extienden sin fork.
GrapesJS proporciona la capa de edición. Tu aplicación proporciona el producto de correo electrónico.
Tu producto: cuentas, inquilinos, facturación, la ruta en la que está montado el editor.
Tu shell alrededor del editor: selector de plantillas, guardar estado, botón de enviar, aprobaciones.
El motor de edición visual. Sabe sobre componentes y lienzos, y nada sobre tus usuarios.
Los subsistemas del editor que configuras: qué bloques existen, qué aceptan, qué se puede estilizar, qué se puede editar.
El estado del editor serializado. Esto es lo que almacenas para que un correo pueda reabrirse más tarde.
Tu API: permisos, versionado, resolución de la etiqueta de fusión, validación, registros de campaña.
El margen que realmente envías. Generado bajo demanda desde el proyecto almacenado.
El proveedor que entrega el correo y reporta lo que le ha pasado.
La bandeja de entrada, y el cliente que lo renderice.
GrapesJS nunca se comunica con tu base de datos ni con tu proveedor de correo electrónico. Te entrega un documento; todo lo que viene después es tu arquitectura.
Tres propietarios, sin solapamiento. El error arquitectónico más común en el tema de esta página es esperar que el editor haga algo en las columnas de la derecha.
Nada de lo que hay en las columnas de la derecha es una carencia de GrapesJS: esas filas nunca fueron tarea del editor. Tratarlas como trabajo de la aplicación desde el primer sprint es lo que mantiene la integración sencilla.
Tres artefactos surgen del mismo lienzo, y no son intercambiables. Uno es el proyecto que conservas, dos son los formatos de entrega que generas a partir de él.
La representación editable del correo — componentes, estilos, recursos y páginas, exactamente como los sostiene el editor.
Mejor para
¿Cómo lo consigues
editor.getProjectData()Este es el que hay que guardar. Almacenar solo HTML renderizado significa que la siguiente edición comienza con el marcado analizado en lugar del documento que el usuario construyó.
El marcado basado en tablas que entregas a un proveedor de envío, con estilos en línea para que más clientes los conserven.
Mejor para
¿Cómo lo consigues
editor.runCommand('gjs-get-inlined-html')El comando de inlining viene del preset del boletín, no del núcleo GrapesJS. Sin él obtienes el marcado de lienzo y una hoja de estilo, que no es lo que quieres enviar.
Un lenguaje de marcado de mayor nivel para el correo electrónico que se compila hasta la tabla responsiva HTML.
Mejor para
¿Cómo lo consigues
editor.runCommand('mjml-code')MJML es un ecosistema separado: el plugin editor renderiza los componentes MJML y un compilador los convierte en HTML. Ambos son paquetes de terceros que añades.
JSON es el proyecto. HTML y MJML son la entrega. Guarda el primero, genera los demás.
De lienzo a bandeja de entrada
No entregues a los usuarios un lienzo en blanco y un div. Entrega un pequeño conjunto de componentes que ya codifican el marcado de tabla, los estilos en línea y los respaldos, y luego deja que la gente los organice. Estos diez cubren la mayor parte de lo que realmente necesitan el marketing y el correo electrónico del ciclo de vida.
Logo, barra de marca, texto de preencabezado. Normalmente bloqueado para que cada correo salga con la misma identidad.
Titular, línea de apoyo y una acción. Dimensionado para que el mensaje sobreviva sin que la imagen cargue.
Un bloque de párrafo con una pila de fuentes de respaldo real y altura de línea que aguanta a los anchos de los teléfonos.
Ancho fijo, dimensiones explícitas y texto alternativo obligatorio, así que una imagen bloqueada sigue dejando un correo electrónico legible.
Un botón basado en tabla en lugar de un ancla estilizada — la diferencia es visible en clientes más estrictos.
Una fila de tabla que se apila en pantallas estrechas, con el orden de apilado ya decidido por ti.
Imagen, nombre, precio y enlace, impulsados por los campos que rellena tu backend en lugar de copiar y pegar.
Una fila fija de iconos y URLs, editable como configuración en lugar de como marcado.
Una línea dibujada con un borde de tabla en lugar de un elemento <hr>, que varios clientes de correo reestilizan.
Identidad del remitente, dirección y enlace de baja de baja. Normalmente bloqueado, porque son obligaciones.
Permite que los usuarios diseñen visualmente sin tener que entender el correo HTML.
Un componente es la definición; un bloque es cómo un usuario lo pone en el lienzo. La biblioteca de bloques es la palanca más poderosa que tienes sobre lo que la gente puede construir — y la más fácil de equivocarse si eres generoso.
El bucle que repiten tus usuarios
Cada elemento disponible, cada estilo editable, sin opinión sobre la estructura.
Una lista corta de bloques que has diseñado, probado y que puedes cambiar centralmente.
Tres niveles, y confundirlos es lo que hace que los constructores de correo sea difícil de desarrollar. Los componentes son lo que son, los bloques son cómo se añaden, las plantillas son puntos de partida terminados.
Plantillas
Un correo electrónico completo desde el que un usuario puede empezar — boletín, recibo, paso de incorporación. Almacenado como proyecto JSON, clonado en su uso.
Bloques
Las unidades arrastrables de las que se ensambla una plantilla: un hero, una fila de artículo, una banda CTA, un pie de página.
Componentes
Las primitivas editables dentro de un bloque, con su propio traits y reglas — una tarjeta de producto que sabe que tiene un precio.
Primero construye los componentes, luego los bloques que los exponen, y después las plantillas que los organizan. Los equipos que empiezan en el nivel de plantilla acaban con decenas de diseños casi idénticos y sin forma de cambiar ninguno.
Una plantilla de boletín ampliada
Plantilla de boletín
Cada hijo es un bloque; cada bloque está formado por componentes. Cambia el bloque de artículo una vez y cada boletín construido a partir de esta plantilla lo recoge la próxima vez que se abra.
Bloquear GrapesJS no es un modo ni un plan tier — es un conjunto de opciones en una definición de componente. Una región bloqueada sigue renderizándose, exportándose y simplemente se niega a arrastrarse, eliminarse o reestilizarse en el editor.
Cabecera de empresa
BloqueadoPresente en cada correo, idéntico en cada correo. Nadie necesita moverlo.
Contenido editable
EditableTexto e imágenes que el remitente está realmente aquí para escribir.
Llamada a la acción
EditableEtiqueta y enlace editables, y una lista corta de colores — no el marcado debajo.
Pie de base legal
BloqueadoIdentidad del remitente y enlace de baja de suscripción. Una obligación, no una decisión de diseño.
Las opciones que lo producen
removable: false, draggable: falseeditable: truestylable: ['background-color', 'color']removable: false, copyable: falseLo que esto te compra
Estas opciones rigen el editor UI. No son autorización. Un proyecto modificado publicado directamente en tu endpoint de guardado está limitado solo por lo que valida tu servidor — así que valida la estructura, las regiones requeridas y los campos permitidos en el backend, cada vez.
El correo personalizado son dos problemas distintos: permitir que un usuario coloque un marcador de posición sin conocer la sintaxis y resolver ese marcador con datos reales en el momento de enviarlo. El editor resuelve el primero. Solo tu aplicación puede resolver el segundo.
Etiquetas de fusión en la plantilla
{{first_name}}{{company_name}}{{order.total}}{{unsubscribe_url}}Para el editor, estos son textos ordinarios. Se almacenan exactamente tal y como están escritos y sobreviven guardados, reabiertos y exportados sin tocar.
Cómo los usuarios los insertan
Expone los campos disponibles como un rasgo en tu componente de texto — un desplegable de "Nombre", "Empresa", "Total de pedidos" — y escribe el token tú mismo en el contenido. Los usuarios eligen un campo; nunca aprenden una sintaxis y no pueden inventar una etiqueta que tu renderizador no conozca.
Bloques dinámicos
Un bloque puede ser un marcador de posición para contenido que aún no existe. El usuario introduce una tarjeta de producto y configura qué productos debe mostrar; los valores llegan cuando se muestra el correo.
GrapesJS proporciona la experiencia de edición. Tu backend resuelve datos dinámicos y etiquetas de fusión cuando el correo se renderiza o se envía.
Dos anchos cubren casi toda la revisión de diseño: el ancho al que se crea el correo y un teléfono. Ambos están a un cambio de dispositivo en el editor, y ninguno es lo mismo que hacer pruebas.
El flujo de trabajo que realmente detecta problemas
Una vista previa en el editor es tu navegador que renderiza el marcado en lienzo. Un cliente de correo muestra una versión transformada de ese marcado a través de su propio motor, y ambos pueden diferir. La vista previa es para revisión de diseño; una lista semilla o un servicio de renderizado es para compatibilidad.
La mayoría de los desastres por correo electrónico no generan errores. Son un enlace roto, una etiqueta de fusión sin cubrir o una baja de baja ausente. Los tres son baratos de detectar en el servidor y caros de detectar en una bandeja de entrada.
Corre antes de que una plantilla pueda salir del borrador.
Barato de automatizar y el fallo más común.
No es negociable, así que impídelo en código en lugar de en una lista de comprobación.
El Storage Manager es una interfaz, no una base de datos. Implévalo contra tu propio API y el editor carga, guarda y restaura automáticamente a través de endpoints que controlas — que es el punto en el que los borradores, versiones y aprobaciones se vuelven posibles.
El ciclo de vida que define tu backend
// The editor hands you project JSON; your backend decides
// what a draft, a version and an approved template mean.
editor.Storage.add('email-api', {
async load({ templateId }) {
const res = await fetch(`/api/email-templates/${templateId}`);
return res.json(); // -> project JSON
},
async store(data, { templateId }) {
await fetch(`/api/email-templates/${templateId}`, {
method: 'PUT',
headers: { 'Content-Type': 'application/json' },
// Authorization is enforced server-side. Never trust this call.
body: JSON.stringify({ project: data }),
});
},
});El guardado automático se limita por el número de cambios en lugar de por un temporizador, así que una ráfaga de ediciones sigue costando una petición. Mantén las versiones como copias inmutables del proyecto JSON — restaurar una revisión entonces solo cuesta cargar, y una mala edición deja de ser un incidente.
Nada en esta arquitectura te pide cambiar cómo envías el correo. El editor produce un documento; tu backend lo renderiza y se lo entrega al proveedor que ya pagas.
GrapesJS
Produce el proyecto y, a petición, el marco. No sabe nada sobre los destinatarios.
HTML / MJML
Generados bajo demanda desde el proyecto almacenado, con estilos en línea o MJML compilados.
Tu backend
Resuelve las etiquetas de fusión, valida la salida, registra la campaña, llama al proveedor.
Tu proveedor
Entrega el correo y reporta rebotes, quejas, abre y vuelve a enviarte.
Ejemplos de dónde publica tu backend
Listados alfabéticamente como ilustraciones del último salto. Cualquier proveedor con un endpoint HTTP API o SMTP tiene la misma forma, y cambiar uno por otro no toca el editor.
GrapesJS es el editor, no tu servicio de correo electrónico.
Ni GrapesJS ni GJS.Market incluyen integración con ningún proveedor mencionado anteriormente, y no se implica ninguna colaboración. La entrega de la entregabilidad, la autenticación y la gestión de supresión siguen siendo responsabilidad de tu proveedor y tu aplicación.
// Server side. GrapesJS is not in this file — and that is the point.
const template = await db.emailTemplates.find(templateId);
// 1. Your application resolves merge tags. The editor never does.
const html = renderMergeTags(template.html, {
first_name: user.firstName,
unsubscribe_url: unsubscribeUrlFor(user),
});
// 2. Your ESP delivers it. Swap the client, keep the editor.
await esp.send({ to: user.email, subject: template.subject, html });La misma capa de edición, empaquetada de ocho maneras diferentes. Lo que cambia entre ellas es quién edita, qué pueden cambiar y dónde va el resultado.
Deja que los clientes diseñen el ciclo de vida y el correo electrónico de campañas dentro de tu producto, según plantillas y bloques que controlas por plan.
Arquitectura de un builder SaaSProporciona a un equipo de marketing un editor visual para un formato recurrente, con un bloque de artículos que mantenga cada número consistente.
Plugins para boletinesCrea los correos que se encuentran dentro de campañas y flujos de trabajo, compartiendo bloques con las páginas de destino a las que apuntan.
Creador de páginas de aterrizajePlantillas muy controladas para recibos y notificaciones — mayormente bloqueadas, con un pequeño centro editable.
Sistemas de plantillasDeja que los equipos de contenido reutilicen los bloques con los que ya escriben contenido web, almacenados junto al resto del modelo de contenido.
Edición con CMS headlessUn editor, un conjunto de bloques de marca por cliente y plantillas que no se pueden desajustar entre reseñas.
Constructores de marca blancaProporciona a los equipos internos un editor controlado en lugar de un archivo HTML compartido y una cola de peticiones.
No-code para desarrolladoresHaz que el editor parezca y se comporte como parte de tu producto, hasta en los paneles, los iconos y el lenguaje.
Etiqueta blanca al editorNo es un juicio, es una comprobación de alcance. Cada fila es algo que necesita un creador de correos electrónicos. La columna de la izquierda es el trabajo que poseerías; la derecha es lo que GrapesJS te da antes de escribir un componente.
| Capacidad | Desde cero | Con GrapesJS |
|---|---|---|
| Lienzo visual | Constrúyelo | Disponible |
| Arrastrar y soltar | Constrúyelo | Disponible |
| Modelo de componentes | Constrúyelo | Disponible |
| Biblioteca de bloques | Constrúyelo | Extensible |
| Edición de estilo | Constrúyelo | Disponible |
| Árbol de capas | Constrúyelo | Disponible |
| Deshacer / volver a hacer | Constrúyelo | Disponible |
| Gestión de activos | Constrúyelo | Disponible |
| Integración de almacenamiento | Constrúyelo | Configurable |
| Componentes personalizados | Constrúyelo | Compatible |
| Arquitectura de plugins | Constrúyelo | Compatible |
"Disponible" significa que la capacidad viene con el núcleo y necesita configuración, no construcción. No significa que no necesite trabajo: todo creador serio de correo define sus propios componentes, restringe sus estilos y escribe su propio adaptador de almacenamiento. Verificado frente a grapesjs 0.23.6 en 2026-09-03.
Construye tu producto de correo electrónico, no otro motor de edición.
Listados reales del catálogo GJS.Market, agrupados por la etapa de la construcción a la que pertenecen. Nombres, precios e imágenes vienen directamente del mercado, así que lo que ves aquí es lo que realmente se está a la venta hoy.
Qué convierte un editor de páginas en un editor de correo electrónico: bloques basados en tablas, un Style Manager con forma de correo electrónico, importación y exportación.
Explora la categoríaSecciones de correo ya hechas y una forma de que los usuarios guarden el suyo propio.
Explora la categoríaUn conjunto diseñado de bloques de correo responsivo, para que tu primera biblioteca de bloques no sea una lista en blanco.
Permite a los usuarios guardar sus propios arreglos como bloques reutilizables sin tocar el código de componentes.
Una biblioteca de puntos de partida, para que nadie empiece un correo desde un lienzo vacío.
Explora la categoríaPara la única parte de un correo electrónico que debe estar escrita a mano — un píxel de seguimiento, un bloque específico del proveedor, un fragmento proporcionado legalmente.
Explora la categoríaUn gestor de activos respaldado por almacenamiento que sobrevive al borrador, porque una URL de imagen rota es un correo electrónico roto.
Explora la categoríaRespalda el gestor de activos con Cloudinary, para que las imágenes de correo tengan una URL permanente y transformable.
Una subida UI delante del gestor de activos, con progreso, reintentos y múltiples fuentes.
Cambia el uploader predeterminado por el de Filestack, incluyendo su propio selector y transformaciones.
Dónde se encuentra el proyecto JSON y con qué frecuencia se le permite al editor escribirlo.
Explora la categoríaPersiste proyectar JSON a Firebase sin escribir primero un adaptador de almacenamiento.
Mantén los proyectos de correo en Directus junto con el resto de tu modelo de contenido.
El límite de tasa ahorra, así que una ráfaga de ediciones cuesta una solicitud en lugar de decenas.
Exporta el documento terminado para el traspaso, revisión o una pipeline de construcción existente.
Explora la categoríaAlgunas capacidades de esta página no tienen ningún plugin detrás, y esta sección no inventará ninguno: no hay producto de vista previa o de comprobación de spam, ni producto CSS-inliner, ni producto de etiqueta de fusión ni producto de plantilla de correo electrónico ya hecho en el catálogo. Estos se describen aquí como patrones a implementar, o como trabajo que nuestro equipo puede hacer contigo.
Cuatro montajes, montadas solo a partir de anuncios que existen hoy en día. Empieza en la fila que coincide con lo que estás enviando y añade la siguiente capa cuando gane su lugar.
Un primer editor interno: arrastrar bloques, guardar una plantilla, exportar HTML.
Creación MJML, un conjunto de bloques diseñado, plantillas y una salida de código por componente.
De cara al cliente: salida MJML, registros plantilla, almacenamiento remoto y autosave limitado.
Véase arquitectura SaaSEl editor de un equipo de marketing: bloques, plantillas y recursos alojados que duran más que el borrador.
Los precios provienen del catálogo en vivo en el momento de la compilación. Los listados gratuitos están marcados; los de pago enlazan directamente a su página de producto.
La forma de la obra, en el orden en que tiene sentido hacerla. Cada paso enlaza con la guía que lo cubre correctamente — esta página es un mapa, no un tutorial.
Monta GrapesJS en un contenedor, configura las necesidades de correo de los dos dispositivos y desactiva el almacenamiento local por defecto antes que nada.
Guía de configuración de GrapesJS →Escribe los componentes basados en tablas de los que están hechos tus correos, limita lo que se puede estilizar y expone cada uno como un bloque.
Componentes de correo electrónico en profundidad →Da a los usuarios un lugar para empezar. Guarda las plantillas como proyecto JSON y clonas al usarlas en lugar de editar la original.
Sistemas de plantillas →Implementa un adaptador de almacenamiento en tu API para que los drafts, autosave y versiones sean tuyos para definir.
Plugins de almacenamiento →Genera el marcado al enviar, resuelve las etiquetas de fusión en el lado del servidor y entrega el resultado a tu proveedor.
Busca ayuda con la construcción →
-thumbnail.jpg&w=3840&q=70)
import grapesjs from 'grapesjs';
import newsletter from 'grapesjs-preset-newsletter';
const editor = grapesjs.init({
container: '#email-editor',
height: '100%',
// Email is authored at a fixed width; give users one extra viewport
// to check, not a full responsive breakpoint set.
deviceManager: {
devices: [
{ id: 'desktop', name: 'Desktop', width: '' },
{ id: 'mobile', name: 'Mobile', width: '375px' },
],
},
// Curated blocks only: the preset's table sections, plus your own.
plugins: [
(ed) => newsletter(ed, { inlineCss: true, showBlocksOnLoad: true }),
],
// Point the editor at your API rather than the browser's localStorage.
storageManager: {
type: 'remote',
autosave: true,
stepsBeforeSave: 10,
},
});// An email-safe button: users edit the label and the link,
// never the table markup that makes it render in Outlook.
editor.DomComponents.addType('email-button', {
isComponent: (el) => el.dataset?.type === 'email-button',
model: {
defaults: {
draggable: '[data-gjs-type="cell"], td',
// Users may recolour it; they may not restyle it into a div.
stylable: ['background-color', 'color', 'border-radius'],
traits: [
{ name: 'href', label: 'Link' },
{ name: 'label', label: 'Button text' },
],
components: `
<table role="presentation" cellpadding="0" cellspacing="0">
<tr><td><a href="#">Read the update</a></td></tr>
</table>`,
},
},
});Ambas muestras se ejecutan contra grapesjs 0.23.6. 'grapesjs-preset-newsletter' y 'grapesjs-mjml' son paquetes BSD-3-Clause separados — el núcleo entrega sin preajuste de correo electrónico — así que instala el formato de salida que elegiste arriba.
¿Qué diferencia una demo funcional de un generador de correo electrónico que puedes entregar a los clientes? Todo aquí es tu trabajo, no del editor.
Lo que los usuarios pueden y no pueden hacer.
Nada de lo que crea un usuario debería perderse.
Validado en el servidor, siempre.
Las partes que no tienen que ver con el diseño.
Un generador de correo acepta marcado creado por usuarios y lo envía a terceros. Esa combinación merece más cuidado que una función CRUD típica.
Riesgo
Las regiones bloqueadas, estilos restringidos y bloques ocultos están en el navegador. Una solicitud elaborada puede publicar cualquier proyecto que desee.
Qué hacer
Valida el proyecto guardado en el servidor: regiones requeridas presentes, tipos de componentes en una lista de permisos, campos dentro de los límites.
Riesgo
Un componente de incrustación de código es una solicitud de función que llega a todos los creadores de correo electrónico, y es una superficie de inyección dirigida a las bandejas de entrada de tus clientes.
Qué hacer
Limpia el marcado almacenado y vuelve a desinfectar en el renderizado. Limita quién puede usar un componente de código y registra cada uso del mismo.
Riesgo
Las subidas enviadas por un editor acaban en URLs públicas que duran tanto como el correo electrónico.
Qué hacer
Validar el tipo y tamaño en el servidor, volver a codificar imágenes y servir activos desde un dominio que no contenga cookies de sesión.
Riesgo
El renderizado y el envío son operaciones costosas e irreversibles. Normalmente están protegidas con menos cuidado que la ruta del editor.
Qué hacer
Autoriza por plantilla y por lista de destinatarios, envía con límite de tasa y exige una segunda comprobación antes de que cualquier cosa llegue a una audiencia completa.
Riesgo
Un generador permisivo de plantillas interpolará encantado un campo que el remitente nunca debería ver.
Qué hacer
Resuelve contra una lista explícita de campos permitidos para esa plantilla y falla el renderizado con una etiqueta desconocida en lugar de emitirla.
El editor es una gran dependencia que vive dentro de tu aplicación. Estas son las palancas que importan, en el orden en que normalmente se benefician.
Carga el editor con pereza
Importala solo en la ruta que edita un correo electrónico y solo en el navegador. Nada del editor pertenece a un renderizado del servidor ni a tu paquete principal.
Plugins opcionales de carga perezosa
Un visor de código, un editor de imágenes o un compilador MJML pueden llegar cuando el usuario abre ese panel en lugar de en init.
Mantén la biblioteca de bloques corta
Cada bloque se analiza con marcado al inicio y se renderiza una tarjeta en la paleta. Un conjunto seleccionado es más rápido y seguro.
Debounce autosave
Reduce la velocidad por número de cambios en lugar de por pulsación de teclas, así que una ráfaga de escritura produce una petición en lugar de treinta.
Mantén los datos del proyecto ágiles
Referencia los recursos por URL. Las imágenes de Base64 dentro del proyecto JSON hacen que cada carga, guardado y copia de versión sea más pesado.
Vigila los componentes personalizados
La lógica de componentes que se ejecuta en cada cambio es la causa habitual de un lienzo que se siente lento en correos largos.
Aquí no se citan cifras a propósito: las cifras dependen de tu recuento de bloques, la lógica de tus componentes y el hardware de tus usuarios. Mide la ruta del editor en tu propia aplicación antes y después de cada cambio.
Ahora que la arquitectura está clara, el compromiso es fácil de expresar. Un constructor alojado es más rápido de presentar ante un cliente; un constructor que posees es una característica de tu producto y no una dependencia de él.
Un editor embebido operado por un proveedor, integrado a través de su API y su UI.
Lo que obtienes
La ruta más rápida para llegar a un editor funcional, con la hoja de ruta y los precios que pertenecen a otra persona.
Compárese con un proveedor alojadoUna capa de edición de código abierto que configuras, extiendes y despliegas como parte de tu propia aplicación.
Lo que obtienes
Más trabajo al principio y un editor que crece con tu producto en vez de alrededor de él.
Empieza a construirLas plataformas alojadas difieren sustancialmente entre sí, por eso la columna de la izquierda dice "depende del proveedor" en lugar de hacer una afirmación general. Consulta los términos específicos del proveedor sobre localización, retención, límites de personalización y qué ocurre con tus plantillas si te vas.
GrapesJS se renderiza en un elemento DOM simple, así que integrarlo es una cuestión de qué hook de ciclo de vida llama a init y a cuál llama destroy. Tu framework alimenta tu aplicación; GrapesJS alimenta la capa de edición visual de correo electrónico.
Si prefieres que esto funcione antes que investigarlo, nuestro equipo crea editores de correo basados en GrapesJS como un servicio — incluyendo las partes de esta página que no tienen ningún plugin detrás.
Ofrece a tus usuarios una forma visual de crear correos electrónicos sin obligar a tu equipo de desarrollo a construir un editor de correo desde cero.
Cuéntanos qué tiene que hacer el editor y obtén un plan definido para la integración.
Empieza a construirPresets, bloques, plantillas, plugins de almacenamiento y assets del marketplace.
Explora los plugins de correo electrónicoComponentes, plantillas, almacenamiento y publicación, entregados en tu pila.
Habla con un experto en GrapesJSTus usuarios crean los correos. Tu producto es el dueño de la experiencia.