Hacker News new | past | comments | ask | show | jobs | submit login

TFA is arguing to use the router for navigation without having it push a separate URL to the bar, and still have back/forward work correctly. Essentially, creating a route change that isn't a route change, so it can properly trigger a router action. Of course, this is the actual point of `stateObject` as far as I understand it.

I think this is a good idea and would make a nice simple Backbone plugin. I've run into similar issues before; sometimes you want to display a temporary menu or other interstitial without a refresh taking you back to it.

Some purists get annoyed by this sort of thinking; they think that the URL bar should always reflect the current state of the app. I disagree with that line of thinking; different apps have different requirements and one size definitely does not fit all.

I've been writing Backbone applications for a while and I constantly run into router limitations that require creative solutions to get around. Backbone.routefilter is a great way to get some more flexibility - in every project I usually use a home-rolled combination of routefilter and a few more injected events. One of my favorites is to add permissions checking at the router definition level, to provide routes that only specific users should be able to use.

I've also been floating the idea around in my head of the url being essentially just a text representation of a state object - could easily just be a query string or something similar. Instead of a router globbing the url, you could attach event listeners to events on specific properties (similar to model/collection events), giving you all the power that most server-side routers have. For example:

    var MyRouter = Backbone.ExtendedRouter.extend({
      routeEvents: {
        'var1' : {'change' : onChange},
        'var2' : {'change add remove' : onVar2Event},
        '' : {'all': onRoute}
      // ...
And so on.

It would then be great to use the above microstates idea to create a navigation api like the following:

    App.Router.setState(publicState, privateState, triggerOptions)  
    App.Router.replaceState(publicState, privateState, triggerOptions)  
    App.Router.addState(publicState, privateState, triggerOptions)  
That way, we can trigger routes exactly when we want them (with or without an actual url change), store private state using the History API, and support microstates. The best part (IMO) is that different routers can listen to separate parts of the url, allowing a URL change to trigger multiple routes on completely separate routers. This would go a long way toward true separation of concerns in larger apps.

Of course a lot more needs to be fleshed out. If any BB devs are interested in helping with idea, please let me know (email in profile)!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact