Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

render_async issues with container_id and turbolinks : not reloading or JS not firing on new visit depending on configuration #136

Open
dbs-ced opened this issue Dec 2, 2020 · 5 comments
Open

render_async issues with container_id and turbolinks : not reloading or JS not firing on new visit depending on configuration #136

dbs-ced opened this issue Dec 2, 2020 · 5 comments

Comments

@dbs-ced
Copy link

dbs-ced commented Dec 2, 2020

Hi !

I'm trying to handle more than one render_async in a single page and my site works with Turbolinks.
My render_async renderer have a container_id set as "render_async_{id}" to refresh them using javascript.

Extract from my html file :
<%= render_async my_path(id), container_id: "render_async_#{id}", replace_container: false %>

In Javascript I do the following to refresh one given render_async :

let container = document.getElementById("render_async_<%= @id %>");
let asyncEvent = new Event('refresh');
container.dispatchEvent(asyncEvent);

When the page loads for the first time, everythings works fine, all my lists are loaded asynchronously and when I make an action changing one of the items of those lists, it is correctly refreshed.

But when I load the same page a second time without refreshing the page, just with navigation through turbolinks visits, all my lists are blank, no asynchronous action is launched.

I tried to remove the container_id from my render_async and the lists are correctly refreshed on turbolinks navigation, so I think the issue is related to container_id - not being properly used to refresh render_async blocks ?

Here is my config file :

RenderAsync.configure do |config|
config.jquery = true
config.turbolinks = true
end

I'm using turbolinks 5.2 and render_async 2.1.8.
Did you already encoutered this issue, and/or did I miss something ?
Thanks in advance !
@kofronpi
Copy link

kofronpi commented Dec 8, 2020

Also encountering this bug @nikolalsvk

@nikolalsvk
Copy link
Owner

Hey, @dbs-ced and @kofronpi. Thanks for submitting and commenting on the issue. I will look more into this and try to fix it ASAP for y'all. We recently got another issue related to Turbolinks like this one #135

What would really help is if you could provide an example where I could reproduce this. I have a Rails 6 + Turbolinks project I use to test stuff here https://github.com/nikolalsvk/rails-6-base-app/tree/render-async. If you could help me reproduce the problem there, it would be easier and faster for me to come up with a fix.

Thanks a lot

@nikolalsvk
Copy link
Owner

nikolalsvk commented Dec 12, 2020 •
edited
Loading

One question, @dbs-ced and @kofronpi - where did you put your <% content_for :render_async %>?

I am trying to debug this issue and this info would help me a lot.

EDIT:

I tested this out with <% content_for :render_async %> in the <head> and it doesn't work with container_id. When you remove the container_id option, the render_async code runs, but you can't really utilize the refresh functionality because container_id is randomized.

Reasons

The reason why render_async doesn't trigger with container_id is that Turbolinks will not reevaluate the render_async logic on the second visit. The reason why the logic gets reevaluated when there's NO container_id is that Turbolinks noticed that the new render_async logic (the script element in the head) is different than before because container_id is randomized (this took me a while to figure out).

Quick fix

Anyway, you can easily solve this by putting <% content_for :render_async %> in the <body>, instead of the <head>. That way you will ensure that render_async code gets evaluated every time the page is visited.

Future improvement and long-term fix

In the meantime, I will try to figure out if it's worth supporting <% content_for :render_async %> in the <head> and keep you posted.

@kofronpi
Copy link

@nikolalsvk thank you ! yes it is in <head> right now.

We will try this fix tomorrow.

@dbs-ced
Copy link
Author

dbs-ced commented Dec 14, 2020

Thank you @nikolalsvk ! The quick fix works fine !
Thanks a lot for you time, waiting for the long-term fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nikolalsvk @kofronpi @dbs-ced