working with browser history

sneakyimp

I've written a demonstration application for a client that loads a single page and then, like facebook or gmail, loads various regions of the page using Javascript. There's no AJAX yet but that's the basic idea. Unsurprisingly, the client has asked that the back button in one's browser take one back through my application as opposed to unloading the page and going to the previous PHP/HTML page, thereby unloading my page entirely.

I understand that one can use history.js which is the self-described successor to jQuery History. Unfortunately, this page doesn't provide much introductory material to describe how the tool can be used. I've tried reading the test scripts but I haven't had much luck penetrating the concept yet. I've also googled for "history.js tutorial" and the top results are all asking the same question I am asking here. Can anyone help me get a grip on this? For instance, why would one want to use pushHistory versus replaceHistory? What are some use cases and standard techniques?

Alternatively, I have located what appears to be the original history plugin which also insufficiently documented.

Has anyone done this sort of Javascript before? I want to integrate this into my app before I start adding any more features.

sneakyimp

For starters, why this?

<script>
			(function(window,undefined){
			    // blah blah blah
			})(window);
</script>

Weedpacket

sneakyimp wrote:
For starters, why this?

From what I understand, "window" and "undefined" are not reserved words in JavaScript - they can be (re)defined to different values. What that construct does is it defines an anonymous function with two parameters (named "window" and "undefined") and then immediately calls it with one argument (the current value of "window") - the other remains ... undefined. So within the scope of the function (// blah blah blah) "window" and "undefined" have their intended meanings.

But as I said, that is how I understand (the justification for) it. In my opinion, a third party script that is in the habit of rebinding those identifiers is just too antisocial to go to any lengths to accommodate.

sneakyimp

I guess I was wondering why the anonymous function. I've seen this technique before and have seen it referred to as a closure which may be strictly true but doesn't really explain much to me. I seem to recall the reason for doing it is to effect some sort of namespace isolation via a Javascript kludge. I.e., to avoid name collisions. Javascript is so weird. The calling of a two-parameter function with only one argument (thereby overriding globally defined equivalents) is certainly a bit too much and doesn't bode well for the viability of the script which is why I'm posting.

I've been working with it though and want to believe it might actually work. It was in fact recommended by a page on the mozilla site.

At the moment, I am beginning to understand it, but cannot seem to determine which event to use in my application: statechange, anchorchange, hashchange, popstage, etc. I can't yet tell why some of them seem to fire twice and others don't fire when the page loads, etc.

traq

it does help with name collisions; i.e., helps keep the global namespace "clean." here's an example that helped me understand scope issues in javascript:

var numberCars = 3; // global
numberTrees = 15; // global
if (numberTrees > numberCars) {
	var numberRoads = 4; // global
} else {
	var numberLakes = 9; // global, but will be undefined since the else{} is never run
}
function simpleFunction() {
	var colorCar = 'blue'; // local
	colorTree = 'green'; // global, once this function is called
	if (colorCar != colorTree) {
		var colorRoad = 'grey'; // local anywhere in this function after this line
	} else {
		var colorLake = 'aqua'; // local, but will be undefined since the else{} is never run
	}
}

some interesting distinctions. it's very much the opposite of how PHP handles local/global scope.

Weedpacket

sneakyimp wrote:
I guess I was wondering why the anonymous function.

Oh, that would be for scoping purposes: all vars declared within the anonymous function are local to the function; the alternative being to clutter your global namespace with all sorts of dross (variables and functions alike).

The bonus of using an anonymous function for the job is that it doesn't have a name - by definition - so won't touch the namespace; and as soon as it has completed executing it is inaccessible. So not only do its locals get garbage collected, but the function itself is a candidate for removal. All that would remain afterwards are things like event handlers that have been bound to things outside the function.

Libraries will need to leave something behind, of course - the library's functionality. The practice is to declare a single object to contain the entire library, make it a global property, and put the public interface in there.

Incidentally, in JavaScript, the global environment is itself an object - namely, "window": hence the "identifier protection" trick.

I think JavaScript - although it has been cursed with an evilly misleading syntax (among other issues) - is actually quite a clever language. As an OO language, "prototypical" inheritance model is arguably superior to other languages' "classical" inheritance in that it's relatively easy to implement the latter in the former (witness how pretty much every JavaScript framework does just that), but somewhat harder to do the opposite. A shame really, because the latter's dominance is one of the things that makes JavaScript look "weird".

And that's even before recognising it as a functional language (meaning functions are first-class citizens), and that "methods" are actually variables that just happen to contain functions ([font=monospace]foo.bar()[/font] is interpreted as "get the object in [font=monospace]foo.bar[/font] and - assuming said object is a function - call it".)