Jason Fb wrote in post #1150072:
What exactly (please paste code examples) by “comes to this view from
another view” ?
I’m in an HTML page, I click an anchor HTML element() which takes me
to another HTML page.
If the page is reloaded check to make sure your onload handler is
re-attached correctly (you can do this with simple debugging or console
statements inside of your onload function)
It’s not re-attaching. I’m thinking that turbolinks has something to
If you have some kind of ajax setup (like some of the default Rails
stuff), then parts of the page might be getting replaced with new HTML
content (Like your my_element). When that happens, the HTML is replaced
and the new html elements do not have the click handler attached to them
(and your onload is not re-run).
I don’t know how can I check if this is happening?
To keep things the way they are, try using jQuery 's on method
(http://api.jquery.com/on/), which you should attached to a parent of
the object that is getting replaced by ajax – not the actual link
Better yet, think about learning Backbone, Ember, or Angular. The way
down quickly in larger apps with a lot of client-side interactivity.
(big, global class-bsaed targets that attach click handlers during the
window’s onload) since about 2009.
If you are using turbolinks you have to re-attach all your click
handlers after the page content is replace, as discussed with detecting
the page change event.
I’ll take a look at how turbolinks work.
Like I said, in a small app you will get away with this but in a larger
app you will drown in a nightmare of page change event binding and
know stay away from this style of coding and prefer a more robust
think-client approach like the ones I mentioned. Obviously, detecting a
change event may just be a small fix and learning a whole new way to
write code is a bigger task.
Thanks for the advices Jason, very helpfull.