Preprocessing Modules with RequireJS Optimizer

RequireJS provides an effective means of bundling an application for production deployment by way of the RequireJS Optimizer; which allows for optimizing, concatenating and minifying modules via Node or Rhino.

The Optimizer is quite powerful insofar that fine-grained control over various aspects of the optimization process can be implemented with relative ease. One such example is the ability to specify a callback function to be invoked for each module in the build prior to optimization. This essentially provides the necessary hooks needed to implement a preprocessor.

The onBuildWrite option

The optimize method of the RequireJS Optimizer accepts an onBuildWrite option which allows for a callback to be specified. The callback will be invoked prior to serialization of each module within the optimized bundle. Callbacks receive the name, path and contents of the module; and, are always expected to return a value.

For example, consider the following build configuration which demonstrates a basic onBuildWrite callback that simply logs the name of each module processed by the build to the console and, returns the module’s content unmodified.

Using the above configuration, when executed against a (contrived) example consisting of just a single module, “ModuleA”, in Node, it would output the following to the console:

If we were to print out the contents of the files we would see something like this:

With this in mind, a basic preprocessor can be implemented quite easily using the onBuildWrite option. Assume the main.js script has a token placeholder for the build version like so:

We can implement a simple preprocessor which replaces the #version token with a build date as follows:

The above onBuildWrite callback logs the original contents, replaces the #version token with the current date, logs the result and returns the processed content. The output of which would be similar to the following:

As can be seen in the above examples, implementing a basic preprocessor is rather simple to accomplish with the RequireJS Optimizer. The ability to do so allows for some interesting possibilities and is certainly something worth checking out if you are leveraging AMD via RequireJS.

You can fork an example implementation at requirejs-preprocessor-example.

March 24, 2012 JavaScript / Software Engineering
4 Comments

Testing Handlebars Helpers with Jasmine

For some time now, I have primarily been using logic-less templating solutions as they allow for a greater separation of concerns in comparison to many of their logic-based counterparts. By design, the decoupling of logic-less templates imparts greater overall maintainability in that templates become considerably less complex, and therefore, considerably easier to maintain and test.

Handlebars, my preferred logic-less templating engine, simplifies testing even further via it’s elegant Helper API. While Handlebars may not be the fastest templating solution available, I have found it to be the most testable, reusable and thus, maintainable.

Custom Handlebars Helpers

Since Handlebars is a logic-less templating engine, the interpolation of values which require logical operations and/or computed values is facilitated via Helpers. This design is quite nice in that template logic can be tested in isolation from the context in which it is used; i.e. the templates themselves. In addition to the common built-in Block Helpers, custom Helpers can easily be registering in order to encapsulate the logic used by your templates.

Registering Custom Helpers

Registering Custom Helpers is as simple as invoking Handlebars.registerHelper; passing the string name of the helper which is to be registered, followed by a callback which defines the actual helpers implementation.

Consider the following custom Helper example, which, given a string of text, replaces plain-text URLs with anchor tags:

(Gist)

As can be seen in the above example, custom Handlebars Helpers are registered outside the context of the templates in which they are used. This allows us to test our custom Helpers quite easily.

Testing Custom Helpers

Generally, I prefer to abstract testing custom Helpers specifically, and test the actual templates which use the Helpers independently from the Helpers. This allows for greater portability as it promotes reuse in that common custom Helpers (and their associated tests) can then be used across multiple projects, regardless of the templates which use them. While one can test Handlebars implementation code with any testing framework, in this example I will be using Jasmine.

Essentially, testing Custom Helpers is much the same as testing any other method. The only point to be noted is that we first need to reference the helper from the Handlebars.helpers namespace. Ideally this could be avoided as, should the namespace happen to change, so, too, will our tests need to change. That being said, the probability of such a change is unlikely.

Using the above example, in a Jasmine spec, the enhance helper can be referenced as follows:

Then we can test that the helper was registered:

We can then test any expectation. For example, the enhance helper should return a Handlebars.SafeString. We can test this as follows:

The enhance helper is expected to replace plain-text URLs with anchor tags. Before testing this, though, we should first test that it preserves existing markup. In order to test this use-case, we first need to access the return value from our custom Helper, we can do this by referencing the string property of the Handlebars.SafeString returned by our Helper:

Finally, we test that our enhance Helper replaces URLs with anchor tags using the above techniques:

(Gist)

We now have a complete test against our custom Helper, and all is green:
Custom Helper Spec
Note: The above Spec Runner is using the very nice jasmine.BootstrapReporter

And that’s all there is to it. You can fork the example at handlebars-helpers-jasmine.

March 13, 2012 APIs / HTML5 / JavaScript / Object Oriented Design
Comments Off on Testing Handlebars Helpers with Jasmine

Jasmine matchers for Sinon.JS

Lately I have been finding myself writing custom Jasmine matchers which wrap the Sinon.JS API as a convenience. After repeating this process quite a few times I took a step back to see if there was a similar solution already available.

After a brief search, I quickly came across jasmine-sinon which, to my surprise, provides a very similar matcher API to that which I had began implementing. This library really is quite nice as it essentially provides matchers for all common Sinon.JS spies, stubs and mocking use-cases. I am sure jasmine-sinon has saved many developers a lot of time by not having to write their own custom matchers as it has for me.

And so, if you are using both Jasmine and Sinon.JS, and find yourself writing convenience matchers to simplify Sinon.JS integration, jasmine-sinon is an excellent addition which compliments both and is certainly worth considering.

March 7, 2012 APIs / JavaScript / Object Oriented Design / Software Engineering / TDD / BDD
Comments Off on Jasmine matchers for Sinon.JS

Integrating Handlebars Templates in Kendo UI

I have been evaluating Kendo UI recently for its rich set of Widget APIs and general HTML5 UI Framework capabilities. One of the first things I wanted to see was how easily Kendo UI Widgets could be integrated with different Templating Engines, Handlebars in particular.

By default, Kendo UI provides out of the box templating support via Kendo UI Templates as well as support for jQuery Templates. While both solutions are quite good, I generally prefer logic-less Templating, with Handlebars being my preferred Template Engine of choice.

Fortunately, as it turns out, integration with Handlebars is actually quite simple. In fact, integration with basically any Template Engine is rather straight forward and can be implemented transparently.

Integration

In order to use a Template Engine which is not supported by default, one just needs to implement a Widget’s specific template property as a method which returns the resulting markup from a compiled template. This is easiest to understand by viewing examples in the context of both default templating as well as specific template integration.

First, templates in Kendo UI are typically implemented as follows (with this particular example being in the context of the rowTemplate of the Kendo UI Grid):

Note that in the above example the compiled template is directly assigned to the rowTemplate property.

Now, to integrate a Template Engine of your choosing (in this example, Handlebars), assign a function to the rowTemplate property. The function assigned accepts a data object (which represents the data of a row) and, simply invoke the complied template with the data object, returning the result as follows:

And thats all there is to it. You can try the above example implementation here.

March 5, 2012 Browsers / HTML5 / JavaScript
Comments Off on Integrating Handlebars Templates in Kendo UI

Aptana JavaScript Outline View

Aptana Studio is a great IDE for developing Web Applications. The fact that it is built on Eclipse and completely free leaves little to be desired. That being said, there is one feature I have always found to be lacking, which is, the Outline View for JavaScript. Or, more precisely, the fact that it dosent provide an Outline View when your code is sandboxed within an immediate function.

As it turns out, it actually does; only there is a syntactical caveat to it – your immediate functions must have the closing parentheses defined outside of the function.

For example, while my preferred tool for validating Javascript is JSHint, the much stricter JSLint requires defining an immediate function’s invocation (i.e. the closing parentheses) within the function:

In JSLint, failing to do so, such as the following:

… results in the following error:

Error: Move the invocation into the parens that contain the function.

Being somewhat used to conforming to these (arguably unnecessary) rules, after some trial and error I found that adhering to JSLint’s requirements was in fact the cause of Aptana failing to provide an Outline View.

The solution to this problem is quite simple, just keep the invocation outside of the immediate function and Aptana will display the correct Outline View. Technically, I would consider this a bug on Aptana’s part and therefore have filed APSTUD-4364. Hopefully this issue will be resolved. In the interim, I hope this post helps.

Update: As of , this has been fixed by the Aptana team. Details

February 11, 2012 JavaScript
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:

  1. An Immediate Function / Self-executing Function performs some initial test conditions.
  2. 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.
  3. 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:

Practical implementation example:

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)
← Older Articles
Newer Articles →