

Implementing microstates in Backbone.js - ChrisWren
http://chrisawren.com/posts/Implementing-microstates-in-Backbone-js

======
AdrianRossouw
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](http://statejs.org)

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

------
ssafejava
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)!

