React Email Editor

Qué es, con precisión

React Email Editor (github.com/unlayer/react-email-editor) es el envoltorio oficial en React del editor visual de correo de Unlayer. Renderizas un único componente de editor, guardas una referencia a él y trabajas con los tres métodos que documenta el README: loadDesign vuelve a poner en pantalla una plantilla guardada, saveDesign te entrega el diseño como JSON y exportHtml devuelve HTML responsivo junto con ese JSON. Tu base de datos guarda el JSON para que el usuario pueda editar más tarde, y el HTML para que tu sistema de envío tenga algo que entregar. El repositorio existe desde 2017 y se mantiene con soltura: la versión 2.1.2 salió el 11 de agosto de 2026, y el trabajo que había detrás era arreglo real y no limpieza — un fallo de hidratación en el renderizado de servidor y una fuga antigua por la que los editores nunca se destruían al desmontarse.

La versión 2 es una modernización, y sus propias notas de actualización son inusualmente francas sobre lo que cambió: React 16.8 y Node 18 pasan a ser el mínimo, las importaciones profundas hacia el interior del paquete quedan bloqueadas por un mapa de exportaciones, y el código publicado es ES2019, así que una cadena de herramientas antigua que no pueda analizarlo debería quedarse en la línea 1.x. El paquete incluye la directiva "use client", lo que permite a quien use el App Router de Next.js importarlo directamente en un componente de cliente en lugar de recurrir al habitual apaño con importación dinámica. La salida se comprueba contra Gmail, Apple Mail, Outlook y Yahoo Mail: los cuatro clientes donde el HTML de correo escrito a mano se rompe más a menudo.

Componente abierto, editor alojado: lee dos veces la línea de la licencia

El repositorio es MIT y el README lo dice sin rodeos, pero MIT cubre el componente de React, no el editor que este carga. Es una forma habitual en el software para desarrolladores y conviene tenerla clara, porque "código abierto" en la insignia y "código abierto" en tu registro de riesgos responden a preguntas distintas. Esto es lo que hay en cada sitio.

Dónde encaja un editor de correo en el arsenal de crecimiento de un fundador

La pregunta que hay que resolver antes de instalar nada es de quién son estos correos. Si son tus usuarios quienes redactan y envían correo dentro de tu producto —un CRM, una herramienta de newsletter, un sistema de reservas que manda confirmaciones que alguien quiere con su marca—, un editor integrado es casi inevitable, y construir el tuyo son meses de trabajo que no tienen nada que ver con por qué te compraron el producto. Si solo se trata de tu correo transaccional y de ciclo de vida, no necesitas ningún editor visual: plantillas escritas en código como React Email dan menos trabajo y se versionan mucho mejor.

• Resuelve la producción, no la distribución Un editor hace que los correos se creen más rápido. No opina sobre quién los recibe, si la dirección es entregable o si valía la pena enviar el mensaje.
• Te quita una cola de encima La ventaja real cuando quienes escriben son tus usuarios es que las peticiones de plantillas dejan de llegar como tickets de ingeniería, lo cual es un argumento de carga de soporte y no de crecimiento; está bien comprarlo en esos términos.
• No decide la tasa de apertura La maquetación es la única parte del rendimiento del correo que está prácticamente resuelta. El asunto, el momento, la calidad de la lista y la reputación no lo están, y ninguna de esas cosas aparece en un editor.
• Añade una dependencia en ejecución Un editor alojado e integrado es un tercero dentro del camino crítico de tu producto. Vale la pena aceptarlo a sabiendas, y comprobar que los diseños guardados se seguirán pudiendo abrir si algún día dejas de pagarlo.

Nuestra propia experiencia gestionando el correo en AgentCeres —el Director de Crecimiento con IA, en agentceres.com— apunta en la misma dirección, y las dos cosas que importaron no fueron ni la maquetación ni las herramientas. La primera fue restar: una persona que se registraba y se quedaba unos minutos en el producto podía recibir tres mensajes casi idénticos en unos cinco minutos, cuando la primera investigación automática aterrizaba encima del correo de bienvenida y del aviso de prueba. Borramos un correo en vez de diseñar uno mejor. La producción nunca fue la limitación; la contención sí. La segunda fue el idioma. Todos los mensajes automáticos que enviamos llevan versiones escritas a mano para los mercados que atendemos, en lugar de traducción automática, porque la pasada automática se leía exactamente como una pasada automática, y ese es justo el trabajo con el que ningún editor de arrastrar y soltar, por bueno que sea, habría ayudado. Elige el editor según de quién sean las manos que lo van a usar y dedica el tiempo ahorrado a correos de ciclo de vida que merezca la pena recibir.