The techniques involved in creating modern web applications are continually evolving. It can be difficult to separate out the ones that are truly improving how web applications are developed from those experiments that, while often interesting, are ultimately not worth investing in. From this sea of ideas a couple of trends have risen to the top and are radically changing how web applications are developed. These techniques are microservice-based architectures on the server and single page applications (SPAs) on the client. While an initial review of these two techniques doesn’t reveal any relation, a deeper analysis shows that these two trends are actually great partners and can be combined to enable powerful, yet maintainable, applications to be created.
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.
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:
When developing for the web, it is a recommended best practice to always test your application during development with a web server. This is for two primary reasons. By running a web server, you can approximate a production environment similar to how your application will be served to your users. Also, browsers implement a same-origin policy that is different for quasi-protocols like
file://. Many of Dojo’s modules like
dojo/text, Dijit templates, and
dojox/gfx depend on loading files from the same origin.
- Using when(value) to always create a promise
- Passing callbacks to be applied directly to the value
When writing tests for an application, it’s prudent to add mock or stub data in order to allow code to be properly tested in isolation from other parts of the system. Within a normal Dojo application, there are typically three places where mocking will occur: I/O requests, stores, and module dependencies.
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.
Dojo has long had great support for JSON through
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.io.script), but the API has been less consistent than some of us would like (
dojo.io.script.get, etc.). Additionally, we’ve never provided a server-side implementation, and if we had, it would have been another module name and API call to remember.
With the release of Dojo 1.8, we have introduced the
dojo/request API which provides consistent API calls between browsers, request methods, and environments:
var promise = request(url, options);
- Persevere packages
Learn More About SitePen Support or Contact Us to get started today!