De React a Rails: creando la Gem Sileo-Rails con Codex

Encontré Sileo en un tuit de @midudev, una librería React bonita, con animaciones suaves, y una API limpia. Pero mi stack es Rails con Propshaft, no React. Así que aproveché la oportunidad para aprender a usar Codex para reconstruirla como una gema de Rails llamada Sileo-Rails usando Stimulus. Con Codex tuvimos fuertes discusiones y muchas iteraciones.

¿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, valores por defecto muy buenos, 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, e introducir un runtime de React para un solo componente UI. Ese no es el Rails Way, y no se lleva bien con Propshaft.

La pregunta fue: ¿puedo preservar el diseño y la ergonomía de API de Sileo mientras lo hago sentir nativo para 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 keyframe 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)
• La lógica de posicionamiento para apilar múltiples notificaciones

Codex luego generó un controlador Stimulus inicial con la lógica de animación core traducida a JavaScript puro. Manejó la manipulación del DOM para crear, posicionar y remover elementos. Las animaciones CSS fueron convertidas 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, lo que requirió múltiples iteraciones y juicio humano.

Donde Codex realmente brilló fue en el trabajo repetitivo: generar la estructura de la gem, escribir el Railtie para 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 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. Los problemas requirieron juicio y ojo humano:

• El timing de animación no se sentía correcto. Las animaciones CSS eran técnicamente correctas pero no se sentían tan suaves como el original. Tuve que ajustar las funciones de timing cubic-bezier y hacer el ajuste fino de las duraciones. Este es trabajo subjetivo que requiere mirar la animación repetidamente y hacer micro-ajustes.
• Estructura y estilos del DOM. Codex generó una estructura DOM funcional, pero no coincidía exactamente con la de Sileo o no lográbamos que responda como esperábamos. Eventualmente recreamos toda la estructura desde cero.
• Comportamiento de apilamiento. Múltiples notificaciones simultáneas necesitaban apilarse correctamente sin superponerse. La lógica inicial de Codex no contemplaba cambios de altura dinámicos cuando las notificaciones tenían longitudes de contenido variables.
• Manejo de memoria. El componente React original depende del ciclo de vida de mount/unmount de React. En Stimulus, necesitaba asegurar que los controladores se desconectaran apropiadamente y los event listeners se removieran. No difícil, pero fácil de pasar por alto.
• Ergonomía de API. Codex propuso una API Ruby que funcionaba, realmente nunca toqué una sola línea de código Ruby para hacer el sitio de demo.

Muchos de estos fueron bloqueantes porque una librería pulida requiere atención al detalle. Codex aceleró el primer 80%; el último 20% todavía necesitó mi ojo y me llevó varias horas perfeccionarlo.

¿Por qué Stimulus fue la elección correcta?

Stimulus no está tratando 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 aplicación Rails.

Para un sistema de notificaciones, esto es perfecto. Las notificaciones son elementos UI efímeros que aparecen, tal vez se actualizan una o dos veces, y desaparecen. No necesitan manejo de estado complejo. Necesitan:

• Una forma de ser disparados desde el servidor (flash messages) o cliente (llamadas JavaScript)
• Animaciones CSS para transiciones de entrada/salida
• Manipulación del DOM para posicionamiento y remoción

La gem resultante, sileo-rails, se siente nativa del ecosistema Rails. Instálala, agrega el helper a tu layout, y empieza a llamar toast.success desde cualquier lugar. Sin React, sin webpack, sin npm install.

Qué Dice Esto Sobre Desarrollo Asistido por IA

Este proyecto reforzó algo que he estado notando: la IA sobresale en traducción, no en diseño. Codex podía mirar código React y producir JavaScript equivalente. Podía generar una estructura de gem siguiendo convenciones Rails. Podía traducir props de componente a firmas de métodos Ruby.

Lo que no podía hacer era tomar decisiones de juicio sobre feel, ergonomía, o apropiedad. ¿Es esta animación suficientemente suave? ¿Esta API se siente natural para un desarrollador Ruby? ¿Es este el nivel de abstracción correcto para una gem Rails? Estas preguntas requieren contexto y gusto que Codex no tiene.

El patrón productivo que he encontrado es: usar IA para el trabajo mecánico de traducción, luego aplicar juicio humano para refinamiento. La alternativa—tratar de prompt-engineerear tu camino hacia un primer borrador perfecto—toma más tiempo que simplemente iterar manualmente en las partes que importan.

Esto no es una limitación de la IA actual que será resuelta por mejores modelos. Es un error de categoría fundamental. El gusto no es algo que puedas codificar en un prompt. Se desarrolla a través de uso, feedback, e iteración. La IA puede producir opciones; el humano tiene que elegir.

Cierre

sileo-rails está disponible en GitHub y RubyGems. Es un proyecto pequeño, pero representa algo que encuentro valioso: usar IA para acelerar implementación mientras mantengo ownership de las decisiones de diseño.

Si estás trabajando con Rails y querés notificaciones sin traer React a tu stack, dale una oportunidad. Y si estás pensando en como la IA encaja en tu propio flujo de trabajo de desarrollo, considerá donde termina la traducción y comienza el juicio. La línea es más importante que la herramienta.

Gracias a Aaryan por la librería Sileo original y la inspiración de diseño que hizo que este proyecto valiera la pena reconstruirlo en Rails.