2026-02-17

From React to Rails: building Sileo-Rails Gem with Codex

Cloning a React toast library into a Rails-native gem using Stimulus. What Codex helped with, what still required engineering judgment, and why Stimulus was the right fit.

~8 min read • rails, ruby, stimulus, propshaft, ai-assisted-development, codex, software-engineering

I found Sileo in a Tweet by @midudev, a beautiful React library with smooth animations and a clean API. But my stack is Rails with Propshaft, not React. So I took the opportunity to learn how to use Codex to rebuild it as a Rails gem named Sileo-Rails using Stimulus, using it as my pair programmer. It was a hard discussion and many iterations.

Why Clone a React Library into Rails?

The Rails ecosystem has toast notification gems, but none matched the polish and simplicity of Sileo's API. Most required too much configuration or produced notifications that felt dated. Sileo's approach, declarative, minimal setup, beautiful defaults, was exactly what I wanted.

I could have wrapped the React component and shipped it that way. But that means adding React to my asset pipeline, managing npm dependencies, and introducing a React runtime for a single UI component. That's not the Rails way, and it's certainly not the Propshaft way.

The question became: can I preserve Sileo's design and API ergonomics while making it feel native to a Rails + Stimulus stack?

What Codex Actually Helped With

I pointed Codex at the original Sileo repository and asked it to analyze the component structure, animations, and API surface. Within minutes, I had a breakdown of:

  • The CSS keyframe animations and their timing functions
  • The React component props and their default values
  • The state management for toast lifecycle (enter, active, exit)
  • The positioning logic for stacking multiple toasts

Codex then generated an initial Stimulus controller with the core animation logic translated to vanilla JavaScript. It handled the DOM manipulation for creating, positioning, and removing toast elements. The CSS animations were converted from React's styled-components to plain CSS that works with Propshaft's asset pipeline.

Good right? Not quite. Codex used yarn and tried a more complicated setup than necessary for a modern Rails 8.1 app. That was the easy part to fix. The harder part was about getting the right visual rendering and behavior, which required multiple iterations and human judgment.

Where Codex really shined was the repetitive work: generating the gem structure, writing the Railtie for automatic integration, creating the helper methods for the view layer, and building the configuration DSL. These are well-understood patterns in the Rails ecosystem, and Codex navigated them competently. Later it was able to create all the scaffolding and documentation to publish the gem to RubyGems.

What Still Required Engineering Judgment

Codex's first draft worked, but it wasn't quite right. The issues required human judgment:

  • Animation timing felt off. The CSS animations were technically correct but didn't feel as smooth as the original. I had to adjust the cubic-bezier timing functions and fine-tune durations. This is subjective work that requires watching the animation repeatedly and making micro-adjustments.
  • DOM structure and styling. Codex generated a functional DOM structure, but it didn't match Sileo's exactly. Eventually we recreated the whole structure from scratch.
  • Stacking behavior. Multiple toasts needed to stack properly without overlapping. Codex's initial logic didn't account for dynamic height changes when toasts had varying content lengths.
  • Memory management. The original React component relies on React's unmount lifecycle. In Stimulus, I needed to ensure controllers were properly disconnected and event listeners removed. Not difficult, but easy to miss.
  • API ergonomics. Codex proposed a Ruby API that worked, I really never touched a single line of ruby code to make the demo site.

Many of these were blockers because a polished library requires attention to detail. Codex accelerated the first 80%; the last 20% still needed my eye and took me several hours to perfect.

Why Stimulus Was the Right Fit

Stimulus isn't trying to be React. It doesn't have a virtual DOM, it doesn't manage complex state, and it doesn't pretend to be a full application framework. What it does is connect JavaScript behavior to HTML elements in a way that feels natural in a Rails application.

For a toast notification system, this is perfect. Toasts are ephemeral UI elements that appear, maybe update once or twice, and disappear. They don't need complex state management. They need:

  • A way to be triggered from the server (flash messages) or client (JavaScript calls)
  • CSS animations for enter/exit transitions
  • DOM manipulation for positioning and removal

The resulting gem, sileo-rails, feels native to the Rails ecosystem. Install it, add the helper to your layout, and start calling toast.success from anywhere. No React, no webpack, no npm install.

What This Says About AI-Assisted Development

This project reinforced something I've been noticing: AI excels at translation, not design. Codex could look at React code and produce equivalent JavaScript. It could generate a gem structure following Rails conventions. It could translate component props to Ruby method signatures.

What it couldn't do was make judgment calls about feel, ergonomics, or appropriateness. Is this animation smooth enough? Does this API feel natural to a Ruby developer? Is this the right abstraction level for a Rails gem? These questions require context and taste that Codex doesn't have.

The productive pattern I've found is: use AI for the mechanical translation work, then apply human judgment for refinement. The alternative, trying to prompt-engineer your way to a perfect first draft, takes longer than just iterating manually on the parts that matter.

This isn't a limitation of current AI that will be solved by better models. It's a fundamental category error. Taste isn't something you can encode in a prompt. It's developed through use, feedback, and iteration. The AI can produce options; the human has to choose.

Closing

sileo-rails is available on GitHub and RubyGems. It's a small project, but it represents something I find valuable: using AI to accelerate implementation while maintaining ownership of design decisions.

If you're working with Rails and want toast notifications without bringing React into your stack, give it a try. And if you're thinking about how AI fits into your own development workflow, consider where translation ends and judgment begins. The line is more important than the tool.

Thanks to Aaryan for the original Sileo library and the design inspiration that made this project worth rebuilding in Rails.