You are currently browsing archived articles from

Basic Dependency Injection with RequireJS

Saturday, December 15th, 2012

Recently, I was having a conversation about the basic concepts of IoC/DI, and, specifically, how they pertain to modern (single page) JavaScript Web Applications. This discussion was quite interesting, and so I felt inclined to share some thoughts on the subject with a wider audience.

Dependency Injection in JavaScript

Being a dynamic language, when designing JavaScript based architectures, in comparison to architectures which are under the constraints of a statically typed language, one is typically less inclined to consider the relevance of, or immediate need for, a complete IoC container. Of course, context is key, and so there are certainly JavaScript applications which can benefit from an IoC container (such as wire.js). As such, it would not be prudent for one to suggest otherwise; but rather, this is simply to say that for the majority of JavaScript applications, standard AMD loaders provide a sufficient means of managing dependencies; as the rigidness inherent to statically typed languages which IoC containers help manage are generally less relevant to dynamic languages.

With that being said, while a robust IoC container may not be necessary for the majority of JavaScript applications, it is quite important to emphasize the benefits of employing basic dependency management and Dependency Injection; as this is an essential design characteristic which is critical to the success and overall maintainability of large scale client-side web applications.

Facilitating Code Reuse

Anyone who has been responsible for developing and maintaining specific core features across multiple applications is likely to understand that the ability to facilitate reuse of JavaScript modules is crucial. This is particularly important in the context of architectures which must account for the ability to support mulitple implementations of the same application across different form-factors; for, the ability to manage and configure dependencies can prove paramount; allowing for a framework upon which various form-factor specific implementations of an application can be supported.

In addition to this, as one might expect, having the flexibility necessary for configuring dependencies lends itself, quite naturally so, to various unit testing scenarios.

Configuring Dependencies with RequireJS

Though not always immediately apparent, applications leveraging RequireJS are essentially using a basic form of Dependency Injection out of the box – even if not in the most purist sense of the term. However, the simple matter of mapping module names to module implementations can be considered, in-of-itself, a basic form of Dependency Injection, or perhaps, one could argue this as being more of a Service Locator, as RequireJS does not instantiate dependencies on a clients behalf. Regardless of the preferred classification, this mechanism of defining dependencies is quite important, as it affords developers the ability to change module implementations as desired without the need to change client code. Of course, such modules must adhere to a specific contract (interface) so as to ensure clients which depend on specific named modules receive the expected API.

Explicit Dependencies

Consider a rather contrived example of a shared Application module which is used across two separate applications; one for Mobile and one for Desktop; with the Application module having a dependency on an AppHelper module:

Both the Mobile and Desktop applications can easily map the AppHelper module to a context specific implementation via their respective main.js configurations:

Based on the above, it is rather evident that the AppHelper module is mapped to the appropriate application specific implementation; MobileHelper for mobile, and DesktopHelper for desktop. Additional context specific APIs can just as easily be defined, and thus provided as dependencies to other modules as needed using this very simple pattern.

Implicit Dependencies

Dependencies need not always be explicit, but rather they can also be implicitly mapped based on the path to which each application’s main.js configuration resides, or based on the configured baseUrl path.

For instance, given the above example, we can map a Templates Module, and implicitly inject the path to each context specific template based on the application’s default path, or baseUrl path:

As can be seen, each application’s main.js defines a Templates module and a TemplateSource module, respectively, with each being shared amongst both the Mobile and Desktop specific applications. The Templates and TemplateSource modules are defined as follows:

While both the Mobile and Desktop applications may share the same Templates and TemplateSource modules, the specific implementation of the templates loaded from TemplateSource is determined via each application’s base path; thus, the path to app/templates/some-view.tpl automatically resolves to the context specific template; i.e.: mobile/app/templates/some-view.tpl for Mobile, and desktop/app/templates/some-view.tpl for Desktop.

Concluding Thoughts

While the above examples are rather basic, they do serve well to demonstrate just how easily one can design for module reuse across different applications with RequireJS, which itself allows for much more robust configurations of modules; such as loading context specific modules at runtime, augmenting modules for differing contexts with mixins, providing third-party libraries based on a particular form-factor (e.g. jQuery for Desktop, Zepto for Mobile, etc.), and more.

You can clone the above example here.

Quick Tip: Chrome Developer Tools Shortcut Keys

Wednesday, November 21st, 2012

Sometimes it is the more subtle, less obvious features provided by tools which prove to be surprisingly useful. Interestingly, while such features can save developers considerable time and effort, they are often much less apparent, and thus, occasionally overlooked when compared to their main counterparts.

A noteworthy example of some very simple, yet extremely useful features can be found in just a few of the basic Chrome Developer Tools shortcut keys. Below is a brief description of the most convenient shortcuts I find myself using regularly.

Go to Source (Cmd-O)

Perhaps the most useful short-cut available in the sources panel, Cmd-O allows one to quickly search for a specific source file (thanks to @augiemarcello for this one):
Chrome Developer Tools Command-O

Show Functions (Cmd-shift-O)

Another extremely useful feature in the Sources Panel, Cmd-shift-O displays a list of all functions and their corresponding line numbers within the current source file:
Chrome Developer Tools Command-Shift-O

Clear Console (Cmd-K/)

Clears the console when in focus:
Chrome Developer Tools Command-k

Previous/Next Panel (Cmd-[ / Cmd-])

Toggles between Developer Tools Panels (e.g. Elements, Resources, Network, Sources etc.):
Chrome Developer Tools Command-[]

There are quite a few additional shortcut keys available in Chrome Developer Tools, and Jared has done a excellent job of providing a Devtools cheat sheet. I highly recommend trying some of them out; committing to memory those which you find most useful – and sharing them with others as well.

HTML5 Document Outliner

Sunday, October 21st, 2012

Recently, while preparing a training session on HTML5 Semantic and Structural Elements, I was rather intent on conveying the importance of an application’s overall markup and structure, while also expressing the importance of not being overly concerned with the absolute technical “correctness” of each and every element used.

With this in mind, providing a general overview of HTML5 sectioning content, and HTML5 Document Outlines, seemed appropriate points to emphasize.

Before doing so, I was looking to utilize a simple utility to provide a means of visualizing an HTML5 Document Outline, and the very useful Chrome Extension, HTML5 Outliner, proved to be an ideal tool for the task.

In particular, the HTML5 Outliner is quite helpful in validating the overall structure of single page web applications, whereby the constructed page is based on multiple disparate client-side templates being rendered at runtime; in which case it can be rather useful to have a holistic view of an application’s structure.

And so, if you are building modern client-side web applications, and using Chrome, if you haven’t done so already, I certainly recommend installing the HTML5 Document Outline for quickly viewing an application’s overall structure.

Github Source Anchors

Friday, September 7th, 2012

Recently while viewing the documentation and source for Lo-Dash, I noticed an interesting Github feature which allows for linking to any line number within a source file, and highlighting the line when the page is loaded, via URL anchors.

Linking to line numbers in source files

To link to a specific line of code in a source file on Github, simply click on the line number, which updates the URL with an anchor to that particular line number, or manually append an anchor to the URL in the form #L<line-number>.

For example, here is a link to the EventRegistry in the Backbone.EventBroker.

Linking to blocks in source files

After discovering this interesting little feature, I tried out a few other things and found that a block of code can also be anchored to as well, allowing for the block to become highlighted when the page is loaded.

Creating an anchor to a code block is as simple as selecting a line and pressing CTRL+SHIFT while selecting another line. Alternately, the line numbers can be manually added in the hash by specifying start and end line numbers in the form #L<line-number-start>-<line-number-end>. For example, here is a link to the EventBroker.get method.


Since source files are likely to change with each commit, it is important to be mindful of the potential side effect of linking to specific line numbers. This is necessary for the obvious reason that changes in source could result in links to line numbers which no longer correspond to the expected code.

That being said, the ability to link to a certain line in a source file is still a rather cool and useful feature, even if only used for sharing links quickly, or for linking to specific commits which are unlikely to change.

Determining if an object is empty with Underscore / Lo-dash

Saturday, August 18th, 2012

When leveraging the utilities provided by Underscore or Lo-dash, determining if an Array, String or Object is empty is quite simple via the isEmpty() method.

The isEmpty() method and Objects

In the context of an Object, it is important to keep in mind that _.isEmpty() is implemented such that it determines an Object as being empty in a literal sense. That is, objects are traversed to determine the existence of any own properties – irrespective of their actual values. Thus, _.isEmpty() will return false if an object contains any own properties, even if all property values are undefined, otherwise it will return true.

While these details may seem obvious, it is important to be mindful of them in order to avoid potential false positives when trying to determine if an object’s properties are all undefined.

For example, consider the following object:

Technically, the above object is not empty, as it contains two own properties. Thus, invoking _.isEmpty() with this object will return false, which is correct, though one may have mistakenly assumed it to have returned true since all of the object’s properties are undefined.

Extending Underscore / Lo-dash

With an understanding in mind of how _.isEmpty() is implemented in the context of objects, should one need to determine if an object is empty based on the values of it’s own properties being undefined, a simple extension, such as the following, can be mixed into Underscore or Lo-dash to provide both the default implementation as well as an extended implementation which takes this into account:

Given the above, we can then invoke the original isEmpty implementation, as well as the extended implementation as follows:

The ease with which libraries such as Underscore and Lo-dash allow for adding extensions and overriding default implementations is a key design feature which makes them not only extremely flexible, but also quite enjoyable to work with as well.

Managing Client-side Templates with RequireJS

Sunday, July 15th, 2012

When developing single page web applications, patterns of structure, organization and reuse become ever more important. This especially holds true when there is a need to maintain mulitiple web applications, each of which targeting a specific form factor, while also sharing many of the same underlying core APIs.

In the context of client-side templating, such patterns begin to emerge, quite naturally so, when leveraging RequireJS modules and the RequireJS text plugin.

Template Modules

One specific pattern I have found myself implementing is that of a single Templates Module which provides a centralized location from which all compiled templates within an application can be referenced. A rather simple pattern, Template Modules are only concerned with loading, compiling and providing a public API to access compiled templates; that is, a Templates Module simply requires all external templates, and provides named methods for retrieving the compiled template functions of each.

A basic implementation of a Templates module is as follows (while Handlebars may be used in this example, any template engine would suffice):

The main benefit of implementing a Templates Module is reuse, as different modules can use the same templates without a need for redundantly requiring and compiling the templates themselves. Additionally, Template Modules provide a convenient means of abstracting away the underlying template engine from client code, thus reducing the amount of refactoring needed should the template engine itself ever need to change.

When using the RequireJS Optimizer, each external template will be included in the optomized build and loaded synchronously, and so there is no additional overhead in terms of HTTP requests when requiring each template in a single location.

You can check out a basic example implementation of a Templates Module (in the context of Backbone) here.