I got to hear some great presentations and have some great conversations at last week’s inaugural Backbone Conf, and one thing that came up over and over again was how to effectively communicate between views in client-side applications. There are lots of patterns for doing this – and we love talking patterns at Bocoup – so I thought I’d go over a few.
For the sake of this conversation, we’ll talk about my favorite demo app, Srchr. When a user enters a search term into Srchr, three things happen:
A naive, non-MV*, jQuery-based way to solve this might look like:
In an MV* land, we throw away this tightly coupled approach, and split our user interface into three distinct views:
Once we’ve split up our app into these three views, we need to reconnect them so that they interact with each other appropriately. The challenge is to do so in a way that doesn’t reintroduce the tight coupling we saw above. Below, we’ll go over a few of our options.
One option is to have views broadcast messages to the entire application when something interesting happens. For example, the search form could announce that a user had searched for something.
You’ll see this work in a couple of ways. In the Backbone Boilerplate, for example, there is an object named
app that is extended with the
Backbone.Events functionality. Views are given access to this object, and they trigger events on it; other views with access to the object can bind to events on it.
You can also use a pub/sub plugin to achieve the same effect.
So, for example, we might do the following in our search form view’s submit handler:
Then, anywhere else in our app, we could bind to the app object’s
search event, and react accordingly. Generally, we’d give all of our views access to this app object.
Pub/sub is very much a “fire-and-forget” approach – we have no idea whether anything in our application responded to the announcement of the search. This may seem undesirable, but it actually makes unit testing a view incredibly straightforward: we can simply test that a view announced what it should have announced when it should have announced it. It also makes a view’s functionality easy to mock when we’re testing other pieces of code – rather than needing to set up an actual view, we can just trigger an event on the app object.
There are a few potential downsides of pub/sub, however:
searchtopic for a different meaning, your application is likely to start misbehaving, so it’s up to you to make sure there’s no accidental overlap.
The shortcomings of a pub/sub approach lead us to a more refined, less global option: evented views. In this pattern, rather than sending messages through an effectively global bus, we trigger events directly on our views; only code that has a reference to a view has an opportunity “hear” the announcement.
In this pattern, we’d start by setting up our views in our route code (or similar):
Then we’d do the following in our search form view’s submit handler:
This approach lets us ensure that only code that has a reference to our search form can react to its announcements; it also essentially eliminates the namespacing issues of the pub/sub approach. Finally, our bindings to view events will get torn down when the view itself is destroyed.
How well this approach fits into your application will depend on your app’s overall structure and architecture – for example, if you aren’t setting up views in a consistent way, you’ll definitely find this difficult. You also run the risk of tying yourself in knots trying to make your views available in all the places you need them – if you find yourself doing that, it’s probably time to pause and consider a different approach.
A third approach is to use one or more models to transmit messages between views by leveraging the events that are triggered when we
set a property on a model. In this pattern, we’d give our views access to an application model, in addition to giving them the models they’ll need to display the appropriate data.
Our search form’s submit handler might then look like this:
Our search results view would be listening for the application model to change:
You might also implement this approach with multiple models for representing different pieces of application state; for example, a User model for keeping track of user information, and a UI model for keeping track of UI state (such as whether a panel is open or closed). Sometimes these models will have a direct relationship to your server-side models, but more frequently, they’ll be used only for managing client-side state, and won’t have a server-side representation.
If we choose this path, we still have our unbinding problem – realistically, this is easily dealt with by adding some convenience methods to our view to help us with smarter binding (and I hear that this may become easier in a future version of Backbone) – but overall, this might be the most MV*-ish way of dealing with relationships between views.
How is this different from a pub/sub approach? In some ways, pub/sub is just a more generic version of the event system used by models, and our application model(s) are ultimately just another method of getting a message from one place to another. Unlike a simple pub/sub pass-through, however, a model can make decisions about when and whether to announce changes. For example, in Ember, related changes are batched and announced all at once, rather than one at a time, and a similar system can be implemented in other MV* frameworks as well. It’s also possible to instruct a model not to announce a change. These are all beneficial features, but they make models a bit less straghtforward to work with than pub/sub.
I find that I’m still partial to the second approach – evented views that localize the announcement of interesting view-related occurrences, without having a strong opinion about what those occurrences mean. The pub/sub approach is a bit too global for me in most cases, and while the application model approach is appropriate in many cases, it’s good not to fall into the habit of using models just because you feel like “MV*” says that’s what you’re supposed to do.
In all likelihood, though, your application will use some combination of these methods: perhaps pub/sub for occurrences of truly global interest, evented views for transferring messages within a page, and an application model for information that is meaningful across multiple “pages” of a single-page application.
There is one thing that I feel strongly that you should almost always avoid: views with direct knowledge of other views, unless those views have a clear parent-child relationship. When you tightly couple views, you effectively require that one cannot exist without the other. This increases your testing burden, and decreases reusability. In a parent-child situation, this might make sense, but in other cases, the downsides are abundant.
Finally, I think it remains to be seen whether a library can effectively generalize this portion of client-side app development. Making generalizations about models, routers, and even views is clearly possible, but good decisions about this portion of app development still involves some context-specific decision making, and I think we’re still a ways away from a consensus on the best approach. How are you solving communication between views?