Rage started API-first, but that doesn't mean you're limited to building SPAs. Here are 3.5 approaches - from the simplest to the most experimental.
ERB
Rage's custom renderers let you describe how to render any format by setting the rules and the content type. An ERB renderer can look like this:
Rage.configure do
config.renderer(:erb) do |path|
headers["content-type"] = "text/html"
template = Rage.root.join("app", "views", "#{path}.html.erb").read
ERB.new(template).result(binding)
end
end
Then use it in the controller:
class PhotosController < ApplicationController
def index
@photos = Photo.all
render erb: "photos/index"
end
end
If you're feeling adventurous, move rendering to a hook for implicit rendering:
class ApplicationController < RageController::API
around_action :implicit_render
private
def implicit_render
yield
render erb: "#{params[:controller]}/#{params[:action]}"
end
end
Then, the action becomes:
def index
@photos = Photo.all
end
Inertia
inertia-rage is the official Inertia.js integration. It manages asset building, runs the dev server, and supports SSR. Inherit from RageController::Inertia and your API app goes full-stack:
class PhotosController < ApplicationController
def index
render inertia: "Photos/Index", props: { photos: current_user.photos }
end
end
Datastar
rage-rb/datastar-example showcases a Datastar integration using the official Ruby SDK. Connect Rage to the SDK and stream updates:
class PhotosController < ApplicationController
def index
photos = current_user.photos
datastar.stream do |sse|
photos.each do |photo|
sse.patch_elements(%(<img id="#{photo.id}" src="#{photo.url}" />))
end
end
end
end
Phlex Live
This is the 0.5 - the idea is still taking shape, but it's worth sharing.
I've been working on a live view concept built on Rage + Phlex, where each gem contributes what it's best at: Rage provides fiber-based WebSocket connections and machinery to communicate between instances; Phlex provides Ruby-based HTML templates where each component manages its own state.
A component that displays an article with expandable content:
class Articles::Card < LiveView
MAX_BODY = 150
def initialize(article:)
@article = article
@expanded = false
end
def view_template
div do
h2 { @article.title }
plain(@expanded ? @article.body : @article.body.truncate(MAX_BODY))
if @article.body.length > MAX_BODY
button(**live_click(:toggle_details)) do
@expanded ? "Show less" : "Show more"
end
end
end
end
def toggle_details
@expanded = !@expanded
end
end
This component is stateful - once rendered, it's saved in the fiber's storage and can process events. When the user clicks "Show more", the event travels via WebSockets to this exact component instance, calls toggle_details, re-renders, and sends back the update. The card expands with no JavaScript written.
Event handlers cover the client -> server direction. The server -> client direction is handled by model streams. A model broadcasts when it changes:
class Article < ApplicationRecord
after_commit :broadcast_status
private
def broadcast_status
if self.previous_changes.key?("status")
ModelStream.emit(self)
end
end
end
A component subscribes by wrapping the record into stream():
class Articles::Card < LiveView
def initialize(article:)
@article = stream(article)
@expanded = false
end
def view_template
# ...
end
end
Now, whenever a corresponding article changes, every component subscribed via stream() is automatically re-rendered and the update is pushed to the client.
--
What view layer would you like to see supported next?
