Dependencies of dgrid

By on September 25, 2012 9:01 am

The dgrid is a fast lightweight grid component, built on Dojo. It represents the start of the art in web development, utilizing numerous modern techniques for modularity and performance. While dgrid is a great component to simply use, there are a number of useful tips we can learn from how dgrid is built, specifically from its dependencies.

The dgrid component was built to minimize dependencies, and only relies on a bare minimum set of modules. These modules were carefully selected because of the critical value they provide dgrid.


Since dgrid was primarily built by SitePen, it should come as no surprise that it is built on Dojo. However, dgrid does not require full base, but only utilizes a selective set of Dojo modules. These include:

  • dojo/_base/declare – This is used to create the dgrid classes.
  • dojo/on – This new event handling module in Dojo is used extensively in dgrid, and is lighter than the old dojo.connect.
  • dojo/aspect – This provides aspect oriented programming functionality that is used to augment methods.
  • dojo/has – This provides feature detection syntax that can be leveraged by the build process for further optimization and removal of unneeded blocks of code. This is also used to conditionally load touch scrolling.
  • dojo/_base/sniff – Several bugs in IE are corrected with dgrid, and would be very expensive to feature detect for. This is only used for past issues, and not future features, so it is future safe.
  • dojo/_base/kernel – Used for deprecated warnings.
  • dojo/_base/lang – Used for mixins and delegates.
  • dojo/_base/Deferred – Used with promises, primarily for interacting with object stores.

A few other Dojo modules are used by some of the plugins (and so they are only loaded if you load the plugin).
A number of the plugins use dojo/query for DOM querying. The ColumnResize plugin uses dojo/dom-geometry and the DnD plugin uses Dojo’s DnD modules. The DijitRegistry plugin uses the registry module from dijit

There are numerous Dojo components that are intentionally not used in dgrid to ensure that optimized builds could be created with only the very minimum of required JavaScript.


The put-selector/put is not in Dojo, but is perhaps the most heavily used module in dgrid. One of the design choices of dgrid was to utilize fast template-free DOM creation. With the extensive DOM creation required in grid creation, and a good tool was needed to avoid clunky DOM APIs. The put() function provided by put-selector allows dgrid to quickly and succinctly build new DOM elements, without requiring verbose templates or long-winded code. The put() function is used over a hundred times in dgrid, and was key to dgrid’s incredibly lightweight footprint and snappy performance. The put-selector module itself is less than a kilobyte minified and gzipped, and more than pays for itself with reduced code in dgrid.

While put-selector is a powerful tool for building DOM elements with compact code, one can certainly go overboard with this tool. With the numerous options provided by put-selector that can be combined an infinite variety of ways, one can easily create long esoteric selector creation strings that may function properly but can be terribly cryptic to read later. In dgrid, one of the lessons we learned is to stick to simple put() calls that generally just create or modify a single element at once. Simple calls that make an element with a class name are not only compact, but can actually improve clarity since they can be read so quickly. For example, in dgrid, you will see usage like:

put(domNode, "div.dgrid-spacer");

This can be quickly read to mean appending a new <div> with a class name of dgrid-spacer. But long nested selectors can be very confusing and difficult to maintain, and should be avoided. With this in mind, put() can contribute to readable, lightweight, fast code.


Finally, xstyle is used to automatically load CSS and add feature-based CSS classes. With dgrid, modules specify their CSS dependencies, and if they have not been loaded by the page (with a <link> or <style>@import), than xstyle will add the necessary stylesheet. While it is still recommended that you include the necessary stylesheets in the page for performance and ordering consistency, dgrid will handle loading the necessary stylesheets for you if you forget.

The dgrid modules also use the the xstyle/has-class module for adding CSS classes to the root <html> element based on feature availability. With this has-class, the actual features that need to be added are explicitly declared. For example, has-class can be used like this:

define(["xstyle/has-class"], function(hasClass){

And then the root <html> element will be given (added) a class name of “has-touch” if and only if the target device has touch capabilities. The features and detection mechanism utilized by has-class are derived from dojo/has (so the features need to be registered there).


The dgrid component provides a good example of how to utilize the latest techniques in AMD modules, pulling only the necessary modules that provide highly valuable functionality with a solid return on investment.