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.

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!

@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 🤷🏽‍♂️.

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.