Dojo has an API for Comet-style real-time communication based on the WebSocket API. WebSocket provides a bi-directional connection to servers that is ideal for pushing messages from a server to a client in real-time. Dojo’s dojox/socket module provides access to this API with automated fallback to HTTP-based long-polling for browsers (or servers) that do not support the new WebSocket API. This allows you start using this API with Dojo now.
The easiest way to provide access to data from an object is to simply provide it as a property of the object. However, what if you want to give others direct property access, but computing the value of the property is non-negligible, and you want to avoid computing it if it is not used?
This scenario is where ECMAScript 5′s getters are valuable, as they allow you to define a property that is computed on access. We can go a step further and cache the result so it is only computed once at most (even for multiple accesses), while still avoiding computation if it isn’t necessary. This can be accomplished with this function:
var lazyProperty = function(target, propertyName, callback){
var result, done;
Object.defineProperty(target, propertyName, {
get: function(){ // Define the getter
if(!done){
// We cache the result and only compute once.
done = true;
result = callback.call(target);
}
return result;
},
// Keep it enumerable and configurable, certainly not necessary.
enumerable: true,
configurable: true
});
}
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:
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
The new dgrid is designed to work with object stores, which makes it easy to create grids that are driven by real-time updates. This is a great feature for rapidly changing data like stock prices or game scores.
To make a dgrid update in real-time, we just need to back it with a real-time object store. This can be accomplished by simply wrapping it with the Observable store wrapper. If we start with a JsonRest object store that retrieves data through REST calls, we can wrap that with Observable:
var stockStore = new Observable(new JsonRest({
target:"./data/stocks.json"
}));
Now our stockStore is real-time ready. Next we have to write some code to notify listeners of changes in data. Observable stores provide a notify() method that we can call to notify the store of changes in data. Typically, for a real-time application with rapidly changing data, we would create a Comet connection to a server, and as we receive data from the server, we could notify our store, which would automatically trigger updates in the grid. This might look something like:
// create a socket or long-polling connection to a server and then listen for messages
mySocket.on("message", function(message){
// got a message
var data = message.data;
// assuming the data is the object to update, we can update the store with:
stockStore.notify(data, data.id);
});
Dojo has long had great support for JSON through dojo.fromJson() and dojo.toJson(). But with the advent of ECMAScript 5′s JSON object, and the increased adoption of this API among browsers, there is now a standard API for JSON parsing and serialization. Dojo 1.7 added a module that aligns with this standard API. This enables Dojo to directly pass through parsing and serialization when native support exists. Using the native JSON parser and serialization is much faster, and allows Dojo to leverage the high-speed, in language capabilities. Also, Dojo’s dojo/json module is based on the feature detection (has() API) system that is integrated with the build system, so it will be possible to leverage the build system to create browser-specific builds (like mobile builds) where this module consumes just a few bytes.
Dojo 1.7 added full support for asynchronous module loading, defined with the widely adopted asynchronous module definition (AMD) format. The new module loader and module format offer faster module loading, better performance, and wide interoperability. However, for many, upgrading from the legacy Dojo module format to AMD is daunting, since the new module formats look much different than the old. Despite the large visual difference though, upgrading is a fairly straightforward process. There may be more effort involved in leveraging the new features and APIs in 1.7 and 1.8, but that is a different topic.
As web applications continue to grow more advanced and more heavily rely on JavaScript, there has been a growing movement towards using modules to organize code and dependencies. Modules give us a way to make clearly distinguished components and interfaces that can easily be loaded and connected to dependencies. The AMD module system gives us the perfect path for using JavaScript modules to build web applications, with a simple format, asynchronous loading, and broad adoption.
The Asynchronous Module Definition (AMD) format is an API for defining reusable modules that can be used across different frameworks. AMD was developed to provide a way to define modules such that they could be loaded asynchronously using the native browser script element-based mechanism. The AMD API grew out of discussions in 2009 in the Dojo community which then moved to discussions with CommonJS on how to better adapt the CommonJS module format (used by NodeJS) for the browser. It has since grown into its own standard with its own community. AMD has taken off in popularity, with numerous module loaders and widespread usage. At SitePen we have worked extensively with AMD in Dojo, adding support and now actively building applications with this format.
The mobile device revolution has placed new demands on web applications. Mobile devices generally have lower bandwidth and lower CPU capacity, forcing us to avoid large complex code. Fortunately, the mobile space has a greater percentage of users running modern browsers than on desktops, so it is feasible to write similar applications with much less code when targeting mobile browsers. However, dealing with the multitude of different platforms is non-trivial, and creating appropriately small packages of code for mobile devices, while still providing sufficient capability for older desktop browsers can be challenging. While there are different ways to deal with platform discrepancies, the hard lessons of the last decade have shown that feature detection is the mechanism for branching.
Fortunately, Dojo 1.7 has evolved with a powerful new feature detection infrastructure. Dojo now uses the popular has() pattern for feature detection in combination with a has()-aware build system. While it is easy enough to write feature detection tests with ad-hoc JavaScript expressions, the has() pattern defines a specific syntax such that the build system can detect these feature-based branches, and one can create application builds that are highly optimized for specific devices, with known feature shims factored out.
Mobile web development is an expansive field of engineering and design, and can require extensive expertise and involve using many tools. Dojo is designed for mobile development at many levels, including lightweight, granular modules for bandwidth and CPU constrained devices, touch and gesture events, mobile-style widgets in Dojo Mobile, feature branching for mobile customizations, and much more. However, before even getting into these sophisticated aspects of mobile development, it is worth considering some of the basics of mobile layouts. Many web sites and web applications can provide a vastly improved user experience by simply employing viewport definitions and adaptive layout techniques.
First impressions are critical, and for many outdated web pages, the first thing a user experiences is illegibly small text that they must zoom in to read properly. Probably the first thing any web developer should learn about to prepare for mobile devices is the “viewport” meta tag. This simple tag instructs mobile devices what scale and dimensions to use to display a page, so that users can be instantly greeted with a properly scaled page where they can immediately start reading and consuming your information without zooming.
The new dgrid is a powerful, but lightweight grid component. It is specifically built to be easily styled with CSS, rather than relying on programmatic properties and changes. The dgrid makes numerous element classes available to reference from CSS and avoids inline styles as much as possible to ensure ease of CSS customization.
Before diving into CSS styling of the dgrid, it is highly recommended that you start your dgrid styling stylesheet with an import (or a link) of dgrid.css (and any other dgrid stylesheets you will use). This will ensure that dgrid.css is loaded before your rules so that your rules can override those in dgrid.css without requiring higher specificity. The dgrid component will load dgrid.css if it hasn’t already been loaded by you, but this will usually cause dgrid.css to load after other stylesheets, and therefore take precedence over other stylesheets.
@import "dgrid/css/dgrid.css";