Five Turbo Lessons I Learned the Hard Way

We've been using Turbo on our latest client project (a Ruby on Rails web application), and after a slight learning curve, we've been super impressed by how much dynamic behavior it's allowed us to add while writing very little code. We have hit some gotchas (or at least some undocumented behavior), often with solutions that lie deep in GitHub issue threads. Here are a few of the things we've discovered along our Turbo journey.

Turbo Stream fragments are server responses (and you don't have to write them by hand) #

The docs on Turbo Streams kind of bury the lede. They start out with the markup to update the client, and only further down illustrate how to use them in a Rails app. Here's the thing: you don't really need to write any stream markup at all. It's (IMHO) cleaner to just use the built-in Rails methods, i.e.

render turbo_stream: turbo_stream.update("flash", partial: "shared/flash")

And though DHH would disagree, you can use an array to make multiple updates to the page.

Send :unprocessable_entity to re-render a form with errors #

For create/update actions, we follow the usual pattern of redirect on success, re-render the form on error. Once you enable Turbo, however, that direct rendering stops working. The solution is to return a 422 status, though we prefer the :unprocessable_entity alias (so like render :new, status: :unprocessable_entity). This seems to work well with and without JavaScript and inside or outside of a Turbo frame.

Use data-turbo="false" to break out of a frame #

If you have a link inside of a frame that you want to bypass the default Turbo behavior and trigger a full page reload, include the data-turbo="false" attribute (or use data: { turbo: false } in your helper).

Update from good guy Leo: you can also use target="_top" to load all the content from the response without doing a full page reload, which seems (to me, David) what you typically want except under specific circumstances.

Use requestSubmit() to trigger a Turbo form submission via JavaScript #

If you have some JavaScript (say in a Stimulus controller) that you want to trigger a form submission with a Turbo response, you can't use the usual submit() method. This discussion thread sums it up well:

It turns out that the turbo-stream mechanism listens for form submission events, and for some reason the submit() function does not emit a form submission event. That means that it’ll bring back a normal HTML response. That said, it looks like there’s another method, requestSubmit() which does issue a submit event. Weird stuff from JavaScript land.

So, yeah, use requestSubmit() (i.e. this.formTarget.requestSubmit()) and you're golden (except in Safari, where you might need this polyfill).

Loading the same URL multiple times in a Turbo Frame #

I hit an interesting issue with a form inside a frame: in a listing of comments, I set it up where you could click an edit link, and the content would be swapped out for an edit form using a Turbo Frame. Update and save your comment, and the new content would render. Issue was, if you hit the edit link again, nothing would happen. Turns out, a Turbo frame won’t reload a URL if it thinks it already has the contents of that URL (which it tracks in a src attribute).

The solution I found was to append a timestamp to the URL to ensure it's always unique. Works like a charm.

Update from good guy Joshua: this has been fixed an a recent update.

These small issues aside, Turbo has been a BLAST to work with and has allowed us to easily build a highly dynamic app that works surprisingly well even with JavaScript disabled. We're excited to see how this technology develops.