I spent the morning pulling my hair out trying to get my routing working after downloading the latest version (2.3.7) in order to use the ($event) event binding. For the life of me I could not get the following route hit:
Vision.Controls.Dashboard = can.Control.extend({
"route": function() {
// this would hit (depending on below explanation)
window.location.hash = '#!dashboard';
},
"dashboard route": function () {
// this would just never get hit
}
});
I had a template defined as follows:
can.route(':page');
Turns out that that doesn’t get the job done but his does (notice the trailing /):
can.route(':page/');
In addition to that I had included the can.route.pushstate
plug-in and that seems to break the routing and I don’t know if that is the intended behaviour. You can simply add the pushstate plug-in to this jsfiddle to “break” it.
It is quite confusing and frustrating trying to sort out things that appear quite simple
If I am doing something wrong or missing something please let me know.
Control based routing should be avoided. I’m working on cleaning up references to it right now. Where are you learning this technique?
Routing should be based around state. The reasons are talked about here: http://stackoverflow.com/questions/25776037/routing-conventions-in-can-js/25776652#25776652
As far as actually mapping that state to custom elements, the best way of doing that is like this:
Here’s some more info on it: http://canjs.com/guides/Tutorial.html#routing
The pushstate
plugin is for using pushstate APIs like here: https://developer.mozilla.org/en-US/docs/Web/API/History_API
If you want simple hash-based routing, do not include that plugin.
Oh, read this recent article for a good start : http://blog.bitovi.com/routing-in-canjs/
It shows pushstate, but applies to hashchange based routing.
Thanks for all the links Justin. I’ll have a look.
To answer your question about where I saw the technique: http://canjs.com/docs/can.Control.route.html
I refactor as I go along but after a quick look at one or two links I already have some other ideas. I just need some large scale permissions-based routing. So all components will not be in the same location, but a mapping of sorts with an associated required permission will do. Some routes may not need permissions at all and may not require the user to be logged in.
Thanks for the pointers. I’ll steer clear of the control-based routing then