I’m having trouble submitting a form from a Bootstrap modal. Despite it being a POST, the turbo-stream header isn’t being added and my controller isn’t using the format.turbo_stream response.
Started POST "/admin/service_areas/1/contacts" for ::1 at 2021-05-08...
Processing by Admin::ServiceAreas::ContactsController#create as HTML
I’ve been modeling my code after the excellent @dstull article here. It’s a bit different because of Bootstrap, but everything’s working except when I submit the form with server validation errors. (I’m redirecting on the success path, so streaming isn’t an issue.)
I’m about to create a small test project to try this out on to simplify things, but even if there are bugs, why won’t it submit as TURBO_STREAM? My destroy code works fine. My form is defined like this (simplified a bit, but the html looks correct):
<%= form_with model: @contact, url: @contact_submit_path do |f| %>
Any ideas? I’m stumped. I can’t think of any reason why the submit only supports HTML.
Thanks - Dave
Hi Dave,
I am glad you found the article useful.
I updated it for the latest turbo upgrade which changed the posts to be html like you are showing here. I spent hours trying to figure out why when I upgraded turbo past 0.5.4 I believe and it was an intentional change.
Did you get a chance to see the latest source code for that? Linking here for you app/controllers/posts_controller.rb · master · Doug Stull / turbo_modal · GitLab
Thanks, Doug. I’ve got the same controller code as you, but things seem to behave differently. Running your project, I get:
Started POST "/posts" for ::1 at 2021-05-08 17:18:28 -0400
Processing by PostsController#create as TURBO_STREAM
where mine is “as HTML”. The turbo-rails versions are the same (0.5.9), but I did notice some differences that might affect things. My Gemfile includes “turbo-rails”, while yours includes “hotwire-rails”. And my package.json shows “@hotwired/turbo-rails”, while yours does not.
Not sure how I got there, so I’m looking into the proper way to set up a rails project for Hotwire. I originally created this project with Stimulus, then added turbo later, so maybe that’s it. Not sure if any of this makes a difference, either. Very confused.
Thanks again. I’ll continue posting what I find out.
Ahh. Sounds like some turbo versions could be stepping on each other. If your turbo version is lower somehow due to some contention there, that will likely cause it
I found that part could get complicated as well. Some other areas to look at could be in the application layout and application js files
If you get that sample app up it could help figure it out if you get stuck.
OK, I’ve got a sample app. I really struggled with this. Bootstrap’s modals gave me trouble, I kept getting multiple (darker) backdrops (really, multiple modals, but it was my fault). I was sorely tempted to give up on Turbo several times. Not sure if it’s really weird, poorly documented, buggy, or all of the above. 
Anyway, I can do the full range of CRUD activities on a post now, and (almost) everything’s working. Editing posts was working with redirects, but now I’m shooting for in-place updating. That’s working, but my modal is staying up. Trying to figure that out now.
FYI: I started getting the same turbo_stream behavior as your project when I used “hotwire-rails” in my Gemfile. Haven’t tried moving things back over to my big project yet.
Thanks again for your assistance. If you want to try things out, here’s the link.
https://github.com/dparfrey/turbo_modal_bootstrap
Got it! I created a “close-modal” controller that I put on the row when it’s updated. That controller simply closes the modal when it gets connected. Works like a charm.
I don’t think it’ll be a problem after updating multiple rows, since the controller won’t get re-connected, and it should disappear on a page refresh. And even if I’m wrong, only the first instance should find a modal to hide. I hope.
If there are any Bootstrap users out there, here’s an approach that can work.
https://github.com/dparfrey/turbo_modal_bootstrap
1 Like