blazer view rendering issue with turbolinks_render

Hi There!

I've been looking to integrate Ahoy with Blazer in my app and I stumbled upon this issue. I ultimately traced the root cause to the turbolinks_render gem which is included by Jumpstart. I'm wondering how this library is used within jumpstart and what functionality may break if I remove or disable the library. I'm also open to other workarounds that allow blazer and turbolinks_render to co-exist with rendering issues.

Thanks!
Kyle

Sounds like you probably want to link to Blazer with data-turbolinks="false"

https://github.com/turbolinks/turbolinks#disabling-turbolinks-on-specific-links

That fix your issue?

I'll have to research to see if the turbolinks_render gem respects that data attribute as noted in the turbolinks readme. They appear to be two separate projects so unsure. If that works it seems like I'll have to propose an update to the blazer gem since its mounted within my jumpstart app and rendering its own internal html views.

Would you agree there doesn't appear to be another option (outside of removing turbolinks_render from the Gemfile)?

That data attribute is handled by Turbolinks, not turbolinks_render. You don't want to run Blazer under Turbolinks at all, so adding the attribute to the link should do it. 

We use the exact same thing for Sidekiq and Administrate links in the navbar. Neither one of their UIs are designed for Turbolinks, so we use that attribute so it doesn't interfere.

Tried adding the data-turbolinks="false"  to the Blazer link I added to _navigation.html.erb but no such luck in solving the issue. I searched around for the Sidekiq and Administrate examples you mentioned but I don't see data-turbolinks attributes on those links in the jumpstart code. 

Forgot to mention that I even tried adding this data attribute to the body tag of layout/view rendered by Blazer and it didn't work. The only thing I've found that corrects the issue so far is removing turbolinks_render from the Gemfile.  

I ended up forking the blazer gem and adding an initializer that defaults turbolinks_render to false, which appears to have fixed the issue.

Probably should open a ticket with the turbolinks_render gem and ask him how he'd approach solving that.

When Railsconf happens and they release the new Turbolinks stuff, we will probably no longer need that gem, but that'll be a couple months.

Thanks Kyle ! I was running into the same issue and your fork worked out great!