One of the principle design philosophies I have advocated over the years, especially through various articles on this site, has been the importance of decoupling. And while I could go into significant detail to elaborate on the importance of decoupling, suffice it to say that all designs – from simple APIs to complex applications – can benefit considerably from a decoupled design; namely, with respect to testability, maintainability and reuse.
Decoupling in Backbone
Many of the examples which can be found around the web on Backbone are intentionally simple in that they focus on higher level concepts without diverging into specific implementation or design details. Of course, this makes sense in the context of basic examples and is certainly the right approach to take when explaining or learning something new. Once you get into real-world applications, though, one of the first things you’ll likely want to improve on is how modules communicate with each other; specifically, how modules can communicate without directly referencing one another.
As I have mentioned previously, Backbone is an extremely flexible framework, so there are many approaches one could take to facilitate the decoupling of modules in Backbone; the most common of which, and my preferred approach, is decoupling by way of events.
Basic Decoupling with Events
The simplest way to facilitate communication between discreet modules in Backbone is to have each module reference a shared event broker (a pub /sub implementation). Modules can register themselves to listen for events of interest with the broker, and modules can also communicate with other modules via events as needed. Implementing such an API in Backbone is amazingly simple, in fact, so much so that the documentation provides an example in the following one liner:
1 2 3 | var dispatcher = _.clone( Backbone.Events ); |
Essentially, the dispatcher simply clones (or alternately, extends) the Backbone.Events object. Different modules can reference the same dispatcher to publish and subscribe to events of interest. For example, consider the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | // A basic shared event broker var broker = _.clone(Backbone.Events); var Users = Backbone.Collection.extend({ // reference the broker, subscribe to an event initialize: function(broker) { this.broker = broker; this.broker.on('users:add', this.add, this); }, add: function(user) { console.log(user.id); } }); var UserEditor = Backbone.View.extend({ el: '#editor', // reference the broker initialize: function(broker) { this.broker = broker; this.$userId = this.$('#userId'); }, add: function() { // publish an event var user = new User({ id: this.$userId().val() }); this.broker.trigger('users:add', user); } }); // ... |
In the above example, the Users Collection is completely decoupled from the UserEditor View, and vice-versa. Moreover, any module can subscribe to the 'users:add' event without having any knowledge of the module from which the event was published. Such a design is extremely flexible and can be leveraged to support any number of events and use-cases. The above example is rather simple; however, it demonstrates just how easy it is to decouple modules in Backbone with a shared EventBroker.
Namespacing Events
As can be seen in the previous example, the add event is prefixed with a users string followed by a colon. This is a common pattern used to namespace an event in order to ensure events with the same name which are used in different contexts do not conflict with one another. As a best practice, even if an application initially only has a few events, the events should be namespaced accordingly. Doing so will help to ensure that as an application grows in scope, adding additional events will not result in unintended behaviors.
A General Purpose EventBroker API
To help facilitate the decoupling of modules via namespaced events, I implemented a general purpose EventBroker which builds on the default implementation of the Backbone Events API, adding additional support for creating namespace specific EventBrokers and registering multiple events of interest for a given context.
Basic Usage
The EventBroker can be used directly to publish and subscribe to events of interest:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | var Users = Backbone.Collection.extend({ broker: Backbone.EventBroker, initialize: function() { this.broker.on('users:add', this.add, this); }, add: function(user) { console.log(user.id); } }); var UserEditor = Backbone.View.extend({ el: '#editor', broker: Backbone.EventBroker, initialize: function(broker) { this.$userId = this.$('#userId'); }, add: function() { // publish an event var user = new User({ id: this.$userId().val() }); this.broker.trigger('users:add', user); } }); // ... |
Creating namespaced EventBrokers
The EventBroker API can be used to create and retrieve any number of specific namespaced EventBrokers. A namespaced EventBroker ensures that all events are published and subscribed against a specific namespace.
Namespaced EventBrokers are retrieved via Backbone.EventBroker.get(namespace). If an EventBroker has not been created for the given namespace, it will be created and returned. All subsequent retrievals will return the same EventBroker instance for the specified namespace; i.e. only one unique EventBroker is created per namespace.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | var Users = Backbone.Collection.extend({ // use the 'users' broker userBroker: Backbone.EventBroker.get('users'), initialize: function(broker) { this.userBroker.on('add', this.add, this); }, add: function(user) { console.log(user.id); } }); var UserEditor = Backbone.View.extend({ el: '#editor', // use the 'users' broker usersBroker: Backbone.EventBroker.get('users'), // also use the 'roles' broker rolesBroker: Backbone.EventBroker.get('roles'), initialize: function(broker) { this.$userId = this.$('#userId'); }, add: function() { // publish an event var user = new User({ id: this.$userId().val() }); this.usersBroker.trigger('add', user); } }); |
Since namespaced EventBrokers ensure events are only piped thru the EventBroker of the given namespace, it is not necessary to prefix event names with the specific namespace to which they belong. While this can simplify implementation code, you can still prefix event names to aid in readability if desired.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 | var Users = Backbone.Collection.extend({ // use the 'users' broker userBroker: Backbone.EventBroker.get('users'), initialize: function(broker) { // prefix the namespace if desired this.userBroker.on('users:add', this.add, this); }, add: function(user) { console.log(user.id); } }); var UserEditor = Backbone.View.extend({ el: '#editor', // use the 'users' broker usersBroker: Backbone.EventBroker.get('users'), // also use the unique 'roles' broker rolesBroker: Backbone.EventBroker.get('roles'), initialize: function(broker) { this.$userId = this.$('#userId'); }, add: function() { // publish an event var user = new User({ id: this.$userId().val() }); // prefix the namespace if desired this.usersBroker.trigger('users:add', user); } }); |
Registering Interests
Modules can register events of interest with an EventBroker via the default on method or the register method. The register method allows for registering multiple event/callback mappings for a given context in a manner similar to that of the events hash in a Backbone.View.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | // Register event/callbacks based on a hash and associated context var Users = Backbone.Collection.extend({ broker: Backbone.EventBroker, initialize: function() { this.broker.register({ 'user:select': 'select', 'user:deselect': 'deselect', 'user:edit': 'edit', 'user:update': 'update', 'user:remove': 'remove' }, this); }, select: function() {...}, deselect: function() {...}, edit: function() {...}, update: function() {...}, remove: function() {...} }); |
Alternately, Modules can simply define an “interests” property containing particular event/callback mappings of interests and register themselves with an EventBroker
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | // Register event/callbacks based on a hash and associated context var Users = Backbone.Collection.extend({ // defines events of interest and their corresponding callbacks interests: { 'user:select': 'select', 'user:deselect': 'deselect', 'user:edit': 'edit', 'user:update': 'update', 'user:remove': 'remove' }, initialize: function() { // register this object with the EventBroker Backbone.EventBroker.register(this); }, select: function() {...}, deselect: function() {...}, edit: function() {...}, update: function() {...}, remove: function() {...} }); |
For additional examples, see the backbone-eventbroker project on github.
I’m interested in utilizing the functionality of your EventBroker in my project, however I can’t figure out how to load it with requirejs. I tried including it as a dependency for backbone in the shim, but I got a timeout error. Can you please provide an example?
Basically, you would just need to do the inverse; that is, Backbone would be the dependency for Backbone.EventBroker. For example:
…
shim: {
‘Backbone’: {
deps: [‘underscore’, ‘jquery’],
exports: ‘Backbone’
},
‘EventBroker’: {
deps: [‘Backbone’],
exports: ‘Backbone.EventBroker’
}
}
…
I realized that made more sense after my post, and after some effort I realized I also need to pass in the script location as a dependency to each of my modules that use EventBroker. Initialize I didn’t think this was necessary because the EventBroker extends Backbone, but once I added it as a dependency (following the example of jquery plug-ins) everything started working as expected. Thank you for your quick reply!
No problem at all. The shim configs are really nice, but they require a different design in terms of how client code accesses plugins in that whereas one used to be able to just require Backbone, and from that access any Backbone Plugins (e.g. Backbone.EventBroker) just as they would for any native Backbone API (e.g. Backbone.Model), now plugins are accessed just as any other module. So essentially plugins are now required explicitly as modules.
This leads to a bit of refactoring needed when upgrading to RequireJS 2.+, however the benefits certainly out weigh the drawbacks.