Design Patterns - Eric Feminella

Decoupling Backbone Modules

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.

4 Comments

Persisting Backbone Collections

Backbone.js provides a light-weight, extensible API which focuses primarily on general structure, and the utility of that structure, without requiring a rigid adherence to specific patterns or prescribing certain design philosophies. This focused approach affords developers a significant level of flexibility which can prove to be essential to the success of many modern client side web applications – especially when considering the challenges surrounding the ever changing landscape of the web.

Naturally, it follows that such flexibility imparts additional responsibility on the developer. In my experience with architectural frameworks in general, and Backbone in particular, many times this kind of trade off can be quite preferable.

Extending Backbone

As mentioned above, Backbone implements the essential building blocks necessary to provide general structure within an application. If a feature is needed which is not provided by default, by design, Backbone allows for easily extending the core APIs in order to implement additional features as needed. In fact, developers are encouraged to do so.

Perhaps a good example of this can be found in the need to persist collections in Backbone; that is, interestingly, while the Backbone Model API implements a default save method, the Backbone Collection does not provide a similar API for explicitly saving the models within a collection; that is, saving the collection itself. This feature may have been left out intentionally as part of an initial design decision, as there are some complexities to saving an entire collection as a general use-case; such as saving deltas, propagating saved state to models within the collection and so forth; or, perhaps it simply may have been an oversite. Regardless of the reason, in certain scenarios it can be useful to save an entire collection rather than saving each model individually – fortunately, given the flexibility of Backbone, writing an extension to implement this feature is quite simple.

The PersistableCollection

As a basic solution for saving a Backbone Collection, I wrote a general abstraction – PersistableCollection, which extends Backbone.Collection, implementing a default save method.

The PersistableCollection API is quite simple in that it essentially just implements a proxy which wraps the collection in a Backbone Model, and ensures there is only one proxy created per collection. The url and toJSON methods, respectively, of the proxy Model reference the url and toJSON methods of the collection to which the proxy is bound. You can either extend PersistableCollection or generate a proxy for an existing collection via the static createProxy method. Examples of each follow.

Using a PersistableCollection

A PersistableCollection can be instantiated and used directly, just like a Backbone.Collection:

var users = new Backbone.PersistableCollection([

{name: 'Jane', id: 25},

{name: 'Joe', id: 26}

], {

url: '/users';

);

users.save(); // saves the collection ...

Extending PersistableCollection

You can extend PersistableCollection and simply invoke save to persist the models in the collection:

var Users = Backbone.PersistableCollection.extend({

url: '/users',

model: User

});

var users = new Users([[

{name: 'Jane', id: 25},

{name: 'Joe', id: 26}

]);

users.save(); // saves the collection ..

Creating a proxy for an existing collection

An existing collection can be saved by creating a proxy for it:

var users = new UsersCollection([

{name: 'Jane', id: 25},

{name: 'Joe', id: 26}

]);

users.url = '/users';

var proxy = PersistableCollection.createProxy(users);

proxy.save(); // saves the collection ...

The PersistableCollection can be used as a general extension for saving entire collections based on the representation of all models within the collection. If you are interested in extending it to account for more specific use-cases, you can simply override the default save implementation as needed.

You can find the gist for the source and spec here.

April 10, 2012 APIs / Design Patterns / JavaScript / Object Oriented Design

1 Comment

IIFE (Immediately-invoked Function Expressions)

When developing Mobile Web Applications, even the seemingly marginal micro-optimizations can result in a noticeable performance improvement over time and, therefore should be implemented where possible. One could also argue (and rightly so) that this same principle applies when developing Web Applications on the Desktop; however, in the context of Mobile Web Experiences, such optimizations are essential, perhaps even obligatory on the developers part.

In a previous post from a few months back I discussed some of the benefits of function overwriting in JavaScript. One similar performance optimization I regularly employee is that of One-time function initializations.

Conceptually, an IIFE/em> is a rather simple pattern which can be broadly described as follows:

An Immediate Function / Self-executing Function performs some initial test conditions.
The Immediate Function returns an anonymous function which, in turn, returns the results of the test conditions. Alternately, the Immediate Function can just return the test condition results.
The anonymous function returned is assigned to a function expression or, the test condition results are assigned directly.

An example in code illustrates just how simple this pattern is:

var hasSomeFeature = (function() {

// implement test logic... for example, testing

// a feature's existence in the browser against

// multiple vendor prefixes, etc.

// return a function which returns the results, or

// just return the result value if desired...

return function() {

// return results...

};

}());

Practical implementation example:

var hasWebSockets = (function(window) {

var prefixes = 'ms O Moz Webkit'.split(' '),

n = prefixes.length,

i = 0;

for (; i < n; ++i) {

if (window[prefixes[i] + 'WebSocket']) {

return true;

}

return 'WebSocket' in window;

}(this));

Implementing Immediately-invoked Function Expressions are quite useful in many situations. Specifically, they are of most value when implemented for use-cases where conditions are too complex to assign to a variable directly and, when the conditions tested only need to be evaluated once, after which re-evaluating the condition would be redundant and unnecessary – such as certain feature detections.

As a general rule of thumb, if a condition or set of conditions can be tested once; that is, they are guaranteed to not change during the execution of the application and, the tests are too complex to maintain if directly assign to a variable, then implementing One-time function initializations are a small, yet simple and practical optimization.

February 4, 2012 Design Patterns / JavaScript / Refactoring / Software Engineering

Comments Off on IIFE (Immediately-invoked Function Expressions)

AT&T Best Practices Guide for App Development

When considering the various best practices surrounding the design of Mobile Web Experiences and Architectures, such works as the W3C’s Mobile Web Application Best Practices guide, or the excellent Mobile Web Best Practices site, and of course, the seminal text, Mobile First, are likely to come to mind. The concepts and strategies presented in these works are a staple in the design of many modern Mobile Web Experiences and are without question an invaluable resource. In addition to these and other similarly related works, another new and valuable resource has been made available from a very important player in the Mobile Space indeed – an actual Wireless Carrier, AT&T.

Recently, I was contacted by a representative of the AT&T Developer Program informing me of the research conducted by the AT&T Research Labs and, the subsequent resources made available by AT&T as a result of their findings. Since I was unaware of this work, I was very interesting in learning more and, after reading the introductory statements, I was quite eager to apply AT&T’s recommendations as well; to quote specifically:

We quickly saw that a few, simple design approaches could significantly improve application responsiveness.

Having read through the material in it’s entirety (provided below) I must say I am rather impressed. The information provided has very real and practical implications on the design of Mobile Web Applications. Specifically, I found the clear and concise explanation of the underlying implementation of the Radio Resource Control (RRC) protocol to be particularly relevant and useful. RRC is by far one of the most important design factors to consider in terms of battery life and Application responsiveness and, as the research suggests, this may not have been common knowledge.

By far, the most interesting and notable aspect of the AT&T Research Lab’s work in this area is the fact that all of the information provided is applicable in the context of all Wireless Carriers, not just AT&T. That is, the recommendations given, such as those regarding the RRC State Machine, for example, are all based on carrier-independent standards and protocols implemented by all Wireless Carriers. As such, understanding the implementation specifics and recommendations provided is certain to prove valuable for all users of your Application, regardless of their Carrier.

If you haven’t all ready, I highly recommend reading and applying the principles provided by AT&T’s research to your current and future Mobile Web Application Designs.

AT&T Research Labs: Mobile Application Resources

Build Efficient Apps
Profiling Resource Usage for Mobile Applications: A Cross-layer Approach

January 15, 2012 Browsers / Design Patterns / HTML5 / JavaScript / Software Engineering / UX Design

Comments Off on AT&T Best Practices Guide for App Development

External Templates in jQote2

The jQote2 API Reference provides plenty of useful examples which are sure to help users get up and running quickly. I found it a bit unclear, though, as to how templates could be loaded externally as, in the reference examples, templates are defined within the containing page. For the sake of simplicity this approach certainly makes sense in the context of examples. However, in practice, templates would ideally be loaded externally.

While jQote2 provides a perfect API for templating, it does not provide a method specifically for loading external templates; this is likely due to the fact that loading external templates could easily be accomplished natively in jQuery. However, since this is a rather common development use case, having such a facility available would be quite useful.

After reviewing the comments I came across a nice example from aefxx (the author of jQote2) which demonstrated a typical approach to loading external templates which was simular to what I had been implementing myself.

And so, I wrote a simple jQuery Plug-in which provides a tested, reusable solution for loading external templates. After having leveraged the Plugin on quite a few different projects, I decided to open source it as others may find it useful as well.

Using the Plugin

Using the jQote2 Template Loader plugin is rather straight forward. Simply include jQuery, jQote2 and the jquery.jqote2.loader-min.js script on your page.

As a basic example, assume a file named example.tpl exists, which contains the following template definition:

<![CDATA[

<% var article, i, n;

for ( i = 0, n = this.articles.length; i < n; i++ ) {

article = this.articles[i];

</header>

</article>

<% } %>

]]>

</script>

We can load the example.tpl template file described above via $.jqoteload as follows:

$.jqoteload('example.tpl', function(templates) {

// create some mock articles...

var articles = [{

text: 'Articles A test...'

}, {

text: 'Articles B test...'

}, {

text: 'Articles C test...'

}];

// Render the articles...

$('#articles').jqoteapp(templates.articles_tpl, {

'articles': articles

});

After example.tpl has been loaded, from another context we can access the compiled templates via their template element id. In this example "articles_tpl".

//... within some other context, access the same

// compiled template

var template = $.jqoteret( 'articles_tpl' );

You can grab the source and view the example over on the jQote2 Template Loader Github page.

December 12, 2011 APIs / Design Patterns / HTML5 / JavaScript

3 Comments

Function Overwriting in JavaScript

Whether intentional, or simply a by-product of it’s design, Javascript, being a dynamic language, allows for a level of expressiveness which most any seasoned programmer would come to appreciate. Javascript naturally provides the ability to implement some rather intriguing and quite unique patterns; one of which is the ability to overwrite a function at runtime.

Function Overwriting

Function Overwriting (also known as “Self-Defining Functions” or “Lazy Defining Functions”) provides a pattern which, as stated above, allows for overwriting a function’s definition at runtime. This can be accomplished from outside of the function, but also from within the function’s implementation itself.

For example, on occasion a function may need to perform some initial piece of work, after which, all subsequent invocations would result in unnecessarily re-executing the initialization code. Typically, this issue is addressed by storing initialization flags or refactoring the initialization code to another function. While such a design solves this problem, it does result in unnecessary code which will need to be maintained. In JavaScript, perhaps a different approach is in order: we can simply redefine the function after the initialization work has been completed.

A possible candidate use-case for Function Overwriting is Feature Detection as, detecting for specific feature support in the Browser typically only needs to be tested once, at which point subsequent tests are unnecessary.

Below is a basic example of implementing Function Overwritting in the context of an abstraction of the HTML5 Geolocation API.

// Initial "getLocation" implementation. Since we only need to test

// for Geolocation support once, we perform the initial test and then

// overwrite the "getLocation" implementation based on the results of

// the test.

var getLocation = function(success, fail, options) {

if (navigator.geolocation) {

var _options = {

enableHighAccuracy: true,

timeout: 60000,

maximumAge: 0

};

// Geolocation is supported, so we overwrite the implementation

// to simply invoke "geolocation.getCurrentPosition" as there

// is no need to perform the test again.

getLocation = function(success, fail, options) {

geolocation.getCurrentPosition(success,

fail,

options || _options);

}

getLocation(success, fail, options);

} else {

// Geolocation is not supported, so we overwrite the

// implementation to simply return false (a real

// implementation might provide a polyfill here...).

getLocation = function() {

return false;

}

};

Considerations

Since functions are objects in Javascript, it is important to keep in mind that if you add a property or method to a function (either statically or via the function’s prototype), and then overwrite the function, you will have effectively removed those properties or methods as well. Also, if the function is referenced by another variable, or by a method of another object, the initially defined implementation will be preserved and the overwriting process will not occur. As such, be mindful when implementing this pattern. As a general rule of thumb, I typically only implement Function Overwriting when the function being redefined is in a private scope.

Concluding Thoughts

As you can see, Function Overwriting provides a convenient facility for optimizing code execution at runtime. There are many use-cases for dynamically overwriting functions and, where appropriate, they can certainly provide value in terms of performance and code maintainability.

Below you can find an example which demonstrates two basic Function Overwriting implementations. Simply load the page and add some breakpoints in Firebug to test the execution paths; both before and after overwriting each function occurs, or you can simply view the source.
Example

November 19, 2011 Browsers / Design Patterns / HTML5 / JavaScript / Object Oriented Design / Refactoring

Comments Off on Function Overwriting in JavaScript