From Rails scaffold listing to Hotwire infinite scroll

Rails scaffold is a technique for quickly generating a typical CRUD UI.

It's a server-side rendered html which allows listing/editing/creating/deleting records.

One of the promises of the modern approach to building UI (like hotwire or stimulus reflex) is how easy it is to just tweak the backend logic, without using JavaScript at all.

Let's look at the example of infinite scroll - full tutorial how to do it is here and here.

I just want to focus on the "diff" how to make it work.

This is a typical Rails scaffold preparing all the posts to be displayed.

  def index
    @posts = Post.all
  end

This is the equivalent Rails view (rendering html).

  <% @posts.each do |post| %>
    <div>
      <h1><%= post.title %></h1>
      <p><%= post.body %></p>
    </div>
  <% end %>

Now, in order to use Hotwire (actually Turbo Frame) we change the controller to this:

  def index
    @page = params[:page] ? params[:page].to_i : 1
    offset = (@page - 1) * PER_PAGE
    @posts = Post.offset(offset).limit(PER_PAGE)
    @next_page = @page + 1 if @posts.size == PER_PAGE
  end

In short, we pass 3 parameters to the view: page, posts, next_page.

And the view changes to this:

<%= turbo_frame_tag "posts_#{@page}" do %>
  <% @posts.each do |post| %>
    <div>
      <h1><%= post.title %></h1>
      <p><%= post.body %></p>
    </div>
  <% end %>

  <% if @next_page %>
    <%= turbo_frame_tag "posts_#{@next_page}", loading: :lazy, src: posts_path(page: @next_page) %>
  <% end %>
<% end %>

We wrap the whole thing with a turbo_frame_tag and we append more such frames for next pages. That's it.

As you can see the middle of the view stayed the same.

The UI now lists posts and keeps appending them when we scroll down.

I'm not claiming that it's amazing or something. But the practicality of getting our app more interactive, while not jumping to JavaScript is simple yet powerful.

I like it as it allows me to gradually extend my app with new features.

If you like audio to educate yourself then I recommend this podcast to learn more how it works:

https://www.codewithjason.com/rails-with-jason-podcast/episodes/092-vladimir-dementyev-5fK__ZQf/

Comments

[Jamie Gaskins]

This works great in Firefox (and presumably Chrome), but it doesn't work as expected on Safari due to some limitations in Safari's implementation of custom HTML elements (such as turbo-frame). Specifically, it looks like IntersectionObserver callbacks fire on custom elements regardless of whether they're in the viewport, so this implementation loads all pages eagerly.

For things that have a known finite number of pages, this is probably still usable, but if someone's loading a virtually infinite social feed it'll probably crash their browser.

I've noticed a few other minor issues with Turbo and Safari. Nothing that doesn't work at all, but definitely some things that will require some workarounds to work as expected. For example, you can't style a turbo-frame in Safari — you can use it as an ancestor element in a selector but you can't apply styles to it directly.

[Andrzej Krzywda]

Thanks for this, I wasn’t aware.