Client side HTML5 History API support #72
Conversation
Added support for configure option html5history and related browser side implementation. With this option routing can use pretty URIs instead of the hash URIs. It's worth to notice that switching the method most likely requires changes also to backend since the browser will, upon initial page load, ask for the URI it is loading instead of the service index (e.g. yourhost.com/users/1). There is a bug in Chrome which causes it to trigger onpopstate event when performing initial page load. Since the event handler must be called upon init manually to ensure correct content, the bug would cause two handler calls in Chrome. Now the handler is set in a setTimeout in order to avoid (most) double calls in Chrome. See Chrome bug for reference: http://code.google.com/p/chromium/issues/detail?id=63040
Also a lot of fuzz due to my editor stripping out extra whitespace.
At least IE9 returns undefined instead of null and thus history support would be incorrectly set to true if using strict comparison.
|
Thanks, will be reviewed soon. |
|
Cool. I'm no expert on pushState implementations, but @jashkenas was asking about this last week at NYC.js. Awesome how open source works like that :) |
|
Any update on whether or not this is making it into director? Currently using vesse's branch in the meantime. |
|
Do want. |
|
+1 |
In some cases, like when you get an URL from an IE user, page can be entered with a hash URL. This commit changes the functionality so that the hash is checked regardless of operation mode, and if in HTML5 history mode the current history state is replaced and handler is called with a nice, clean URI.
Conflicts: README.md
|
@hij1nx Decision please. |
|
I'm on the fence about taking this commit without any tests. although i really want these features. Is there any way you can add a simple harness with a director backend? |
|
@hij1nx If your question was meant for me, sure. My original intention was of course to add tests as well but then I got busy, and also didn't know what would be the preferred way from this project's point of view - i.e. would a simple, manually launched node server and manually opening the browser test page suffice. If it does I'll try to find some time to implement the tests. |
…used when creating onpopstate method
By default when in html5history mode the route handler is executed in Router.init() because of need for routing cannot be determined (like it easily can when using hashes). Usually this is the wanted behavior, but since that is not always the case this option makes it possible to disable execution.
|
OK, finally got time to implement the dummy backend and tests. There is now file director/test/browser/backend/backend.js that needs to be started in that folder. After that going to http://localhost:8080/ executes the tests that are basically the same as the hash routing tests. I needed to modify helpers/api.js (didn't want to add options to every call plus a timeout is needed due to that Chrome bug mentioned in the actual browser.js) a bit but the old tests should work. When implementing the tests I also added yet another configuration option run_handler_in_init (sorry for the lame name, didn't come up with anything better) which works only if combined with html5mode. If that option is set to false then the route handler is not executed in Router.init(), but by default it is because of not being able to determine if init should route or not. |
…ng enabled since the outcome depends on the uri where the browser is when test starts
Added hash routing fallback to the route handlers to enable testing with IE. Not all tests pass, but that is the case with test-harness.html as well so supposedly this is not because of html5 mode.
|
+1 |
Conflicts: README.md lib/director/browser.js test/browser/routes-harness.html
Async testing and setTimeouts needed for Chrome bug made the test highly unreliable. It failed randomly depending on if the route could be changed to '/a' before executing the test.
|
Is there any reasons for this not being merged to director? If there is something which needs to be done I'll be happy to help as this feature is pretty nice and Vesse's implementation is working flawlessly! |
|
@framp Will review and finish this by tomorrow. |
[lib] Client side HTML5 History API support
Enable using HTML5 History API and the clean URLs it brings instead of the hash fragment URIs on browsers that support it. In practice a new configure option
html5historywas added and the required changes implemented tobrowser.js.These changes have been manually tested with:
No tests were added due to not being able to test with just a HTML page and QUnit. Implementing tests would require adding a server implementation that serves the test page and related JS components.
Documentation is updated as well. Unfortunately the diff contains a lot of irrelevant changes as my editor stripped trailing whitespaces.
#20