Formularios Anidados en Rails: Uso de Simple Form y Cocoon

Contenido del curso

Introducción

Pruebas

Interacción dinámica

Notificaciones

Ciclos de vida

Cierre

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:36

Formularios Anidados en Rails: Uso de Simple Form y Cocoon

Curso Intermedio de Ruby on Rails

Clase 20 de 34

Clase 20 / 34

Recursos

Comprender cómo se transmite información entre el cliente y el servidor cuando trabajamos con modelos relacionados es fundamental para construir formularios robustos en Rails. La clave está en una convención del HTML que muchas veces pasa desapercibida: el atributo name de los inputs. A continuación se explica paso a paso cómo funciona esta mecánica y por qué no es magia, sino reglas claras de nomenclatura.

¿Cómo se relaciona un formulario HTML con un modelo de Rails?

Todo parte de una taxonomía sencilla. Un formulario contiene etiquetas, inputs y un botón de envío (submit). Los inputs son el vehículo para transportar datos del navegador al servidor, y el submit dispara la acción de envío.

Cuando conectamos esto con Rails, el protagonista es el atributo name de cada input [0:55]. Este atributo indica a qué campo del modelo hace referencia cada dato. Por ejemplo, si tenemos un modelo llamado usuario con dos campos —nombre y apellido—, los inputs generados con SimpleForm lucirían así:

name="usuario[nombre]" → referencia al campo nombre.
name="usuario[apellido]" → referencia al campo apellido.

Si el usuario escribe "Johan" en nombre y "Tique" en apellido, los params que recibe Rails al momento del envío forman un hash de clave-valor [1:25]:

ruby { usuario: { nombre: "Johan", apellido: "Tique" } }

Esta estructura es la que el controlador procesa para crear o actualizar registros.

¿Qué ocurre cuando un modelo tiene asociaciones anidadas?

La complejidad aparece cuando el modelo principal contiene colecciones de otros modelos. Imaginemos que un usuario tiene muchos teléfonos (has_many), y cada teléfono posee dos campos: número y tipo [1:50].

¿Se puede colocar un formulario dentro de otro?

La respuesta directa es no. HTML no permite anidar formularios y esperar que todo funcione correctamente [2:15]. Lo que se hace en su lugar es aplicar convenciones en el atributo name para que tanto el cliente como el servidor entiendan que existe una relación de anidamiento.

¿Cómo se construye la convención de nombres?

Supongamos dos registros de teléfono: uno de tipo "casa" y otro de tipo "oficina". La convención sigue este patrón [2:35]:

name="usuario[telefonos_attributes][0][numero]" → número del primer teléfono.
name="usuario[telefonos_attributes][0][tipo]" → tipo del primer teléfono.
name="usuario[telefonos_attributes][1][numero]" → número del segundo teléfono.
name="usuario[telefonos_attributes][1][tipo]" → tipo del segundo teléfono.

El identificador único (0, 1, etc.) es imprescindible porque cada línea del formulario solo aporta la información de un campo. Sin ese índice, Rails no podría agrupar los campos que pertenecen al mismo registro [2:55].

¿Cómo lucen los params con modelos anidados en el servidor?

Una vez que el formulario se envía, Rails recibe una estructura de hash que refleja la relación [3:40]:

ruby { usuario: { nombre: "Johan", apellido: "Tique", telefonos_attributes: { "0" => { numero: "55555", tipo: "casa" }, "1" => { numero: "66666", tipo: "oficina" } } } }

Esta representación permite que el controlador, mediante accepts_nested_attributes_for, procese tanto el modelo principal como sus asociaciones en una sola operación.

Cuando herramientas como SimpleForm y la gema Cocoon generan dinámicamente campos en el navegador, lo que hacen internamente es crear inputs con esta misma convención de nombres [3:55]. No hay nada oculto: se agregan nodos HTML que siguen las reglas descritas, permitiendo añadir o eliminar registros asociados sin recargar la página.

Entender esta mecánica resulta esencial antes de trabajar con Selectize y Cocoon en conjunto, ya que ambas librerías operan sobre la misma base de formularios anidados para habilitar comportamientos dinámicos en la interfaz. Si tienes dudas sobre cómo se aplica esta convención en tus propios modelos, comparte tu caso y lo revisamos juntos.

Resumen

¿Cómo se relaciona un formulario HTML con un modelo de Rails?

name="usuario[nombre]" → referencia al campo nombre.
name="usuario[apellido]" → referencia al campo apellido.

Si el usuario escribe "Johan" en nombre y "Tique" en apellido, los params que recibe Rails al momento del envío forman un hash de clave-valor [1:25]:

ruby { usuario: { nombre: "Johan", apellido: "Tique" } }

Esta estructura es la que el controlador procesa para crear o actualizar registros.

¿Qué ocurre cuando un modelo tiene asociaciones anidadas?

¿Se puede colocar un formulario dentro de otro?

¿Cómo se construye la convención de nombres?

Supongamos dos registros de teléfono: uno de tipo "casa" y otro de tipo "oficina". La convención sigue este patrón [2:35]:

name="usuario[telefonos_attributes][0][numero]" → número del primer teléfono.
name="usuario[telefonos_attributes][0][tipo]" → tipo del primer teléfono.
name="usuario[telefonos_attributes][1][numero]" → número del segundo teléfono.
name="usuario[telefonos_attributes][1][tipo]" → tipo del segundo teléfono.

¿Cómo lucen los params con modelos anidados en el servidor?

Una vez que el formulario se envía, Rails recibe una estructura de hash que refleja la relación [3:40]:

ruby { usuario: { nombre: "Johan", apellido: "Tique", telefonos_attributes: { "0" => { numero: "55555", tipo: "casa" }, "1" => { numero: "66666", tipo: "oficina" } } } }

Esta representación permite que el controlador, mediante accepts_nested_attributes_for, procese tanto el modelo principal como sus asociaciones en una sola operación.

Introducción

Curso Intermedio de Ruby on Rails: Migración y Optimización Avanzada

Migración de Rails a MongoDB con Mongoid y Pruebas Automatizadas

Gestión de Múltiples Versiones de MongoDB en Linux

Migración de Rails a MongoDB con Mongoid: Configuración Inicial

Migración de Modelos de Active Record a Mongoid

Migración completa de aplicaciones con MongoDB y Rails

Pruebas

Pruebas Automatizadas: Introducción a TDD y BDD en Desarrollo de Software

Creación de Fábricas Automatizadas con FactoryBot y Faker en Rails

Integración de Librerías para Pruebas Automatizadas en Rails

Pruebas de Modelos en Rails con Mongoid y RSpec

Pruebas de Validación y Guardado en Modelos Rails

Validación y Pruebas de Modelos en Ruby on Rails

Pruebas de Integración en Rails: Configuración y Ejecución Básica

Creación y prueba de tareas con métodos POST en Rails

Automatización de Pruebas con Headless Browser y Capybara en Rails

Pruebas de Sistema con KPIBara y WebDriver en Rails

Automatización de Pruebas de Sistema con Selenium y JavaScript

Interacción dinámica

Uso de CoffeeScript con Rails y Webpacker: Integración y Ejemplos

Integración de Selectize con RAILs y Webpacker

Formularios Anidados en Rails: Uso de Simple Form y Cocoon

Implementación Selectize en Formularios Dinámicos con Kokoon y CafeScript

Notificaciones

Envío de Emails Automático al Crear Tareas

Introducción a Service Objects en Ruby on Rails

Pruebas de TDD para Service Object de Notificaciones por Correo

Creación de Service Objects para Envío de Correos en Ruby on Rails

Procesos en Background con Sucker Punch en Rails

Pruebas con Doubles en Rails usando Sucker Punch

Ciclos de vida

Máquinas de Estado Finito: Conceptos y Aplicaciones Prácticas

Creación de Máquinas de Estados con AASM en Ruby on Rails

Creación de Service Object para Gestión de Estados de Tareas en Rails

Acciones de Controlador y Pruebas en Ruby on Rails

Integración de AJAX en Gestión de Estados de Tareas en Ruby on Rails

Cierre

Optimización de rendimiento en aplicaciones web con Ruby on Rails

Migración y Pruebas Automatizadas en Ruby on Rails

Formularios Anidados en Rails: Uso de Simple Form y Cocoon