We Keep Coding

Reloading ajax retrieved data after page refresh

So, I have a page that has several links with onClick events that will retrieve data from external files and fill a div with this data. This works as intended. When I refresh the page, however, the div empties again. What I would like to happen is that after a refresh, the div will maintain the last content retrieved.
I'd prefer not to go down the road of cookies and have looked into adding data to the URL which I think is the way I want to go with this.
Is there some nice JQuery calls that can append data to url when a link is clicked and then on refresh restore the required content to the div?
My loadContent function is:
function loadContent (url, container) {
var target = $(container);
target.load(url, function (text, statusText) {
if (statusText === "success") {
target.find("a[rel^='gridnav']").initgn();
}
});
}
edit: I forgot to mention, the line
target.find("a[rel^='gridnav']").initgn();
is used to re-initialise a script on the new content loaded.
So when I click a link, the onClick event calls the function like this
TEST</li>
where xyz.html contains only the data I want inside the div "#right"
Is there a way to edit this function to do what I want ?

You can append data to the url by using
window.location.hash
https://developer.mozilla.org/en-US/docs/DOM/window.location
If you search for QueryString in jQuery plugins, there should be dozens of plugins that simplify this task.

I'd use localStorage. It's like cookies but much, much easier to maintain. The only downside is that it's not supported by all legacy browsers (See http://caniuse.com/#search=localStorage for browser support). For an orview on thhe feature, see https://developer.mozilla.org/en-US/docs/DOM/Storage If you want to go with completely no cookie like features at all; well then it has to be done server side to the best of my knowledge

Without cookies, your task will be a little bit harder. But I may have two solution for you:
Using session on server, you can control which ajax has been call, so next time when the main page is loaded, you can append the new content to it.
Using url hash to append ajax anchor has been click #anchorname so you can click it a gain after reload.

The comment tells you how you can modify the url without a page load. You could use that. If you have to work with older browsers, then you can still use the fragment (or do both things).
There are some history plugins for jQuery/JavaScript that manage this .. it's a technique called "deep linking." You may be able to find something simple to work with. Basically when loadContent runs you would want to update the url from /whatever to /whatever#right with the fragment indicating the load-content ID or something like that.
Another alternative would be to set some flag on the server that loads into that div when the page loads initially, which would save you an ajax request too. Depending on how your server code is set up that may not work for you, though.

Can I load new content using AJAX, but change the URL in the omnibar?

I don't want to use hashbangs, or shebangs, as they are known. I want to do it the way Facebook does. You click on Profile, the bar remains unchanged and the content is loaded using AJAX. I was wondering if the new HTML5 History API could be used.
EDIT: I think I'm going to go ahead and dive into HTML5's history API. Keeping the question open in case anyone has better suggestions.

The HTML 5 history API is the right way to go.
see here: https://www.new-bamboo.co.uk/blog/2011/02/03/degradable-javascript-applications-using-html5-pushstate/
The pushState and replaceState methods will allow you to change the URL without making an HTTP request. The difference being that pushState pushes a new state on to the history stack, while replaceState replaces the item at the top of the stack.

Also take a look at jquery-pjax

You don't need to do that. You can just prevent the default action from occuring. For instance, with jQuery we have;
function(event) {
event.preventDefault();
// this is different from event.stopPropogation()
// do some stuff
}
this will prevent the link's default action (following the url) from occurring.
P.S. I've always heard shebang refers specifically to this: #!, and not just #, but I could be misinformed...

Is there an event like hashchange for query strings?

I have been using hashes to pass data between pages (like setting scrollTop(), etc.) and have also used the hashChange event to trigger changes on a given page.
However, hashes have default behaviors that I'm not necessarily interested in, like making the page jump to a given (sometimes insignificant) spot.
I feel like getting/setting a query string would be more logical, but:
Is it?
Is there an event I can listen for when the query string is set?
Are there query-string-related behaviors I should know about?

It depends on what you're doing.
A query string change will always trigger a page reload. The only part of the URL you can change without a page reload is the #-part.
In javascript applications, page loads are generally not okay. But it may be possible to use when having a traditional html page request/response model.
There's no event AFAIK though, since it will change page.

As the other answer says, changing the query string will cause a page reload. As far as the browser is concerned you'll then be on a completely new page.
There are events that will fire when you do this. The ’beforeunload` event will fire, however it won't be very useful as it also fires when the user clicks on a link or closes the window.
Effectively the event that will fire if you change the query string will be the load event on the new page that it loads.

It is illogical to reinvent anchor behaviour. It is better to not expose hash links to insignificant fragments (although modern browsers are doing scrollIntoView() for any element with id, there is a dedicated behaviour for <a name="xxx">). So, answer is yes here, page arguments should be passed via querystring.
Event is window.beforeunload, yes, page reload when javascript:void(location.search='some') has been set
There are no surprises, have a look
Also, on working with querystring: http://xkr.us/js/querystring

Hash doesn't work with back button; Need javascript to call function on url change

Hey everyone, this code is meant to read what comes after the hash in the url and display a specific div depending on that value. Right now it works fine, except for when you try changing the hash while you're already on the site (or if you hit the back button, which has the same effect: changes the hash, but the div isnt changed). The site is made so that it doesnt reload with every div change (the main content of the page), so I'm assuming the reason the div doesnt change when you hit the back button or type in a different value after the hash is because the page is already loaded, and the javascript code is only called once on page load. I need a way for it to be called whenever the url is changed. Here's the code:
function hash() {
var hash = window.location.hash.replace('#','');
InsertContent(hash);
}

I'm afraid it's not a bug, it's a feature. Opera for example stores the exact state of a page in memory. So if you hit the back button, that state will be restored exactly. It's like you've never change the page.
Changing the hash should work though, by calling InsertContent() right after you've changed the hash. Doesn't that work? Can you show us the code?

You need to poll the window.location.hash and see if it changes. Some browsers support onhashchange event.
Another discussion: On - window.location.hash - Change?

jQuery has a plugin called "address" to address this problem

Assigning to document.location.href without clobbering history

In testing document.location.href, I have observed that when the user initiates an action that results in javascript that assigns to document.location.href, the new URL is added to the history.
However, if the call is initiated by javascript that is result of, say, state change of an XMLHTTPRequest, the entry for the current page in the history is over-written. Have I characterized this correctly? Is there a way to get the page change to be reflected in the history in this latter case?

I was facing the same problem and found this workaround which worked for me
instead of
function onAjaxCallback(evt){
location.href=newLocation;
}
i wrapped the location.href call around a setTimeout. Seems to do the trick. My history's behaving fine now. Hope that helps
function onAjaxCallback(evt){
setTimeout(function(){
location.href=newLocation;
},0)
}

You could change the location without having the browser display a Back button like this:
window.location.replace(new_url);
However, the original address remains in the browser's history and may be accessed using something like CTRL+H
Reference:
https://developer.mozilla.org/en/DOM/window.location#replace
https://developer.mozilla.org/En/DOM/Window.history#Notes

study: window.location.replace() and window.location.assign()

URL can be manually added to history before redirecting the user.
if (window.history) {
history.pushState({}, window.location.href);
}
window.location.replace("/login/?next=" + window.location.pathname);

Read the original question more carefully. The question is not about content loaded by an XHR, but about content loaded by a script loaded by an XHR. I had the same problem and the setTimeout method seems to work well.

Alas, your question can't be answered, AJAX requests have nothing to do with browser history, and if you loaded some dynamic content with them, then the user clicked the browser back button, the previous page is loaded (this which was loaded with an ordinary GET or POST request), which corrupts the sequence you display content in.
Dmitri's answers means that you will maintain your own history for the dynamic content using the fragment part of the url (this after the # symbol), maybe you'll provide your own back and forward buttons, but still you're not protected from the effect of the browser back and forward buttons.
If only they had provided some kind of events to handle user clicks on these buttons with the ability to cancel.