react-with-rails
Installation
SKILL.md
React with Rails
Two viable paths: Inertia.js (Rails controllers render React components, no separate API) or classical API + SPA (Rails-API serves JSON; React lives in its own repo or its own folder). Pick wrong and you pay for years.
The opinion
Inertia.js for most React + Rails apps. Classical API + SPA only when you have an explicit reason (multi-platform clients, separate deployment cadence, separate teams). Use
jsbundling-railswith esbuild orvite_rails. Don't add React to a Hotwire app unless you have a concrete need React solves and Turbo doesn't.
Counter-position: React + GraphQL + Apollo + bespoke routing is mature and has its place. For most Rails + React teams in 2026, Inertia is the right default.
Decision matrix
| Need | Use |
|---|---|
| One web client, server-rendered routing, want React's component model | Inertia.js |
| Native mobile client + web SPA + third-party API consumers | Classical API + separate React SPA |
| Heavy real-time + multi-user state | React + dedicated state layer (Liveblocks, Yjs); Rails as API |
| Sprinkles of interactivity on a Rails monolith | Don't. Use Hotwire. |