History back bug in turbolinks to a page with hash - javascript

I'm having a little annoying problem with Turbolinks in rails, which I hope some of you can help me with.
I'm using jQuery-address to add hashes to my url in order to execute some javascript, when a specific hash value occurs.
The problem is that Turbolinks doesn't seem to work, if I click the back button (history back) and the history back refers to an URL with a hash. It simply doesn't change the page content. E.g. mypage.com/test2 and i go back to mypage.com/test1#1.
I want to make a js fix, so if I hit another page with a hash using history back, it should reload the page to refresh the content OR just force the content to refresh manually with Turbolinks.
Thanks in advance!

The best information I can give without code is that Turbolinks refreshes the <body> of the page
Delegation
Normal HTML rendering is to re-render the entire page, meaning your JS is able to re-bind to the different elements. The way JS works is to bind an event to a specific element. That element has to be on the page (document / DOM) itself in order for the JS to bind to it.
Turbolinks is notorious for preventing JS from binding events to elements. As Turbolinks keeps the same JS on the page, it prevents binding for the JS. Instead, you'll need to use the turbolinks event handlers to bind your events to the DOM, and delegate through turbolinks, like so:
var ready = function(){
//your code here
};
$(document).on("page:load ready", ready);

Related

Does "history.pushState" change web page content?

I'm a beginner, hope some help to understand these questions, thanks~
For web pages like youtube.com, it uses ajax + history:
does a "pushState" reload the page?
if I injected some java scripts into this web page, will DOM Element I injected be removed or replaced? when will this happen?
if this happens, how to re-inject DOM element to make it displayed, or how to prevent the DOM element from being removed...?
does a "pushState" reload the page
No. It changes the URL and stores some data (which you pass to it as an argument) in the history. It doesn't change the page at all.
You are expected to use pushState when you write other code that changes the state of the page. (And you should change the state of the page so it is the same as if you freshly loaded the page at the URL you passed to pushState).
Then you are expected to change the state of the page back to host it was before (using the stored data) when you get a popState event.

JavaScript Historic back/forward

I'm building a little CoffeeScript application with 10 buttons and a container (simple). When the user press on one of the button : the container change.
The buttons look like a navbar and instead of using links (that will reload the entire page), I used javascript (Coffeescript, jquery or whatever) to change the content of the page (with some Ajax query to load data).
The problem is that the back and forward button of the browser can't work with that solution... and I need to find a solution for that. Routing maybe ?
I really like the way Asana.com resolved this issue: actually the address change but the content seems not to be entirely reloaded.
What do you suggest ? Thanks for the help
Hashes. The simplest solution is to define an URL hash every time the user clicks on a button. For example:
location.href = "#" + button.id;
With that, you create a history entry, and the user can press back or forward in the browser.
But how can you check when this happens? There's the hashchange event:
window.onhashchange = function() {
var state = location.hash.substring(1); // chomps the initial #
...
};
Basing your code on the state variable, you can trigger your AJAX calls from there.
By the way, you can change your code altogether, using links instead of buttons with an hash as the href property, which does not reload the page, but creates an history entry and fires the hashchange event.
The hashchange event is supported by every modern browser (that support history.pushState too, a more flexible and powerful way to control your history) and IE8-9.

Page transition with backbone

i have followed the samples and currently using event aggregator router for my application in backbone.
so basically i might not use anchor element at all instead i have any element on click event triggering router event.
I still feel that i might be missing something what is the downside of this way of navigating versus directly putting in link via template compilation.
I can think of a couple benefits of using a normal anchor tag with a hash route over having a click event trigger a routing change:
It will make your site easier for search engines to index, thus improving SEO.
It will allow users the ability to easily right or cmd click and open your page in a new tab/window.

Does document reload every time DOM changes via Javascript?

I kind of have a newbie question. I've done some testing, but I didn't get anything solid, so does the whole document reload when DOM is updated?
No, the document is not reloaded when the DOM is updated.
You can test it using this example: http://jsfiddle.net/AATC6/
There is an alert in the load event for the page, and you can click on the link to add an element to the DOM, which does not cause the load event to be triggered.
No it does not. However there is an event for some browsers DOMSubtreeModified which can be used to track changes to the DOM.

history.back(); doesn't trigger $(document).ready();

I have a webpage that use $(document).ready() to build the interface. Then the user can go to a child page, and to go back to the original page he can press the browser's "previous" button or a "Return" button in the page which triggers a history.back();. Back on the original page, $(document).ready() is not triggered so the page is missing information.
Is there a way to trigger it automatically like if it was a "real load"?
edit
placing an alert in it, the alert is popped but stuff is missing in my interface like if some part of the ready event is missing. Investigating...
edit 2
hahahahaha in document.ready I click some checkbox which are supposed to be unchecked. When I "back" on this page, they are checked so they become unchecked because I reclick them.
Sorry, this is completely my bad :(
A quick solution to this problem, use "onpageshow" instead.
window.onpageshow = function(event) {
//do something
};
If the user uses the Back button to navigate and you require a full reload of the page, you can set the NO-CACHE policy of the page.
This way the browser is forced to reload the page from the server, even using the Back button.
1.) put scripts at the bottom of your page.
2.) execute plugins and whatnot in your last script tag(s).
3.) Do not use onDomReady implementations at all, it's redundant.
People are so accustomed to onload or ondomready, they overlook the fact that putting your scripts at the bottom of a page does virtually the same thing without the need to poll and see if your html is available.
Furthermore, it's also good practise as your scripts do not block html/css rendering either.
Not depending on onDomReady or onLoad implementations solves a lot of issues.
Very interesting question. You might need to re-trigger the event/function when the page gets focus, or something similar. you might also need to keep a flag variable to track whether an 'event re-triggering' is in order.

Categories

Resources