Building a modal form with Turbo Stream GET requests and custom stream actions

Turbo 7.2 brought major changes to what you can accomplish with Turbo Streams. To demonstrate those changes, today we are going to build a Turbo Stream-powered modal form without a single Turbo Frame. We will also create our own custom Turbo Stream action that emits a custom event on the browser.

The key technique we will use in this article is an update to the standard method of using Turbo to open and populate modals. Prior to Turbo 7.2, Turbo would not allow GET requests to respond directly with Turbo Streams. Smart folks devised a workaround to this limitation which involved using empty Turbo Frames to sneak in Turbo Stream actions. That workaround still works fine, but it is no longer necessary.

As part of our modal implementation, we will also have a chance to build a custom Turbo Stream action. Custom actions are an entirely new feature added in Turbo 7.2, and we will cover enough to get you started with this new tool in Turbo.

When we are finished our application work like this:

To follow along with this article, you will need to be comfortable with Ruby on Rails and you should have some experience using Stimulus. We will move quickly through the Turbo content, so previous exposure to using Turbo Streams will be helpful but is not required. As usual, you can review the complete code for this tutorial on Github.

Let’s get started!

Everyone GET in here! Infinite scroll with Rails, Turbo Streams, and Stimulus

If you have worked with Turbo Streams, you have probably run into a frustrating limitation. From the beginning, Turbo Streams were designed exclusively for handling form submissions, and that was the way it worked. If you wanted to respond to a GET request with a Turbo Stream, you couldn’t, without a clunky workaround.

Until now.

In Turbo 7.2, you can respond to GET requests with Turbo Streams. No more empty Turbo Frame hacks.

To demonstrate, we are going to build a simple Rails application that supports infinite scrolling through a paginated resource using Pagy, Turbo Streams, and a tiny Stimulus controller.

When we are finished, our application will work like this, and we won’t use a single Turbo Frame:

Before we begin, you should be comfortable working with Rails and have at least a passing familiarity with Turbo. If you have never used Turbo before, this article will not be the best starting place. This article is an update to an article I published earlier this year. Reviewing the previous article will help you understand why GET Turbo Streams are such an exciting change.

As usual, you can find the completed code for this tutorial on Github.

Let’s get started!

Interactive charts with Ruby on Rails, StimulusReflex, and ApexCharts

Every B2B web app eventually gets charts. Users love them, buyers love them, sales teams love them. Look at all this data! Look how pretty it is! Charts!

I love charts too. So, let’s build a filterable pie chart with Rails and StimulusReflex. Our chart will rely on data from the database, and, because it is 2022, we will be able to update the chart as the user applies a filter without requiring a full page turn.

To render our charts, we will use ApexCharts, but the technique shown in this article will work fine with any other frontend charting library, I just like ApexCharts.

When we are finished, we will have a Rails app with a chart that looks like this:

(It looks nicer when it isn’t being captured as a low quality gif!)

Before beginning, this article assumes that you are comfortable with Ruby on Rails and that you have a passing familiarity with Stimulus and that you have written a Stimulus controller or two before. You won’t need any prior experience with StimulusReflex to follow along with this article.

As always, you can find the completed code accompanying this article on Github.

Let’s dive in!

Hotwiring Rails Newsletter - August 2022

This newsletter went out via email to the Hotwiring Rails subscriber list, but I know that not everyone wants another email cluttering up their inbox. For those folks, I’ll always publish the full content of the newletter here too, so you can get all the content with none of the emails.

Thoughts or feedback on how I can make this newsletter more valuable? Have something you’d like to include in next month’s edition? Send me an email, or find me on Twitter.

Rails is back isn't enough

The article below is on a topic that has bothered me for a long time — the lack of opportunity for junior Rails developers — spurred by some recent Twitter energy around Ruby on Rails being “back”. I got mentioned in one of the viral threads about Rails being back which jump started my brain into writing this article, but I don’t write it to admonish folks who are excited about Rails and want to bring in more Rails developers with educational content. I love that work, and appreciate the positive energy, and the commitment to building great content. The Rails is back energy just happened to kick off this train of thought about what the long term outlook of the Rails world is when there are few paths for folks to make their living as junior Rails developers.

2022 is an exciting time for Rails developers.

The release of Rails 7 brought Hotwire into the default Rails package along with new asset bundling solutions to get applications off of the dreaded Webpacker. For fans of Redis, the new Kredis gem is a suggested default for Rails 7 applications, offering tools to make it easier for Rails devs to do fun stuff with Redis.

Outside of officially endorsed Rails projects, the StimulusReflex team is steadily making improvements to StimulusReflex, CableReady, and the related set of projects that make building modern, reactive applications in Rails easier than ever.

Despite all of that excitement, folks in the Rails community have gotten used to dealing with “Is Rails dead? Rails is dead.” questions and comments that discourage developers from choosing Rails for their next project.

“Is Rails dead?” questions are silly if you spend any time keeping up with the Rails ecosystem. Rails isn’t dead, it is alive and kicking, just like it has been for nearly 2 decades. Many billions of dollars have been earned riding the Rails and new businesses continue to be built on the foundation that Rails provides.

As a reaction to “Is Rails dead?”, Rails enthusiasts are leaning into a “Rails is back!” narrative — we aren’t dead, we’ve got all this cool new stuff to share!

I don’t think the noise of “Rails is dead!” and “Rails is back” is particularly interesting. Neither narrative adds any value to the conversation. As a Rails enthusiast (and sometime Rails content creator), I love the idea of “Rails is back”, but I don’t think it gets us where we are trying to go.

Writing effective coding tutorials

Writing about what you learn, when done well, is a great way to solidify your own knowledge of a topic, stretch yourself professionally, and establish credibility in your field.

In 2020, I started writing tutorial-style articles for Ruby on Rails developers. Writing these articles began as a fun distraction from a stressful job, and as a way to reconnect with web development as a discipline as my day job pulled me further away from regularly writing code. From that beginning as a distracting hobby, I grew to have a passion for writing tutorials as a way to share my knowledge with internet strangers.

Over the last 18 months, my writing has helped me grow my professional network, find new consulting clients, earn a few thousand dollars in (self-published) book sales, and to feel much more confident in my technical skills.

As I’ve worked to improve my own writing, I have read many, many articles from other developers. Many of those articles have been valuable but I also see very common, correctable mistakes from folks who have knowledge to share but struggle with sharing that knowledge effectively.

Today, I’m sharing some of the most common mistakes I see tutorial writers make and how to correct those mistakes to write more effective tutorials. I will also share the simple formula I use when writing new tutorials.

Hotwiring Rails Newsletter - April 2022

This newsletter went out via email to the Hotwiring Rails subscriber list, but I know that not everyone wants another email cluttering up their inbox. For those folks, I’ll always publish the full content of the newletter here too, so you can get all the content with none of the emails.

Thoughts or feedback on how I can make this newsletter more valuable? Have something you’d like to include in next month’s edition? Send me an email, or find me on Twitter.

Lessons learned from publishing on Gumroad

(This post was originally published on Indie Hackers, but I thought some of my regular blog readers might find it interesting, so I’m publishing it here, with light edits.)

One month ago I published my first ebook on Gumroad. I went into the process with absolutely no idea what I was doing, and no real idea of what to expect. I wanted to see if I could write and sell a book, so I struck out with that goal in mind and winged it all the way to the finish line.

Now that I am through the writing and publishing process, I thought others who are considering writing an ebook (especially a technical book like mine), might find value in hearing about my process along with what went well and what could have gone better.

User notifications with Rails, Noticed, and Hotwire

A nearly-universal need in web applications is user notifications. An event happens in the application that the user cares about, and you inform the user of the event. A common example is in applications that have a commenting system — when a user mentions another user in a comment, the application notifies the mentioned user of that comment through email.

The channel(s) used to notify users of new important events depends on the application but the path very often includes an in-app notification widget that shows the user their latest notifications. Other common options include emails, text messages, Slack, and Discord.

Rails developers that need to add a notification system to their application often turn to Noticed. Noticed is a gem that makes it easy to add new, multi-channel notifications to Rails applications.

Today, we are going to take a look at how Noticed works by using Noticed to implement in-app user notifications. We will send those notifications to logged in users in real-time with Turbo Streams and, for extra fun, we will load user notifications inside of a Turbo Frame.

When we are finished, our application will work like this:

Before we begin, this tutorial assumes that you are comfortable building simple Ruby on Rails applications independently. No prior knowledge of Turbo or Noticed is required.

Let’s dive in!

Toggling view layouts with Kredis, Turbo Frames, and Rails

Kredis is a new gem that makes it easier to work with Redis keys in Ruby on Rails. Kredis was added a suggested gem for new Rails applications starting with the release of Rails 7.0 in December of 2021 and is likely to become a larger force in the Rails world in the coming years.

From the documentation, Kredis “encapsulates higher-level types and data structures around a single key, so you can interact with them as coherent objects rather than isolated procedural commands”.

What this means for us is that we can use Kredis to make it easier to use Redis as a data store in our application. With Kredis, it is simple to use Redis to read and write complex data structures. Kredis’ integration with ActiveRecord allows us to work with Redis data alongside existing models.

Today we will use Kredis to power a card/list view toggle for a resource’s index page, persisting the user’s view preference across requests. This tutorial will offer a gentle introduction into how Kredis works while exploring how Kredis can help us implement a common real-world UX pattern.

We will also add a bit of Turbo functionality in the form of a Turbo Frame to wrap the list of items to make applying the user’s view preference a bit more efficient.

When we are finished, our application will work like this:

Before we begin, this tutorial is best suited for folks with experience building simple applications with Ruby on Rails. If you have never used Rails before, this tutorial will be difficult to follow. You do not need any prior experience with Turbo or Kredis to follow along with this tutorial.

As usual, you can find the complete code for this application on Github.

Let’s start building.