Blog

Jul 23

Dojo FAQ: When should I use DocumentFragments?

By on July 23, 2014 11:36 am

DojoFAQ

A common practice when adding new elements to a document is to add them to a container DIV and then insert that node into into a document. A lesser used alternative is the DocumentFragment class. So, what is a document fragment, and when should you use one instead of a container DIV?

The main reason to use a container DIV is performance efficiency. Adding elements to a DOM document causes a relatively expensive document reflow, while adding elements to an external node and then inserting that into the document only causes a single reflow. There are times, however, when using a container DIV is problematic. For example, assume you need to add 1000 table rows to an existing TBODY element. Using a container node would result in an invalid document since there is no element that can contain TR elements in a TBODY. However, you can use a document fragment to efficiently handle this use case.

A document fragment is a lightweight container that looks and acts like a standard DOM node, with the key difference that when a document fragment is added to a document, the children of the fragment are added in its place. This operation is still treated as a single node insertion, in that the document is only reflowed after all the children have been added, so inserting a fragment is generally as efficient as inserting a single node. In the case of our table example, the new TR elements can be added to a DocumentFragment, and then the fragment can be appended to the TBODY. The result will be that all the TR elements in the fragment are appended directly to the TBODY.

DocumentFragments are nothing new; they are supported as far back as Internet Explorer 6. Dojo’s dom-construct.toDom function (and the dojo._toDom function before that), which converts HTML strings into DOM nodes, has always returned the new nodes in a DocumentFragment. So, to answer the original question, you can use a fragment anywhere you don’t need the structure provided by a container node, and you should use a document fragment in situations where a container node is unsuitable.

Learning more

SitePen covers DocumentFragments and other DOM manipulation topics in our Dojo workshops offered throughout the US, Canada, and Europe, or at your location. We also provide expert JavaScript and Dojo support and development services. Contact us for a free 30 minute consultation to discuss how we can help.

Jul 16

Dojo FAQ: When should I provide callbacks to dojo/when?

By on July 16, 2014 12:04 pm

DojoFAQ

In JavaScript it is common to use a Promise as a placeholder for a value which will eventually be provided upon completion of some operation. However most JavaScript methods run synchronously and immediately return a value. Dojo’s when module provides a transparent way to apply callbacks to either values or promises. It can do this in one of two ways:

  • Using when(value) to always create a promise
  • Passing callbacks to be applied directly to the value
Jul 9

FAQ: How can I create a JSONP service-based store?

By on July 9, 2014 11:16 am

DojoFAQ

Dojo’s store API is a common interface for providing data to user interface widgets, such as dgrid, Dijit Select, and Dojo Charting. The beauty of having a consistent API is that once you’ve defined an interface for a data source, that data becomes easily available to all widgets that support the store API. We’re going to look at how you can create a basic, read-only dojo/store API-compliant module for accessing GitHub’s API (specifically, GitHub issues), an example of implementing your own Dojo store.

Jul 2

Dojo FAQ: Dynamically loading CSS

By on July 2, 2014 11:46 am

DojoFAQ

In large JavaScript applications, it can be beneficial to dynamically load CSS stylesheets. For example, if a certain JavaScript widget, such as a complex grid, uses a large standalone stylesheet for its display aesthetics, it would be optimal to only load this stylesheet if the widget is in use, rather than always including the CSS source on each application load.

Jul 1

Intern 2.0 released

By on July 1, 2014 12:31 pm

We’re happy to officially announce the release of Intern 2.0. This is our most ambitious version yet, with brand new libraries to improve test reliability and performance, new features to make debugging instrumented or compiled code easier, and more!

  • Installation times have been reduced by 25%
  • Proxy server performance sending static files has been improved by 55%
  • CommonJS modules now receive full code coverage analysis and reporting
  • Stack traces on test failures now provide accurate line/column information back to the original source code using source maps
  • BrowserStack is now supported out of the box
  • TestingBot is now supported out of the box
  • Chai as Promised is now supported by the functional testing interface
  • Bugs and issues related to the WD.js library, like poor error reporting, no longer exist

For more information on this release, including a full list of enhancements, bug fixes, and upgrade advice, visit the release notes. While this is a new major release with a few backwards-incompatible changes, we’ve taken extra care to make sure that only a very small number of tweaks are necessary for an initial upgrade from Intern 1 (usually just updating the tunnel configuration), so in less than 15 minutes you should be up and running with everything that Intern 2 has to offer.

If you or your team would like assistance upgrading your test suite to use all the features of Intern 2, or if you are looking to have a new feature added to Intern, SitePen is here to help with expert advice, support, and custom development services. Get in touch today to learn how we can help.

Jun 24

REST tips

By on June 24, 2014 11:50 am

At SitePen, we have long been advocates for building web applications on a RESTful architecture. Over the last several years, it has been exciting to see organizations increasingly provide RESTful endpoints for the Dojo-based front-ends that we support and develop. A well-designed REST backend can be a excellent foundation for manageable, scalable applications, that will be ready to evolve into the future. I wanted to share a few tips for designing a set of RESTful services.

Jun 18

Dojo FAQ: Does Dojo have routing like Backbone and Ember

By on June 18, 2014 11:42 am

DojoFAQ

A client-side router allows an application to respond to changes in the URL, handling browser navigation, history, and making single page applications bookmarkable. The user can share the URL or use it to quickly navigate to specific states of the application. Many JavaScript frameworks and toolkits, including Dojo, provide a mechanism for registering and handling URL events. Dojo provides routing with the dojo/router module.

Jun 17

Local Database Stores

By on June 17, 2014 10:57 am

Modern browsers have powerful new database capabilities that enable applications to store data locally, and perform advanced indexed queries without a network connection. Applications can be built with offline support without any disruption to data interaction, including searching. However, these database capabilities have traditionally been difficult to use across browsers since Safari only supports WebSQL (although version 8 is slated to include IndexedDB support), and Firefox and Internet Explorer only support the W3C’s IndexedDB API (Chrome supports both). And these two interfaces couldn’t be more different, making it very problematic to write applications that work offline on all the major browsers.

But, it is now much easier to access these database capabilities. By taking advantage of the consistency of the Dojo object store implementation, in version Dojo toolkit version 1.10, dojox/store now includes object store implementations for IndexedDB and WebSQL, along with a wrapper that will automatically delegate to the appropriate store implementation based on browser support. With a single common interface, you can retrieve, update, add, and delete objects, and even perform sophisticated queries in exactly the same way with the different underlying storage implementations.