This post has been updated to cover Intern 3.4 and TypeScript 2.3. Read our Intern 4 and TypeScript testing article for more recent information.

When writing object-oriented source code, you generally only want to expose a very specific API to whomever is using it. In many languages you would control this by marking methods and properties you do not want other developers to use as private.

Performance is a critical part of most applications. Research continually shows that good performance is essential for a good user experience.

It’s been a while since we’ve dove into Dojo’s Deferred module on the SitePen blog—the last time was back in 2010 when we introduced the promise-inspired improvements that landed with Dojo 1.5. Quite a lot has happened since on the topic, including a ground-up rewrite of Dojo’s asynchronous foundations in 1.8+, so it’s about time we take another look at deferreds and promises and how it all fits together in Dojo.

One of the primary motivations for creating Intern was to make support for continuous integration testing much easier to achieve with JavaScript-based application development. We recently converted the vast majority of the unit tests in Dojo core from DOH to Intern, in order to streamline the process of regression testing patches for Dojo 1.x.

While it will not happen often, there may be times when you need to patch your Dojo source. Perhaps you discovered a bug and are waiting for the fix to be committed or released, or your application uses an older version of Dojo but you want to use features found in newer releases.

We normally try to schedule new minor releases of Intern about once every four to six weeks, but when we are working on a major release, there will often be a larger than usual gap in the release cycle. In order to keep our users informed of what’s going on, we wanted to write about what we’ll be doing over the next six to twelve weeks for Intern 3, during which time there will be no new releases (except for possible critical patch releases).

A common scenario with web applications is accessing protected resources, which require authentication with the server in order to proceed. A common flow is as follows: User opens web site Web site presents authentication screen User enters credentials Web site presents protected information This is simple enough to begin with, but what happens when the session times out? Or perhaps the application does not require authentication initially, but once the user initiates an action to access protected resources authentication is required? A common approach is to use redirects to an authentication page: User’s authentication session times out Any action on user’s part redirects to authentication screen After successful authentication, user is redirected to the results of the initial action This model works well enough with applications architected around the full page request-response model, but becomes less pleasant with single-page applications that provide a persistent and responsive user interface.

As object stores are frequently used in Dojo-based applications, developers often ask about a good way to utilize stores in their custom widgets. Here we present a common pattern for doing just that in a two-stage approach, starting simple.