I’ve continued my hacking with in-page client-side routing using the director.js library and am finding the exercise fairly interesting.
I’ve posted an updated demo snapshot here: http://www.chrisrussell.net/html5/re-director2/
re-director.js instantiates and controls an instance of a director.js router, and manages the single-page test app.
Upon initial load of the page document.location = “http://www.chrisrussell.net/html5/re-director2/” and there is no router instantiated or running in the context of the page.
re-director.js will prompt you via text messages / buttons in the “re-director console window” (gray DIV center page). Click through the buttons to boot up the router.
Watch carefully as you proceed through the states. On a default load of the page (i.e. there was no hash route specified in the request URL), the demo should internally redirect and execute the “boot” route callback.
Note the “current re-director.js statistics” table displayed below the current route. In the default page load / internal re-direct to the “boot” route, you’ll note that on re-director.js console step #19, the route callback for “boot” was called.
Once the director.js router is started, you can use the links at the top of the page to invoke routes from within the page. (always keep an eye on the re-director.js console window – it will sometimes be prompting you for action).
If you click on several links, you’ll see the page updating to tell you what’s going on. Mostly what we care about is ‘routes served’ out of re-director.js. The rest of the stats are effectively instrumentation to monitor director.js.
In the current build of re-director, I’m studying the ‘all routes callback’ stat with some suspicion: I’ve found several cases where it appears the registered callback is not invoked when I think it should be. It’s odd.
Next step will be to extend this example to carefully monitor and verify the behavior of all director.js callbacks.