De React a Rails: Construyendo la Gema Sileo-Rails con Codex
Clonar una librería React de notificaciones en una gema nativa de Rails con Stimulus. En qué me ayudó Codex y para qué todavía hace falta el juicio humano.
Encontré Sileo en un tuit de @midudev: una librería React de notificaciones, con animaciones suaves y una API limpia. Pero mi stack es Rails con Propshaft, no React, así que lo usé de excusa para aprender a trabajar con Codex como par y reconstruirla como una gema de Rails llamada Sileo-Rails, sobre Stimulus. Hubo bastante ida y vuelta.
TL;DR
Por Qué Clonar una Librería React en Rails
El ecosistema Rails tiene gems de notificaciones, pero ninguna igualaba el pulido y la simplicidad de la API de Sileo. La mayoría requería demasiada configuración o producía notificaciones que se sentían anticuadas. El enfoque de Sileo (declarativo, configuración mínima, buenos valores por defecto) era exactamente lo que quería.
Podría haber wrappeado el componente React y publicarlo así. Pero eso significa agregar React a mi pipeline de assets, manejar dependencias npm, y correr un runtime de React para un solo componente de UI. Ese no es el Rails Way, y no se lleva bien con Propshaft.
Así que la pregunta era si podía preservar el diseño y la ergonomía de la API de Sileo mientras lo hacía sentir nativo de un stack Rails + Stimulus.
Qué Ayudó Realmente Codex
Le mostré a Codex el repositorio original de Sileo y le pedí que analizara la estructura de componentes, las animaciones y la API. En minutos tenía un desglose de las animaciones CSS y sus keyframes con sus funciones de timing, los props del componente React y sus valores por defecto, el manejo de estado para el ciclo de vida de la notificación (entrada, activo, salida), y la lógica de posicionamiento para apilar varias notificaciones.
Codex después generó un controlador Stimulus inicial con la lógica de animación principal traducida a JavaScript puro. Manejó la manipulación del DOM para crear, posicionar y remover elementos. Las animaciones CSS pasaron de los styled-components de React a CSS plano que funciona con el pipeline de assets de Propshaft.
¿Bien, no? No tanto. Codex usó yarn e intentó una configuración más complicada de lo necesario para una app Rails 8.1 moderna. Esa fue la parte fácil de arreglar. La parte más difícil fue conseguir el renderizado visual y un comportamiento correcto, y eso requirió varias iteraciones y juicio humano.
Donde Codex realmente brilló fue en el trabajo repetitivo: generar la estructura de la gema, escribir el Railtie para la integración automática, crear los métodos helper para la capa de vista, y construir el DSL de configuración. Estos son patrones muy conocidos en el ecosistema Rails, y Codex los resolvió sin problemas. Después pudo crear todo el scaffolding y la documentación para publicar la gema en RubyGems.
Lo Que Requirió Mucho Juicio Humano
El primer borrador de Codex funcionaba, pero no estaba del todo bien, y los huecos eran de los que solo agarra una persona.
El timing de la animación no se sentía bien. El CSS era técnicamente correcto pero no se sentía tan suave como el original. Tuve que ajustar las funciones de timing cubic-bezier y hacer el ajuste fino de las duraciones, mirando la animación una y otra vez y haciendo micro-ajustes. Trabajo subjetivo, no hay forma de evitarlo.
La estructura y los estilos del DOM no coincidían con los de Sileo, y no lograba que respondiera como yo quería, así que al final recreamos toda la estructura desde cero. El apilado fue otro: varias notificaciones simultáneas tenían que apilarse sin superponerse, y la lógica inicial de Codex no contemplaba los cambios de altura dinámicos cuando las notificaciones tenían longitudes de contenido distintas.
El manejo de memoria era fácil de pasar por alto. El componente React original depende del ciclo de vida de mount/unmount de React. En Stimulus necesitaba asegurar que los controladores se desconectaran bien y que los event listeners se removieran. No es difícil, pero es de esas cosas que te muerden más tarde.
En ergonomía de API a Codex le fue bien: propuso una API Ruby que funcionaba, y nunca toqué una sola línea de Ruby para armar el sitio de demo.
Estos eran bloqueantes porque una librería pulida vive en los detalles. Codex aceleró el primer 80%; el último 20% todavía necesitó mi ojo y me llevó varias horas dejarlo fino.
Por Qué Stimulus Fue la Elección Correcta
Stimulus no trata de ser React. No tiene virtual DOM, no maneja estado complejo, y no pretende ser un framework de aplicación completo. Lo que hace es conectar comportamiento JavaScript a elementos HTML de una manera que se siente natural en una app Rails.
Para las notificaciones eso es perfecto. Son efímeras: aparecen, tal vez se actualizan una o dos veces, y desaparecen. No necesitan manejo de estado complejo. Necesitan una forma de ser disparadas desde el servidor (flash messages) o el cliente (llamadas JavaScript), animaciones CSS para las transiciones de entrada y salida, y manipulación del DOM para el posicionamiento y la remoción.
La gema resultante, sileo-rails, se siente nativa de Rails. Instalala, agregá el helper a tu layout, y llamá a toast.success desde cualquier lugar. Sin React, sin webpack, sin npm install.
Qué Dice Esto Sobre el Desarrollo Asistido por IA
Este proyecto reforzó algo que vengo notando: la IA es buenísima para traducir, no para diseñar. Codex podía mirar código React y producir JavaScript equivalente, generar una estructura de gema que seguía las convenciones Rails, traducir props de componente a firmas de métodos Ruby. Todo trabajo de traducción, y lo hizo bien.
Lo que no podía hacer era tomar decisiones de juicio sobre el feel, la ergonomía o lo apropiado. ¿Es esta animación suficientemente suave? ¿Esta API se siente natural para alguien que escribe Ruby? ¿Es este el nivel de abstracción correcto para una gema Rails? Esas preguntas necesitan contexto y gusto que Codex no tiene.
El patrón que me funciona: usar la IA para el trabajo mecánico de traducción, y después aplicar juicio humano para el refinamiento. Intentar llegar a un primer borrador perfecto a fuerza de prompts lleva más tiempo que iterar a mano en las partes que importan.
No creo que mejores modelos arreglen esto. El gusto no es algo que puedas codificar en un prompt. Se desarrolla con el uso, el feedback y la iteración. La IA produce opciones; alguien todavía tiene que elegir.
Cierre
sileo-rails está en GitHub y RubyGems. Es un proyecto chico, pero captura algo que valoro: usar la IA para ir más rápido en la implementación mientras mantengo el ownership de las decisiones de diseño.
Si trabajás con Rails y querés notificaciones sin arrastrar React a tu stack, dale una oportunidad. Gracias a Aaryan por la librería Sileo original y la inspiración de diseño que hizo que valiera la pena reconstruirla en Rails.