ReActionView makes Rails templates reactive without a client framework

The claim: reactive without a second copy of the page

ReActionView describes itself as reactive views for the HTML+ERB you already have, and the promises are listed as a set of absences: no new syntax, no client framework, no API layer, no build step. The framing is that you get what a client-side framework gives you without adopting one. The mechanism is a template handler rather than a rendering rewrite. Rails 8.2 already renders HTML templates with Herb::Engine, which reads the HTML and the Ruby in a template together, and ReActionView builds on that foundation. The workflow it describes is a template that declares state the browser owns, changes it with an HTML attribute, and has your controller answer when the server is needed. The last clause is the important one, because it is what keeps the server in the loop without a second client-side model of the page to keep in sync with the server-side one.

Installing it and what the generator does

Installation is two commands, one to add the gem and one to run its generator:

bundle add reactionview
bin/rails generate reactionview:install

The generator creates config/initializers/reactionview.rb and imports the client from app/javascript/application.js. From there the branching depends on how you ship JavaScript. On importmap-rails, the gem pins the client for you. With a bundler, you need to install the reactionview npm package as well. That split is a good sign about the design, since it means the gem does not force a JavaScript delivery strategy on the host application, but it also means there are two supported paths to get right and the documentation covers turning on reactive templates and checking that it works. The version requirements are Ruby 3.2 or newer and Rails 7.0 or newer, and the documentation site is reactionview.dev.

Herb's engine comes along on older Rails

The version story is the part to understand before you install, and it is stated in two beats. On Rails 8.2, the Herb::Engine is already there, and ReActionView adds the reactive layer on top of it. On Rails 8.1 and earlier, the gem brings the engine itself. That is a meaningful difference in what you are adding to your application, and it is also why the gem declares compatibility with Rails 7.0 while the natural home for it is 8.2. The engine reads the HTML and the Ruby in a template together, which is what makes the two-way reading possible: a template can both contain markup and carry Ruby that the browser can reach. The repository structure reflects this, with an assets/ directory, a javascript/ directory holding packages for the reactionview client and for dev-tools, and a lib/ directory for the Ruby side.

The debugging story, which is arguably the bigger win

ReActionView also brings Herb's error overlays, the dev tools and per-tag instrumentation to the page. The README's example of what that surfaces is specific and is the kind of detail that matters in practice: a mismatched tag, or a div inside a p, shows up in the browser with the file and the line while you are working. That is a class of error that in a plain ERB template produces a silently wrong page rather than a broken one, and HTML has enough nested-tag rules that a browser will forgive a lot of invalid nesting. Per-tag instrumentation is the other half, and the repository has a dedicated dev-tools package for it, with a separate build script in the package.json. For a team that has been debugging malformed markup by reading rendered HTML in a terminal, having the file and line appear in the browser is a genuine change of workflow.

The package and gem layout

The Ruby side is a gem named reactionview with a gemspec, a Rakefile, a sig/ directory for type signatures, a test/ directory and an Appraisals file for testing against multiple dependency versions, plus gemfiles/ for the appraisal matrix. The JavaScript side is a private npm package named @reactionview/source at version 0.0.0, with a description that calls it the Rails template handler with Herb integration, and it uses yarn with a yarn.lock at the root. The package.json workspaces are docs and javascript/packages/*, and the scripts cover building the client and the dev-tools, cleaning the built assets out of app/assets/javascripts, and running the documentation site with yarn dev, build and preview in the docs directory. The Ruby version is pinned in .ruby-version and the Node version in .node-version, and there is a .rubocop.yml for style, which tells you the project treats itself as a normal gem rather than a script.

Where ReActionView is the wrong choice

Three cases. The first is an application that already has a client-side framework, where adding a second way to express interactivity means two mental models and two build paths for the same page, and the value of the reactive layer drops to zero once you have one. The second is a team on Rails 8.1 or earlier, where the gem pulls in the Herb engine as well, and the cost of a template engine change is higher than the cost of a reactive layer, so it is worth asking whether upgrading Rails first is the better order of operations. The third is anyone who wants the client framework's ecosystem, since a no-build-step approach by definition does not give you the component library, the router and the dev tooling that come with one. Against building a small JSON API and a front end for the few interactions that need to be dynamic, ReActionView's difference in approach is that the interaction lives in the same template as the markup, so there is no duplicated view layer, and the cost is that you are inside a template handler's assumptions rather than a framework's, with a smaller ecosystem to fall back on.

Editorial conclusion

ReActionView is a good fit for a Rails team that has HTML+ERB templates it wants to make interactive incrementally, and that would rather add a template handler than a client framework, a build step and a second copy of the page. It is a poor fit for an application that already committed to a client-side framework, and a poor fit for a codebase that cannot move to Rails 8.2 or later. Check three things before you try it: that you are on Rails 8.2, where the engine is already present, since on Rails 8.1 and earlier the gem brings the engine itself and you should understand that difference, that your Ruby is 3.2 or newer and Rails 7.0 or newer, which the README states as the requirement, and that you are comfortable with the importmap or bundler branch, because on importmap-rails the gem pins the client for you while with a bundler you also install the reactionview npm package.

Frequently asked questions

Official sources

1. License: MIT
2. marcoroth/reactionview on GitHub
3. Project website
4. README
5. Releases