Migrating from UJS to Turbo

Hey guys,

I’m really impressed with Hotwire. I have a 5 year old Rails app that has come up through the ranks from Ruby 2.1/Rails 3 back in 2015 to 2.6.5/6.1 now. We also use Mongoid, and we’ve never used turbolinks. Given those things, I was pleasantly very surprised that I was able to get the demo chat app working so quickly.

But then I saw that Turbo requires turning off UJS. That blew me away. UJS is huge part of my app. Turning it off breaks over half the app. Not being able to use UJS feels like a complete dealbreaker. I’ve looked around a bunch and I don’t see anybody else balking at this, so I’m wondering if either:

  1. When I wasn’t looking, UJS fell out of favor and I should have migrated off it a while ago
  2. It’s super easy to migrate from UJS to Turbo but I just haven’t RTFM’d enough
  3. It’s simply expected that migrating from UJS to Turbo is just a Very Hard Thing

To be clear, if the answer 3, then cool so be it. Maybe I’ll still invest the time in playing around with it, but before I do that, I wanted to see if there was something subtle or obvious I was missing :slight_smile:

Thx!

3 Likes

Hmm where does it say that you have to turn off UJS? I just migrated an app from turbolinks to turbo and UJS still works ok.

It says it on this page: GitHub - hotwired/turbo-rails: Use Turbo in your Ruby on Rails app

Rails UJS includes helpers for sending links and forms over XMLHttpRequest, so you can respond with Ajax. Turbo supersedes this functionality, so you should ensure that you’re either running Rails 6.1 with the defaults that turn this off for forms, or that you add config.action_view.form_with_generates_remote_forms = false to your config/application.rb .

Note that the helpers that turn link_to into remote invocations will not currently work with Turbo. Links that have been made remote will not stick within frames nor will they allow you to respond with turbo stream actions. The recommendation is to replace these links with styled button_to , so you’ll flow through a regular form, and you’ll be better off with a11y compliance.

You can still use the data-confirm and data-disable-with .

Do you have any data-remote: true forms in your app?

1 Like

Had a ton of them. They should still work after installing turbo, the biggest issue i had was that the redirects stopped working for turbolinks form submits. I made all forms non remote and that was mostly enough. If you have some .js.erb responses then they would need to be migrated to turbo OR just continue using remote forms.

Hmm ok thanks for the response, Simon. Will noodle on it over here. Have a good one.

My upgrade to Turbo from Turbolinks and UJS started with removing UJS because I had read and heard that the two are not compatible. They submit forms under a different content_type and I figured if Turbo was to replace UJS (another thing I’ve been reading) then I might as well rip it out now.

I found that Turbo, despite much fiddling and googling just wasn’t able to render a redirect response from a form. I tried everything. I reintroduced UJS after trying everything else and installed this shim: turbolinks-rails/redirection.rb at master · turbolinks/turbolinks-rails · GitHub

I now have the right script response and content_type, but the JS just… isn’t executing. I can copy and paste the response body into the console and it does exactly what I want it to - it just doesn’t execute it upon response.

So if you’ve been having issues upgrading to Turbo, you’re not crazy. I’ve found it to be far from the drop-in replacement that some have said it is.