Question

I have a web application with require.js, backbone.js and jquery.
The brief structure of the app is as follows:

• There are 2 sections on the screen (toolbar and main content below).

• There are multiple components (address management, event management), each triggered by a hash fragment change and require a
  page transition.

• There is one backbone.js router. It’s the heart of the application. The router is activated with a new hash fragment (manually entered,
  back button, menu item selection).

Up until now, in the router, I made the page transition, I DIRECTLY called the controller (“view” in backbone) of the selected component.

So there’s a CENTRAL handling of controller calling.

But this has to change now to a DISTRIBUTED handling. I now need to respond to a new hash fragment from two different places: From the toolbar component and from router.
So my idea is to exchange the direct controller calling mechanism with pub sub. Now MULTIPLE components could register for a special action and the router just “fires the event”.

I searched around and found Chaplin (https://github.com/moviepilot/chaplin), a backbone.js example application.

The developers of Chaplin seem to have a similiar thing called “ApplicationView” (https://github.com/moviepilot/chaplin#toc-router-and-route):

“Between the router and the controllers, there’s the ApplicationView as
a dispatcher.”

Is there anyone who has already this kind of architecture and can tell me his experience with this or has anybody solved this in another way?

Answer 1

I’ve used a similar, though maybe less complex, architecture in this project. I give a pretty good explanation in this answer to a related question. The quick overview:

• I manage app-wide events that change the application state using a singleton State model that works similarly to Chaplin’s pub/sub architecture. This is just a basic Backbone model, with some added methods to deal with serializing and deserializing attributes as strings, so they can be set in the URL.

• Application components that change the application state in response to user interaction or other input do so by setting properties on app.state.

• Components that need to update when the application state changes do so by binding to change events on app.state (it looks like this is exactly the way Chaplin’s mediator works, though they renamed the methods to fit the pub/sub paradigm).

• I treat my routers like specialized views that update the address bar and respond to user input in that area. Changing the address (manually or by clicking on a link) causes the router to set() the necessary changes on the app.state model, and everything else updates accordingly.

I hope that’s helpful – I think it’s a little simpler than the Chaplin approach.