Cómo crear un constructor de formularios

Un constructor de formularios permite a las personas diseñar sus propios formularios (elegir campos, fijar reglas, publicar un enlace) y después recoge las respuestas. Por dentro son tres cosas: una definición del formulario guardada como datos, un renderizador que convierte esa definición en un formulario que funciona y un almacén de respuestas con avisos y exportación. Antes de crear uno, comprueba que de verdad lo necesitas: si solo quieres un formulario de contacto o de solicitud, crea ese formulario directamente y olvídate del constructor.

¿Necesitas realmente un constructor?

Un constructor es un proyecto más grande que un formulario, porque cada tipo de campo tiene que funcionar en el editor, en el formulario público, en la validación, en el almacenamiento, en los avisos y en la exportación.

Lo que necesita un constructor de formularios

Definiciones de formulario

Guarda cada formulario como una lista de campos, en datos estructurados (JSON en una columna de Postgres funciona bien). Un campo podría tener este aspecto:

• id: un identificador estable que nunca cambia, aunque cambie la etiqueta
• tipo: texto, correo, número, texto largo, selección, casilla, fecha, archivo
• etiqueta y texto de ayuda
• obligatorio, mín. / máx., tipos de archivo permitidos
• opciones para los campos de selección
• orden y, opcionalmente, una condición («mostrar solo si el campo X es Y»)

El editor modifica esta lista; el formulario público la lee. Ese es todo el truco: no hace falta código nuevo para cada formulario.

Respuestas

• Respuestas: formulario, versión del formulario, fecha de envío, contestaciones indexadas por el ID del campo, estado (nueva, leída, archivada).
• Archivos: los archivos subidos van en el almacenamiento de archivos, y la respuesta guarda solo una referencia. Nunca dentro de la fila de la base de datos.

Páginas

• Lista de formularios con el número de respuestas.
• Editor: añade, reordena y configura campos, con una vista previa en directo al lado.
• Ajustes: mensaje de confirmación o redirección, correos de aviso, fechas de apertura y cierre, límite de envíos.
• Formulario público en su propio enlace y una versión insertable para otras webs.
• Tabla de respuestas con búsqueda, estado, vista de detalle y exportación a CSV.

Decisiones y compensaciones

Versionado. Alguien acabará cambiando «Teléfono» por «Número de móvil» después de 200 respuestas. Si las contestaciones se guardan por ID de campo y cada respuesta registra la versión del formulario, las respuestas antiguas se siguen mostrando bien. Sin eso, tus datos se desordenan sin que lo notes.

La validación se hace dos veces. Comprueba los campos en el navegador para dar una respuesta rápida y otra vez en el servidor, porque cualquiera puede enviar datos directamente a tu endpoint. La comprobación del servidor es la que cuenta.

Subida de archivos. Trae costes de almacenamiento, límites de tamaño, comprobaciones del tipo de archivo y cuestiones de privacidad (currículos, documentos de identidad, formularios médicos). Limita tipos y tamaños y haz que los archivos subidos sean privados por defecto, legibles solo por los propietarios del formulario. Consulta cómo añadir subida de archivos a tu app.

Avisos. «Envíame un correo cuando alguien envíe el formulario» es lo esperado. Necesita un proveedor de correo y una clave de API; consulta cómo enviar correos desde tu app.

Spam. Un formulario público acabará encontrado por bots. Usa un campo trampa (honeypot, oculto para las personas y rellenado por los bots), límites de frecuencia por IP, validación en el servidor y, si hace falta, un servicio CAPTCHA.

Inserción. Insertar un iframe es la forma más sencilla y segura de poner un formulario en la web de otra persona. Un código de inserción con script parece más integrado, pero es más difícil de construir y de proteger.

Lógica condicional. «Mostrar este campo solo si…» es muy popular y multiplica las pruebas. Añádela cuando lo básico ya esté sólido.

Un primer prompt que funciona

Crea una app web de constructor de formularios para mi equipo. Los usuarios con cuenta crean formularios en un editor con vista previa en directo. Tipos de campo: texto corto, texto largo, correo, número, fecha, selección única, casillas de verificación y subida de archivos. Cada campo tiene un ID estable, una etiqueta, un texto de ayuda, una marca de obligatorio y reglas específicas del tipo (mín./máx., opciones, tipos de archivo permitidos y un límite de 10 MB). Guarda la definición del formulario como JSON con un número de versión que aumenta en cada publicación. Cada formulario tiene un enlace público y un código de inserción con iframe. Valida los envíos en el servidor según la versión publicada, guarda las respuestas indexadas por ID de campo junto con la versión del formulario y pon los archivos subidos en un almacenamiento privado. Añade un campo trampa oculto y un límite de envíos por IP. Los propietarios ven una tabla de respuestas con estado (nueva, leída, archivada), una vista de detalle y exportación a CSV. Guárdalo todo en una base de datos. Deja la lógica condicional y los avisos por correo para más adelante.

Pasos de construcción

1. Editor y definición. Crea un formulario con todos los tipos de campo y revisa con el agente el JSON guardado. ¿Es limpio y estable?
2. Formulario público. Rellénalo desde un móvil. Comprueba los mensajes de validación y la pantalla de confirmación.
3. Validación en el servidor. Pide al agente que envíe directamente al servidor, sin pasar por la página, un envío que incumpla las reglas. Debe rechazarse.
4. Versionado. Renombra y reordena campos después de unas cuantas respuestas. Las respuestas antiguas deben seguir mostrando las contestaciones correctas.
5. Subidas. Prueba un archivo demasiado grande y otro de un tipo incorrecto. Confirma que un desconocido no puede abrir un archivo subido adivinando su enlace.
6. Tabla de respuestas y exportación. Comprueba la exportación a CSV con comas, saltos de línea y tildes en las respuestas.
7. Avisos, inserciones, lógica. Añádelos uno a uno.

Errores habituales

• Guardar las respuestas por etiqueta. Las etiquetas cambian. Usa IDs de campo estables.
• Validación solo en el navegador. Es una comodidad, no una protección.
• Archivos subidos públicos. Los formularios suelen recoger documentos que la gente no querría que se vieran.
• Sin protección antispam. Un formulario público puede llenarse de basura en cuestión de días.
• Crear un constructor para un solo formulario. Crea el formulario.
• Envíos ilimitados en un producto público. Si los clientes crean formularios, fija límites por plan, o un formulario popular puede disparar la factura de alojamiento.

Cuándo es mejor un producto ya hecho

Las herramientas de formularios alojadas son excelentes y baratas para la mayoría de necesidades. Ya han resuelto la inserción, el spam, los pagos, las integraciones y la accesibilidad en decenas de tipos de campo. Si tu equipo solo necesita formularios, usa una: consulta alternativas a Typeform y alternativas a Google Forms.

Crea el tuyo cuando las respuestas deban vivir junto a tus propios datos (alimentar un CRM o un portal de clientes que gestionas tú), cuando necesites flujos de trabajo tras el envío que las herramientas no hacen, cuando la ubicación o la propiedad de los datos sea un requisito o cuando los formularios sean una función de un producto que vendes.

Crearlo con Mythex

En Mythex describes el constructor en el chat y pruebas el editor y el formulario público lado a lado en la vista previa en directo. Mythex añade una base de datos dedicada para las definiciones de formulario y las respuestas, y activa el almacenamiento de archivos automáticamente cuando tu app necesita subidas (limitado a 1 GB en el plan gratuito). Los correos de aviso pasan por un proveedor que conectas con tu propia clave. Publica la app en un enlace de mythex.ai o, en Pro, en tu propio dominio, y los enlaces públicos de los formularios funcionarán desde ahí.

Preguntas