One of the nice features of testing with Intern and Leadfoot is the ease of authoring functional tests to mimic end-user behavior. The API for retrieving relevant DOM nodes is relatively straightforward, usually with a single line of code needed to get a reference to the relevant node.
When we started writing tests for Dijit, we realized that it was often a fair amount of boilerplate to get references to specific widget instances, attach points within those widgets, and property values of widgets. One of the advantages of Intern is you can integrate this boilerplate into a helper. So, we set out to create a simple Intern helper utility to make these operations as efficient to author as normal functional tests.
It’s been over a year since the release of dgrid 0.4, which brought about some major changes, including integration with the new dstore API. Since then, we (and others) have used it in numerous applications, and we’ve continued to refine it.
Now, at long last, we’re proud to announce dgrid 1.0!
For the dgrid 0.4 release we added a new demo and helper utility, the dgrid Laboratory. This is more than just a demo, as it allows you to quickly explore and build different dgrid configurations, returning boilerplate code for efficiently including dgrid within your application. Although not every possible configuration is supported with this tool (sub-rows, column sets, and compound columns), it is very useful for visually generating complex base configurations for use in your applications. The dgrid Laboratory itself was built using dgrid as well!
Using the dgrid Laboratory
The left panel of the dgrid Laboratory allows you to select and modify the grid’s configuration. The right panel provides a preview of the grid as well as generated code. These right panel tabs are updated in real time as you make modifications to the dgrid options in the left panel.
Adam Klien, software engineer at Google, announced on ESDiscuss that they were withdrawing the proposal to implement
Object.observe and plan to remove it from V8 by the end of the year.
Object.observe, they assured me the other browsers would eventually implement the rest of Web Components. I also missed that Polymer 1.0 abandoned
Recently, we had the opportunity to assist BuyWinR, a company based in Brisbane, Australia. In this case, we went from initial inquiry to solution in less than 48 hours. To provide insight into how a typical support issue might be solved, the founder of BuyWinR has allowed us to share this story.
SitePen is a huge supporter of TypeScript. It allows our developers to write using modern standards support for ES6 and some ES7 features while still targeting ES5 browsers. It also includes a type system that adds to our code’s integrity and makes it easier to write good software.
Nearly every sufficiently large web application looks for a mechanism to efficiently synchronize or bind data between the Model and the View. There are many large scale application frameworks and approaches focused on this, whether the binding is one-directional like React, or follows other approaches such as those seen with AmpersandJS, Angular, Aurelia, Backbone, Ember, Knockout, Mayhem, or many others listed on ToDoMVC.
Simple Model-View synchronization
Many of our customers use Dojo and Dijit, because it’s a comprehensive toolkit for building web applications that work today, and while it does not intend to be an MV* framework, it already includes a lightweight approach to getters and setters.
Dojo’s Deferred module provides a convenient way of managing asynchronous operations. If you’re new to deferreds, you can get a good introduction by reading our blog post and some tutorials on dojotoolkit.org: Getting started with Deferreds and Dojo Deferreds and Promises.
There are a few features of the
then method on a promise that are important to understand and remember:
then always returns a promise
- the promise returned by
then resolves to:
- the value returned by the callback passed to
- if the callback returns a promise, the value that promise resolves to