DEV Community: Avi Flombaum

Turbo View Transitions in Rails

Avi Flombaum — Wed, 21 Feb 2024 16:24:24 +0000

I'm trying to improve my design engineering and have been practicing and looking for opportunities to flex and grow. One of my favorite new techniques is View Transitions, a simple way using CSS to animate transitions between states of the view, whether it's a full page reload or a DOM update. I happen to love JS but I want to write as little of it as possible, especially when it comes to adding and removing classes to facilitate animations. So view transitions really speak to me.

Support for view transitions just hit the Turbo library with the release of Turbo 2.0. Along with DOM morphing support and combined with the rest of Rails, it's a powerful combination where you can achieve some impressive reactivity with really minimal effort, code, and complexity. Let me show you.

All the code for the application is on GitHub and you can see a demo of view transitions with turbo.

Everything here applies to Rails 7 and Turbo 2.0. It's worth upgrading your applications to the modern Rails stack (I just did an update from 6 to main and besides some stuff with webpacker, it really wasn't that bad).

Setup

Our application has Photos that have URLs and likes count. In db/seed.rb I create a few photos. There's also a PhotosController that has index, show and update actions. That's about all you need to know.

Classic View Transitions

The transition we want to implement is the one between the index and show views. When you click on a photo in the index, it should animate the transition to the show view. The first step to accomplish this is to add <meta name="view-transition" content="same-origin" /> to your layout. With that, having nothing to do with Rails, you actually will already get a nice fade transition between the two views as that's the default view transition.

There are great articles on how view transitions work so I'm not going to cover the default use-case in detail.

The basics are that the browser is taking a screenshot of the current page and a screenshot of thew new page and transitioning them between two CSS pseudo-elements of ::view-transition-old and ::view-transition-new. The browser then animates the transition between the two screenshots, the default being a fade. The browser is apparently really great at this effect as we will see.

Focusing the Transition to an Element

Rather than fading the entire page between views, we can focus the transition on a specific element. You're telling the browser to explicity focus the transition of the element from the old to the new view. All you have to do is give the presence of the elements you want to focus the transition on the same view-transition-name property.

This actually took me a second to understand how to use correctly but in our example, what we want to do is tell the browser that the thumbnail of the photo is being transitioned to the full photo element. Instead of just fading the entire page, the browser will focus the transition on moving the thumbnail of the photo into the full photo, which creates a lovely effect of the thumbnail moving and growing into the full photo.

I updated the thumbnail to have a unique view-transition-name property based on the photo id.

app/views/photos/index.html.erb

<img
  class="h-auto max-w-full rounded-lg"
  src="<%= photo.url %>"
  alt="<%= photo.name %>"
  style="view-transition-name: photo_<%= photo.id %>"
>

Now that the thumbnail has a unique view-transition-name, we can tell the browser to focus the transition on the full photo element by giving it the same name.

app/views/photos/_photo.html.erb

content_tag :div, 
  class: "photo-viewer", 
  style: "view-transition-name: #{dom_id(photo)}", 
  id: dom_id(photo)

That's it. Now when you click on a photo, the transition will focus on the thumbnail and animate it into the full photo.

Turbo Frames and Custom Transitions

For my next trick, let's use a custom view transition animation for an element within a turbo frame by implementing an updating "Like" button.

app/views/photos/_photo.html.erb

<%= turbo_frame_tag dom_id(photo, :likes) do %>
  <div class="photo-viewer__like-button" style="view-transition-name: zoom">
    <%= form_for(photo) do |f| %>
      <%= f.button type: 'submit', class: "like-button__link" do %>
        <span class="like-button__icon">❤️</span>
        <span class="like-button__count"><%= photo.likes_count %></span>
      <% end %>
    <% end %>
  </div>
<% end %>

When you click the Like button, it will submit the form looking for the turbo frame with the same id in the response in order to update just the frame contents. After the server updates likes_count, it sends back photos/show.html.erb again which contains the same turbo frame and thus that is the only element to update. Just standard turbo frame magic. If you're curious, here's photos#update, nothing special.

def update
  @photo.increment(:likes_count)
  @photo.save
  redirect_to photo_path(@photo)
end

If you noticed, the element within the turbo frame has a view-transition-name of zoom.

<div class="photo-viewer__like-button" 
  style="view-transition-name: zoom">

This means this element will be animated with a custom view transition we can define called zoom.

But before we can define that zoom transition, we do have to tell Turbo to actually fire the view transition when the turbo frame updates. From How to use View Transitions in Hotwire Turbo:

We need to override the default rendering function for Turbo Frames in the turbo:before-frame-render event handler with a custom one that utilizes View Transitions.

In app/javascript/controllers/application.js:

addEventListener("turbo:before-frame-render", (event) => {
  if (document.startViewTransition) {
    const originalRender = event.detail.render;
    event.detail.render = (currentElement, newElement) => {
      document.startViewTransition(() => originalRender(currentElement, newElement));
    };
  }
});

The handler code first checks whether View Transitions are supported by the browser and if so, it wraps the original rendering function with the document.startViewTransition function. Now when a frame is rendered, the browser will use view transitions to animate the changes.

With that, we can define the zoom transition in our CSS.

app/assets/stylesheets/application.tailwind.css

@keyframes zoomIn {
  from {
    transform: scale(0.5);
    opacity: 0;
  }
  to {
    transform: scale(1);
    opacity: 1;
  }
}

@keyframes zoomOut {
  from {
    transform: scale(1);
    opacity: 1;
  }
  to {
    transform: scale(0.5);
    opacity: 0;
  }
}

::view-transition-new(zoom) {
  animation: zoomIn 0.5s ease forwards;
}

::view-transition-old(zoom) {
  animation: zoomOut 0.5s ease forwards;
}

And viola! We get a really nice effect when the like button is clicked all the while only updating the turbo-frame content.

Turbo Streams and Real-Time Updates

But wait, there's more! We can make the like button update in real-time when another user likes the photo and still have the same view transition firing to animate the change.

First, let's implement the real-time updates. Hold on because it's really complicated with Rails (sarcasm).

Subscribe photos/show to a stream for the photo:

<%= turbo_stream_from @photo %>

Tell the Photo model to broadcast a refresh whenever an instance of Photo is changed.

class Photo < ApplicationRecord
  broadcasts_refreshes
end

And then...well that's it.

We're not done, let's make this even better.

First, now that we're using turbo streams and broadcasting the changes, we can entirely remove the turbo frame from the view. The form will submit and the turbo stream will update the like count and the button on the page you are on as well as any other browser that is viewing the same photo.

Second, we're updating a lot of DOM in this interaction because the turbo stream is broadcasting an entire page update when all that has changed is literally the number inside the like button. Wouldn't it be amazing if we could just update that number and change nothing else? You guessed it, we can. Turbo 8 ships with DOM morphing built-in, we just need to enable it.

To enable this, we just add <%= turbo_refreshes_with method: :morph, scroll: :preserve %> to application.html.erb layout.

Now pay attention to what DOM gets updated when like button is pressed.

Ya, that's right, it's only updating the content of the like button's count (and the form authenticity token because that changed too). Otherwise, nothing about the page's DOM is changed. This is a huge win for performance and user experience. And we literally implemented this with one line of code and 0 Javascript.

Conclusion

Just stop and think for a second about what we've accomplished here. We have an element that will update in real-time across browsers and animate itself and we wrote no Javascript. In fact, we barely wrote any code to accomplish this at all.

The real-time update with morphing totaled 3 lines of code.

Subscribe to the stream.
Broadcast the refresh.
Enable morphing.

All the animations are handled by view transitions. And that's just one of the features, let's not forget where the post started with the cool transition between the thumbnail and the photo.

If you enjoyed this post, please follow me on X/Twitter for more. I'm also available for contract work.

Turbo Frame Slide Over

Avi Flombaum — Sun, 14 Jan 2024 15:41:45 +0000

Another common UI pattern is a slide over. This is a modal that slides in from the side of the screen.

It's really easy it turns out to implement this with a Turbo Frame. Let's do it.

Step 1: The Slide Over Turbo Frame

First, we need to create a Turbo Frame that will be the slide over. We'll call it slide-over and we'll put it at the bottom of the post index page.

app/views/posts/index.html.erb

<div class="w-full"> <% if notice.present? %> <p class="inline-block px-3 py-2 mb-5 font-medium text-green-500 rounded-lg bg-green-50" id="notice"><%= notice %></p> <% end %> <div class="flex items-center justify-between"> <h1 class="text-4xl font-bold">Posts</h1> <%= link_to "New post", new_post_path %> </div> <div id="posts" class="min-w-full"> <%= render @posts %> </div></div><!-- This will be empty when the page loads --><%= turbo_frame_tag "slide-over" %>

We've basically create a frame or a slot that the eventual slide over will occupy on the dom the second that frame is given a URL to load content from.

We want to trigger that frame to load when we click on the new post button. So let's give that button the target of the slide-over turbo frame.

<%= link_to "New post", new_post_path, class: "btn btn-primary", data: {turbo_frame: "slide-over"} %>

Simple enough. When we click on that button now, it will change the source of the slide-over turbo frame and essentially load whatever HTML is the response to /posts/new.

The next step is to turn that into the slide over.

Step 2: The Slide Over

app/views/posts/new

<%= turbo_frame_tag "slide-over" do %> <div aria-labelledby="slide-over-title" role="dialog" aria-modal="true"> <div class="backdrop animate-fade-in"></div> <section> <div class="absolute inset-0 overflow-hidden"> <div class="fixed inset-y-0 right-0 flex max-w-full pl-10 pointer-events-none"> <div class="w-screen max-w-md pointer-events-auto"> <div class="flex flex-col h-full py-6 overflow-y-scroll bg-white shadow-xl"> <div class="px-4 sm:px-6"> <div class="flex items-start justify-between"> <h2 class="text-base font-semibold leading-6 text-gray-900" id="slide-over-title">New Post</h2> <div class="flex items-center ml-3 h-7"> <button type="button" data-action="remove#remove slide-over#slideOut" class="relative text-gray-400 bg-white rounded-md hover:text-gray-500 focus:outline-none focus:ring-2 focus:ring-indigo-500 focus:ring-offset-2"> <span class="absolute -inset-2.5"></span> <span class="sr-only">Close panel</span> <svg class="w-6 h-6" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"> <path stroke-linecap="round" stroke-linejoin="round" d="M6 18L18 6M6 6l12 12" /> </svg> </button> </div> </div> </div> <section> <%= render "form", post: @post %> </section> </div> </div> </div> </div> </div> </div><% end %>

We're putting a basic tailwind slide over as the content for the slide-over turbo frame. Within there is the new post form.

With that, clicking on the new post button will display the slide over but without any of the fancy animations. Let's add that by building a quick stimulus controller.

Step 3: Slide Over Animations

What we want to do is bind the slide over to a stimulus controller so that we can say when the controller connects, which will happen upon the injection of the slide over html into the DOM, trigger the animation classes.

First, let's bind the slide over to a stimulus controller.

app/views/posts/new

<%= turbo_frame_tag "slide-over" do %> <div aria-labelledby="slide-over-title" role="dialog" aria-modal="true" data-controller="slide-over"> <!-- The rest of the slide over --> </div><% end %>

By giving that div the data-controller attribute of slide-over stimulus will look for a slide_over_controller.js file and controller. So let's build that so that it triggers animations upon connecting to it's DOM.

app/javascript/controllers/slide_over_controller.js

import { Controller } from "@hotwired/stimulus";export default class extends Controller { connect() { console.log("The Slide Over has Appeared"); }}

Now, when we click on the new post button, we should see that log in the console.

The next step is to create a target for the animation classes, the DOM element that we want to apply the animations to.

app/views/posts/new

<%= turbo_frame_tag "slide-over" do %> <div aria-labelledby="slide-over-title" role="dialog" aria-modal="true" data-controller="slide-over remove" data-remove-target="element"> <div class="backdrop animate-fade-in"></div> <section> <div class="absolute inset-0 overflow-hidden"> <div class="fixed inset-y-0 right-0 flex max-w-full pl-10 pointer-events-none"> <!-- This element should be the target --> <div class="w-screen max-w-md pointer-events-auto" data-slide-over-target="slideOver"> <div class="flex flex-col h-full py-6 overflow-y-scroll bg-white shadow-xl"> <div class="px-4 sm:px-6"> <div class="flex items-start justify-between"> <h2 class="text-base font-semibold leading-6 text-gray-900" id="slide-over-title">New Post</h2> <div class="flex items-center ml-3 h-7"> <button type="button" class="relative text-gray-400 bg-white rounded-md hover:text-gray-500 focus:outline-none focus:ring-2 focus:ring-indigo-500 focus:ring-offset-2" data-action="remove#remove slide-over#slideOut"> <span class="absolute -inset-2.5"></span> <span class="sr-only">Close panel</span> <svg class="w-6 h-6" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" aria-hidden="true"> <path stroke-linecap="round" stroke-linejoin="round" d="M6 18L18 6M6 6l12 12" /> </svg> </button> </div> </div> </div> <section> <%= render "form", post: @post %> </section> </div> </div> </div> </div> </div> </div><% end %>

We can add that target to the stimulus controller and add the animation classes to it upon connection.

app/javascript/controllers/slide_over_controller.js

import { Controller } from "@hotwired/stimulus";export default class extends Controller { static targets = ["slideOver"]; connect() { this.slideOverTarget.classList.add("translate-x-full"); setTimeout(() => { this.slideOverTarget.classList.remove("translate-x-full"); this.slideOverTarget.classList.add( "transform", "transition", "ease-in-out", "duration-300", "sm:duration-700", "translate-x-0" ); }, 100); } slideOut() { this.slideOverTarget.classList.remove("translate-x-0"); this.slideOverTarget.classList.add( "transform", "transition", "ease-in-out", "duration-300", "sm:duration-700", "translate-x-full" ); }}

Now, when we click on the new post button, the slide over will slide in from the right. And when we click on the close button, it will slide out.

That's it!

Drag and Drop Direct to S3 Active Storage File Uploader

Avi Flombaum — Fri, 11 Aug 2023 00:49:47 +0000

You want a fast fancy uploader to be an easy thing to implement. But it gets tricky. I'll do my best to explain how I built the Uploader for Musicbase using ActiveStorage and Direct Uploads to S3.

It might get complex and there are a lot of steps, but its worth it and you can totally do it.

If you want more resources on the topic, Chris has a great video on Activestorage with Direct Uploads.

The Setup

If you want to follow along, the first thing I did was clone my Rails Starter template. But any Rails app will do. The only thing that's special about my template for the sake of this demo is that it is using importmaps to manage JS dependencies. But we're not going to have any dependencies so it shouldn't matter.

You can follow along by following the commits in the series github repo.

Setup Your Model

Commit

We're going to use a Track model where a track will have a filename, title and artist_name. We'll also add a has_one_attached :audio_file to the model.

rails g model Track filename title artist_name

Then let's install ActiveStorage.

bin/rails active_storage:install

And finally lets add the has_one_attached :audio_file to the model.

app/models/track.rb

class Track < ApplicationRecord
  has_one_attached :audio_file
end

Run your migrations with rails db:migrate.

Let's make sure this worked by uploading an mp3 file to a new track in the console.

track = Track.new
track.audio_file.attach(io: File.open("./spec/fixtures/Plastikbeat - Babarabatiri Loop (Original Mix).mp3"), filename: "01 - The Beatles - I Saw Her Standing There.mp3")
track.save

If you want that file, you can grab it here and put it in spec/fixtures.

Setup S3

Commit

The next step is setting up S3. This has been covered in a lot of places, the Rails Guide are fine. Just make sure to configure the corect CORS settings for a direct upload.

And don't forget to add the aws-sdk-s3 gem with bundle add aws-sdk-s3.

Configure the Correct CORS for Your Bucket

Make sure you configure the correct CORS settings to allow direct uploads. Again, the Rails Guides on CORS are fine. Just make sure you edit the AllowedOrigins section. My CORS looked like this:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT"
        ],
        "AllowedOrigins": [
            "http://localhost",
            "http://127.0.0.1",
            "http://localhost:3000",
            "http://127.0.0.1:3000"
        ],
        "ExposeHeaders": [
            "Origin",
            "Content-Type",
            "Content-MD5",
            "Content-Disposition"
        ],
        "MaxAgeSeconds": 3600
    }
]

Okay, I'm assuming that you setup S3 and changed your ActiveStorage settings to use S3/Amazon.

If you've done all that you should be able to create another track in your console as we did above and this time, after you track.save, try calling track.audio_file.url. You should get back a nice looking S3 URL.

The View

Commit

Let's setup our view.

`overmind`

If you're using my starter template, I use overmind to manage my processes. If you're not using overmind, I highly recommend it. Learn how to use overmind instead of foreman or here Without overmind, you can still run rails s but you should also run bin/rails tailwindcss:watch in another terminal.

If your app is working, you should see my nice starter page.

Tracks Controller

To get our views going, let's generate a tracks_controller with a new and create action.

rails g controller tracks new create

Let's go over to http://localhost:3000/tracks/new

To make our view, we're going to do two things.

First, let's drop the HTML we're going to use in our view.

app/views/tracks/new.html.erb

<div class="w-full">
  <div class="p-6">
    <div id="uploadzone">
      <button
        class="w-full rounded-lg bg-muted border-2 border-dashed border-gray-300 p-8 text-center hover:border-gray-400 focus:outline-none focus:ring-2 focus:ring-indigo-500 focus:ring-offset-2">
        <svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="mx-auto h-12 w-12 text-gray-400"><path d="M17.5 22h.5c.5 0 1-.2 1.4-.6.4-.4.6-.9.6-1.4V7.5L14.5 2H6c-.5 0-1 .2-1.4.6C4.2 3 4 3.5 4 4v3"></path><polyline points="14 2 14 8 20 8"></polyline><path d="M10 20v-1a2 2 0 1 1 4 0v1a2 2 0 1 1-4 0Z"></path><path d="M6 20v-1a2 2 0 1 0-4 0v1a2 2 0 1 0 4 0Z"></path><path d="M2 19v-3a6 6 0 0 1 12 0v3"></path></svg>
        <span class="mt-2 block text-sm font-semibold text-gray-900 dark:text-white">Drag Tracks to Upload or Click Here</span>
      </button>
    </div>
  </div>
  <div id="uploads" class="flex flex-col overflow-y-scroll divide-y border h-[calc(100vh-18em)]">
  </div>
</div>

That's just a bunch of tailwind stuff but it'll make a pretty nice looking upload zone page with a locked container to store all the files that get uploaded in a scrollable window. It'll look like this:

You also have to open app/views/layouts/application.html.erb and change the margin top from 28 to 8 using mt-8.

Building the Upload Zone

We need to have our upload zone be able to accept files. We're going to use the HTML5 File API to do this but it's not that complicated. You could always use a great library like Dropzone.js, but I accidentally promised this would be dependency free even though I used Dropzone.js for production.

Triggering the File Upload

Commit

We need to make it so that when you click on the uploadzone it triggers the familiar File Upload dialog. We're going to do this with a little bit of JavaScript.

The first step is adding a hidden file input field to our HTML, <input type="file" class="hidden" multiple />.

Let's now create a stimulus controller to handle the upload zone.

rails g stimulus uploadzone

Let's build a method in the controller to handle the triggering of the file upload dialog.

app/javascript/controllers/uploadzone_controller.js

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  connect() {}

  trigger() {
    this.element.querySelector("input[type=file]").click();
  }
}

Before we talk about refactoring that at all, let's add the controller and action to our HTML.

Let's make the entire uploadzone div bound to the stimulus controller and add a click event to it.

Edit app/views/tracks/new.html.erb and add the following to the uploadzone div.

<div id="uploadzone" data-controller="uploadzone" data-action="click->uploadzone#trigger">

Now, when you click on the uploadzone div, it'll trigger the trigger method in the controller which will click the hidden file input which will trigger the dialog.

Lovely.

Refactor to Use a Target

Instead of doing our querySelector, let's make the hidden file input a target of our controller named fileInput.

app/javascript/controllers/uploadzone_controller.js

import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  static targets = ["fileInput"];
  connect() {}

  trigger() {
    this.fileInputTarget.click();
  }
}

And in our HTML, to bind the file input as a target:

app/views/tracks/new.html.erb

<input type="file" class="hidden" multiple data-uploadzone-target="fileInput">

Everything should still work.

Drag and Drop

Commit

Preventing Default Drag and Drop Behavior

Now that we have the file input triggering, let's make it so that we can drag and drop files into the uploadzone.

In order to do this, the first thing we need to do is prevent the browser from doing what it normally does when you do a drag and drop.

Let's add this to our stimulus controller:

app/javascript/controllers/uploadzone_controller.js

connect() {
  this.element.addEventListener("dragover", this.preventDragDefaults);
  this.element.addEventListener("dragenter", this.preventDragDefaults);
}

disconnect() {
  this.element.removeEventListener("dragover", this.preventDragDefaults);
  this.element.removeEventListener("dragenter", this.preventDragDefaults);
}

preventDragDefaults(e) {
  e.preventDefault();
  e.stopPropagation();
}

Because our uploadzone is bound to the entire div we want to monitor for the drag and drop, we can do this in our connect hook. this.element represents that uploadzone div, the element of the controller. We're adding listeners to dragover and dragenter which will tell the browser to not do what they normally do by calling our preventDragDefaults method.

When the controller disconnects, let's clean that up by removing the listeners.

You should be able to drag a file into the space and see nothing happen (as opposed to the browser opening your file).

Accepting Files from the Drag and Drop

Now that we've prevented the browser from doing what it normally does, we need to accept the files that are being dragged into the uploadzone. Let's bind another action to our uploadzone div, drop->uploadzone#acceptFiles.

app/views/tracks/new.html.erb

    <div id="uploadzone" data-controller="uploadzone" data-action="click->uploadzone#trigger drop->uploadzone#acceptFiles">

That will make it so that when we drop files into the uploadzone, it'll call the acceptFiles method in our controller.

app/javascript/controllers/uploadzone_controller.js

acceptFiles(event) {
  event.preventDefault();
  const files = event.dataTransfer.files
  debugger;
}

We're going to use the dataTransfer property of the event to get the files that were dropped into the uploadzone. If you now drop a file into the uploadzone, you'll see that the files variable is an array of files in your debugger.

Quick Recap

Set up the HTML for the uploadzone.
Set up the stimulus controller to handle the triggering of the file upload dialog.
Set up the stimulus controller to handle the drag and drop of files into the uploadzone.
Set up the stimulus controller to accept the files that were dragged into the uploadzone.

Our drag and drop left us with a nice array of files that we're going to be able to pass off to some function that handles uploading them. However, we didn't get left with a nice array of files after the click of the uploadzone. Let's fix that so that we have parity between the events, at the end of the file dialog and at the end of the drag and drop we should be left with a nice array of files to pass off to some upload function.

Getting Files from the File Dialog

Commit

The file dialog when completed changes the value of the file input. We can use that to get the files that were selected. We're actually going to be able to re-use our acceptFiles method to do this after a slight modification.

Let's add a change event to our file input in our HTML.

app/views/tracks/new.html.erb

<input type="file" class="hidden" multiple data-uploadzone-target="fileInput" data-action="change->uploadzone#acceptFiles">

Now when that input is changed it will send that event to our acceptFiles method.

What we want to do is modify our acceptFiles to either look for drag and drop dataTransfer files or from files from the file input.

app/javascript/controllers/uploadzone_controller.js

acceptFiles(event) {
 event.preventDefault();
 const files = event.dataTransfer ? event.dataTransfer.files : event.target.files;
 debugger;
}

If event.dataTransfer exists, we know the event was the drag and drop and we can get the files from the dataTransfer. Otherwise, we know the event was from the file input and we can get the files from the target.files.

What We've Built

At this point we've basically built a Drag and Drop file upload component. In fact, we built the shadcn on rails dropzone component.

Cool, right? Now we're ready for the upload which we will cover in part 2 tomorrow.

Why No Rails Components?

Avi Flombaum — Mon, 31 Jul 2023 12:48:00 +0000

Why no Rails Components?

If there are two things you should know about me as a developer it's that I love Ruby on Rails and that I value speed above all else when it comes to building. I've been using Ruby on Rails so well over a decade and one of the reasons I love it so much is because it aligns with my second value of speed. Ruby on Rails is one of the fastest frameworks I've seen to getting web applications up and running while creating a sound architecture for expansion.

I could write a lot about how it does that and put the framework into the context of other frameworks today, but that's not the point of this post. The point of this post is to talk about an area where Ruby on Rails is woefully behind and more to the point, slow.

The Problem: The Frontend

Since the beginning, Rails treated the frontend as a second class citizen. It was always assumed that you would use Rails to render HTML and that was it. If you wanted to do anything more than that, you were on your own. This was fine for a while, but as the web has evolved, this has become a bigger and bigger problem. Where React shines is that it is all frontend. Now obviously, that comes at the expense of so much, but with React, you can really get a stylish and super interactive frontend pretty quick.

The main manner in which React provides developers with this speed is through shareable components that you can just drop into your application and they work. Like look at this shiny piece of frontend beauty magic.

import { Drawer } from 'vaul';

function MyComponent() {
  return (
    <Drawer.Root>
      <Drawer.Trigger>Open</Drawer.Trigger>
      <Drawer.Portal>
        <Drawer.Content>
          <p>Content</p>
        </Drawer.Content>
        <Drawer.Overlay />
      </Drawer.Portal>
    </Drawer.Root>
  );
}

I mean that's pretty cool. I don't know of a mechanism in Rails with which to achieve something like that.

Current Solutions

There are some ways you could get that sort of interoperability and composability of components. One, there are plenty of Javascript libraries that provide the base functionality of such interactions. I can't at the moment find one for that sort of mobile drawer effect, but I'm sure they exist.

These libraries generally provide your application with a javascript object to be initialized and bound to your DOM. So to implement them, you have to put the library in the context of a view, generally include or write markup for the HTML of the component you want to use, perhaps copy and pasting from the library example. You then need to put the javascript library into the context of a stimulus controller and initialize it and bind it correctly. Oh and you also have to account for the styles.

It's possible and it works, its just a good amount of work and each step introduces friction points and breaking potential.

Another more modern concept might be actually using web components. I haven't tried this but you could use libraries like Shoelace. Certainly web components seems to check a lot of the boxes of drop-in interoperable fully encapsulated components.

The thing about those is I have no experience with them, they are pretty modern and I'm not sure what the adoption of them from a developer perspective is like, they certainly require adding a layer of abstraction to your Rails application, it's not as bad as, but it's sort of like saying "if you want this functionality, just use React with your Rails application."

I think there has to be a better way.

What I Want

Looking at that awesome Vaul drawer example, or looking at full component libraries and themes such as the incredibly well designed and popular shadcn, what I want in Rails is something like:

<%= render_drawer do %>
  <%= drawer_trigger "Open" %>
  <%= drawer_content do %>
    <p>Content</p>
  <% end %>
<% end %>

I want that code in my rails views to take care of everything, the underlying markup required, literally the structure of the HTML to create the component and interaction, the styling of the that markup so it looks awesome, and then the javascript, in the form of a stimulus controller bound to the markup, that provides the functionality. I want all of that, I want to think about none of it, and I want to easily be able to customize all parts of it in the future. Is that really so much to ask?

Oh, and also, I want no new dependencies, libraries, or indirections. That is to say, I want all of this accomplished staying as close to vanilla Rails as possible.

The Solution: Rails Components

I'm building Rails Components to solve this problem. I want to be able to drop in components into my Rails applications and have them just work. I want to be able to customize them and I want to be able to do it all without having to think about the underlying HTML, CSS, or Javascript. I want to be able to do it all in Rails. And not only is this possible, I've already shown it to be by porting the majority of shadcn to rails.

In the next few days I'm going to write about why this is important to me, how I'm accomplishing this, and where I'm going with it. So stay tuned, should be a fun week of posts!

I'd would really love your feedback and thoughts on all of this so please, leave a comment or ask a question. And especially if you're already using shadcn on rails, I'd love to hear from you.