Hacker News new | past | comments | ask | show | jobs | submit login
Implementing microstates in Backbone.js (chrisawren.com)
9 points by ChrisWren on Dec 9, 2013 | hide | past | favorite | 3 comments

I've started using [1] state.js for state management with backbone. It has the wonderful ability to extend any owner object with a state machine, so you can turn models, views or whatever into fully functional FSMs.

I'm actually dying to get around to a project that requires server-side rendering again, because I think having this logic abstracted will make this stuff so much more straight-forward.

I'm already able to replay the entire navigational flow of the site entirely on the server, as part of the tests.

[1] http://statejs.org

That's really interesting! Could you post any examples of how you're using it?

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 | Lists | API | Security | Legal | Apply to YC | Contact