Add supports for render in controllers

[jorgemanrubia]

I published a gem that adds support for render in Rails controllers when using Turbolinks.

I think this should be officially supported by Turbolinks and I am willing to work on that PR.
I would include a comprehensive suite of tests as part of the PR, and I am willing to follow any guideline or consideration you may have. I just don't want to do the work if there is no hope to have it used.

As mentioned in this comment:

I think the situation right now is inconsistent and can be really confusing:

• Rails 5 adds Turbolinks by default
• Forms are remote by default
• render won't work with the defaults mentioned above.

The fact that forms in scaffolds are generated with local: true in Rails 5.2 looks like an smell to me. The vanilla code generated by Rails won't use its own defaults!

[mrhead]

Nice work @jorgemanrubia! I agree, that this (or something similar) should be enabled in Rails by default so default remote forms don't need any custom SJR. And if they need it, then Turbolinks can be disabled for the action and custom SJR can be returned.

[ghost]

Any news on this?

[jorgemanrubia]

@sstephenson @rafaelfranca could you please weight in on this one? I am really good with any decision, I just suspect this hasn't even entered into your radar yet.

In addition to my comment above, I wrote a couple of pieces on why I think this should be officially supported by Rails:

• On form validations with modern rails
• On why I created the gem

The library got much better on latest iterations but I know there are probably additional scenarios to handle. As mentioned above, I'd love to put the work to make this happen.

Thanks!

[ghost]

@jorgemanrubia This looks great! We need this in rails core, or something similar. My only addition would be to allow the scroll position reset to be optionally disabled as this can sometimes be useful on a search results page; so that you can do dynamic filtering etc.

[MrHubble]

I believe @sstephenson and @javan suggested this might be included in Turbolinks 6 on the Remote Ruby podcast:

They each share how they got started programming, a brief insight into how they work at Basecamp, the transition from CoffeeScript to ES6, Typescript, as well as (wait for it...) upcoming features in Stimulus (🙌) and considerations for Turbolinks 6 (no feature promises made 😉).

[jorgemanrubia]

Thanks @MrHubble, that's great news. I haven't been able to get any kind of response on this one despite of trying different channels so I'll grasp at this 🤷🏽‍♂️.

[roelandmoors]

I'm a new Rails user and I was really confused with forms not just working. At first nothing was working because a xhr request occurred and I didn't know I should handle it. I then handled it with custom javascript to only replace the form, but error handling was not working correctly.
I then installed this Gem and now it works as I hoped it would the first time.

I really hope a solution like this will go into Rails/Turbolinks by default.

[manuelmeurer]

Ping @sstephenson @rafaelfranca, it would be really great to hear the Turbolinks team official stance on this! 😄

[xiobot]

Please let's have this in core!

[ahoward]

yes. js in rails needs to work or all-js starts feeling better ;-/

[jbakerdev]

@sstephenson @rafaelfranca - Another vote to include in core. Sure seems like the missing link...

[jorgemanrubia]

I can confirm Turbolinks 6 will handle form submissions in a way that makes this unnecessary, among many other goodies 😀

[MrHubble]

@jorgemanrubia that's great news! Is this something you're personally working on at Basecamp?

For someone who has yet to tackle this problem, would you recommend using your turbolinks-render gem or wait for Turbolinks 6 to be released? The main concerns are ease of migrating from turbolinks_render to use Turbolinks 6, and the unknowns around a potential release date for Turbolinks 6.

[jorgemanrubia]

@MrHubble I am not working on Turbolinks 6. @sstephenson and @javan are. It will introduce a bunch of new features that, among other things, will solve the problem this gem addressed. It will use a different approach compared to the gem, so it should not affect to your decision of using the gem now (it won't make adopting it harder or easier).

Sorry I can't share more details yet. Hopefully we'll have exciting news about the new version next year. I attended an internal presentation and all I can say is that it's going to be huge.

[amitsaxena]

@jorgemanrubia I guess no movement on this or Turbolinks 6 even after more than an year? What's the recommended way to handle remote forms these days? 😄

[jorgemanrubia]

My recommendation would still be turbolinks-rails until Turbolinks 6 is released. I know it's taking a long time. Hadn't being this year so crazy it would be already out.

[amitsaxena]

Creating simple forms in a fresh rails 6 app is a pain these days. I miss the golden convention our configuration days when it was so simple to keep moving 😄

For some reason redirect_to now no longer works for my turbolinks forms (though it seems to work in a fresh app). The logs say Redirected to xyz but no real redirect happens. Not sure what's happening. Also relying on redirect for ajax requests seems fragile to me given what if future versions of rails just broke this behaviour (not sure if redirect_to works across all remote requests even now). Other people seemingly are complaining about rails forms as well:
https://discuss.rubyonrails.org/t/default-handling-of-remote-forms/74680

It would be so nice if the defaults for forms were fixed and the rails guides gave examples of how to build forms in a rails app. The current information is scattered and incomplete. Or have we just assumed that everyone is using SPAs these days. The barrier to entry for a newcomer seems significant as of now and I am not sure if that's helpful for growing the community.

[amitsaxena]

Additionally I have no idea where turbolinks 6 is (there is no branch with that name and I don't see a turbolinks-next either) and if it is being worked upon. So I have no idea if it's coming in 2020 or 2025 🤔

I guess I'll go with local: true for now (default rails scaffolds seem to be using that hack as well instead of doing it the recommended rails way) to move forward.

[manuelmeurer]

@amitsaxena Unfortunately you're right, there is not much info on when the next version of Turbolinks will be available.
There is a thread about it on the Rails discussion forum: https://discuss.rubyonrails.org/t/turbolinks-and-stimulus-are-developed-behind-a-wall/75124

It would be so nice if the defaults for forms were fixed and the rails guides gave examples of how to build forms in a rails app.

The Rails guides are open-source and everyone can contribute! If you can't find something that you think should be in there, consider adding it:
https://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#contributing-to-the-rails-documentation

[dsazup]

I can confirm Turbolinks 6 will handle form submissions in a way that makes this unnecessary, among many other goodies 😀

Hey @jorgemanrubia, now that hotwire is out, do you think this is still relevant? It seems the gem you have created and hotwire works a bit different. Your gem replaces the whole page and is very automatic, whereas hotwire requires to add respond_to turbo_stream for every form and it creates a lot of work. I still think it would be really great to have something like this in the core (or maybe v2 of your gem 😄 )

[leastbad]

I had two hopes for Hotwire: that it would fix remote form validations and provide a viable Android wrapper. I am grateful for the Android wrapper, don't doubt for a moment.

I created Optimism to handle validations for remote UJS forms. I was really excited to sunset the library, because it shouldn't need to exist.

You're our human on the inside. Please, we're counting on you!

[jorgemanrubia]

Support for form validations is totally in the plans. There is a PR here with a proposed solution. We discussed this internally before releasing Hotwire and, while it was left out for launch, we agreed this was necessary as it's a common Rails pattern.

[jorgemanrubia]

This is handled now in latest turbo beta. Kudos to @seanpdoyle for tackling this!

[bdavidxyz]

@jorgemanrubia @seanpdoyle It actually works only for the error scenario. For the happy path, if the form submission simply render something, it doesn't (yet) works.
Scenario where you do some in-place editing (so you POST some data, but stay on the same page with some valid feeback displayed) are actually pretty common.
How to handle this right now ?