solved: switch to dis-able turbo/hotwire/etc?

How can I disable all the fancy magic, not quite full baked, stuff that might interfere with a simple click-a-link, re-render page?

It's the one thing the Jumpstart config does not let you turn off/on.

Running into hard-to-debug issues related  to "if you load or reload a page it works" but "if you navigate there from another page it doesn't". 

Rather than waste more time debugging half-cooked Rails magic, I need to get the app done and page load speed is (literally) the least important thing.

Kevin Penner
In your javascript/packs folder, you can remove or comment out:
require("turbolinks").start()
in the relevant .js files.

Thanks, but in this case, it's not actually turbolinks.. it's some combination of the new magic hotwire/stimulus/etc that is doing what the "old turbolinks" did.
Not a full solution, but looks like removing the data-turbo-track parameters in the layout application.html.haml (.erb for many of you) eliminated some of the turbo/jquery conflict with some jquery widgets that I was seeing. Eventually I created a custom layout for those few pages that needed the jquery widgets:

# layouts/application.html.haml
...
    = javascript_pack_tag 'application', 'data-turbo-track': 'reload'
    = stylesheet_pack_tag 'application', media: 'all', 'data-turbo-track': 'reload'
    = stylesheet_link_tag 'application', media: 'all', 'data-turbo-track': 'reload'
...

I'd still like to find a true "on/off switch" to enable/eliminate all hotwire features/oddities.
John Quarto-vonTivadar
to anything you want to not use Turbo encompass it in a tag (typically a DIV, but could be a FORM or almost any other HTML tag), with `data-turbo="false"`.   Example
`<div data-turbo="false"> < a href="{url}">click me</a></div>`
should turn Turbo off for that div's descendent tags.   To turn it off for your site, put it in the `<html>` tag. 
(though I found plenty of the parts of JSP that use it to good effect, so I only turn it off for stuff I myself write, and then only to get it work "old-school", and once it does then I see if I can re-Turbo it.  But that's just because I think Turbo often feels like driving a Ferrari to pick up a gallon of milk. IMHO)
John Quarto-vonTivadar
as for Kevin's comment a bit earlier, nowadays just substitute the word "turbo" where it used to say "turbolinks".   turbolinks is a subset of turbo. Presumably you want it turned off not just when it's a link but also when it's a form etc.
also Happy to say I got a reply on Turbo github issue page, with link to the right doc page:

https://github.com/hotwired/turbo-rails/issues/182#issuecomment-859896460

John's note above how to disable per-link is also detailed in their docs here:
https://turbo.hotwire.dev/handbook/drive#disabling-turbo-drive-on-specific-links-or-forms

If you want to disable for the page, no matter how you navigate there, as I needed, the doc describes how to do that too.

TL;DR
Putting:
<meta name="turbo-visit-control" content="reload">

in the header will ensure a full page load for that page. So I conditionally include that for specific pages that need a full page load.

Their docs anticipated the exact same situation I ran into (using a 3rd party jquery* widget):

This setting may be useful as a workaround for third-party JavaScript libraries that don’t interact well with Turbo Drive page changes.

* I'm also including jquery via a script link to a cdn rather than webpacking it, in the absence of cogent docs on how to do it the "right" way. But it works fine that way.
John Quarto-vonTivadar
jquery is a wonderful thing but it's just not needed any more. I hate to say that because it means "oh lord, another skill to acquire" but the situation is what it is in 2021.   Probably the least offensive is to acquire Stimulus whilst in Rails world. As for the jquery widget, that solution works fine if the widget is on one page so you turn off Turbo and live with it, until there's time to "fix" it. But what if the widget is on , say , the top nav? Are you going to disable Turbo for the whole site? that's where it gets hairy. This has always been the Rails experience for me: when you fight the convention you pay an exponentially increasing price for maintenance and that exhausts me. I recently finished several days of trying to keep a jquery snippet in my sidebar that just would not work with Turbo in the picture (despite data-turbo="false") and at some point I realized "even though this code is already written if instead I'd spent the hours during the week simply working through the Stimulus docs, I've have acquired a skill I can use more generally, rather than trying to solve a single instance of "must use jquery!".

 Certainly looking forward to learning "stimulus/et al" someday when I have time for something optional, for example to implement cooler form editing with per-element dynamic editing in-page as asked about https://jumpstartrails.com/discussions/784

But 'not needed anymore' is perhaps premature (in 2021). The jquery widget in question is the doorway to an essential (for us) feature, in-browser enterprise-class video recording/player/management/cdn system (Ziggeo and/or Addpipe), developed by, I dunno, maybe 10-20 people-years of development. (So not something we'll be re-writing.) They use jQuery, so we use jQuery. So in this case "must use jquery" for that one page. Which fortunately was simple (and in fact was precisely the use case the Turbo docs cite for providing the was to ensure a full page load for specific pages).

Notifications
You’re not receiving notifications from this thread.
Subscribe
© 2021 GoRails, LLC