I’ve continued to work with director.js. The library has a well-design API and is just small enough that I dare debug it when it does odd things I don’t expect. Unfortunately, I’ve discovered quite a few behaviors that don’t really work as well out-of-the box as I had hoped.
In particular, today I’ve been pushing the tests into the land of route recursion and asynchronous processing of routes and ran into some problems. I got one bug fixed in a forked version of director.js that completely horks asynchronous routes but am currently blocked trying to determine the source of an unhandled exception that occurs when director.js dispatches the ‘notfound’ route on an unknown route AND asynchronous route processing is enabled.
The latest snapshot is online here: http://www.chrisrussell.net/html5/re-director3/
Why so much effort?
If you want to write a useful single page HTML5 application you have to assume that at some point or another your user is going to hit refresh in the browser, navigate forward or backwards, or copy the URL and paste it somewhere expecting that clicking it will do something rationale. All of these cases are 100% screwed without some sort of client-side routing solution.
Once I get this issue with async dispatch of route ‘notfound’ straightened out I think I’ll have enough to roll on to the next stage with.
There’s going to be a whole bunch of interesting detail pertaining to _how_ this router will be used.