Quantcast
Channel: Code Review - Eric Feminella
Viewing all articles
Browse latest Browse all 23

Decoupling Backbone Modules

$
0
0

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:

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:

// 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:

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.

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.

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.

// 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

// 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.


Viewing all articles
Browse latest Browse all 23

Trending Articles