Blog

Apr 17

dstore 1.1 released

By on April 17, 2015 12:21 pm

dstore

We have released dstore version 1.1, which features a new set of stores for local DB storage. This feature provides the ability to store data locally in browsers, and use high-performance querying capabilities through the disparate technologies of IndexedDB and WebSQL (and localStorage), through the consistent dstore interface. Complex queries can be formulated in your application, and data can retrieved from local database storage with the same APIs and query format as is currently supported with other stores. Queries can then be automatically translated to SQL or cursor operations, depending on the underlying technology available.

Apr 16

We’re Contributing to Dojo 2!

By on April 16, 2015 2:28 pm

At the end of 2014, we looked ahead to determine where to focus SitePen’s open source efforts in the coming year. After our successful contributions to dgrid and the new dstore package, it became increasingly clear that contributing to the future of Dojo was where our team would have the biggest impact and the most fun. So, we’re happy to announce that we are and will be actively contributing to the planning and development of Dojo 2!

SitePen In Action

So far, We have contributed our knowledge and expertise in developing enterprise web applications to what Dojo 2 needs to be; a modular, collection of packages that fit together to deliver high-performance web applications that are well-designed, highly performant and maintainable.

We’ve also poured our hearts (and design resources) into the overhaul of the Dojo Website, which was in dire need of a modern design and cleaner information architecture.

roadmap

So Much Excitement!

A few of the reasons we’re looking forward to contributing to Dojo 2:

  1. the final result will be a tight collection of packages that feel familiar to Dojo developers while leveraging the capabilities and improvements of the modern web platform.
  2. It’s going to be authored in TypeScript! As a superset of JavaScript, TypeScript makes it simpler to support many of the recent ES2015 improvements and provide support for types and interfaces.
  3. Helping to reshape and grow the Dojo community!

Don’t delay! Check out the new Dojo Web site, read the Dojo 2 vision and roadmap and when you’re spun up like us, hit the contribute button and tell us that you want to be part of the future of Dojo!

Apr 14

Minimizing Dijit Instances in dgrid

By on April 14, 2015 11:22 am

dgrid

Dijit and dgrid provide a powerful set of user interface components, allowing for fast construction of sophisticated web applications with excellent performance and interactivity. However, one particular configuration of dgrid that can impact memory and performance: heavy use of persistent Dijit editors within grid cells. The dgrid’s Editor plugin makes it very easy to leverage various Dijits for editing cells. However, using the default “always-on” mode, where a Dijit is instantiated for every editable cell, in combination with a several columns with numerous rows can quickly consume a lot of memory and create a noticeable drag on your application’s performance.

Dijit editors can help provide some fantastic functionality, with powerful widgets for auto-completion, date input, and validation. In this post, we’ll review two approaches to achieving advanced data input in dgrids that are designed for heavy data manipulation without compromising performance or memory consumption.

editOn

The simplest and most straightforward way to limit the creation of Dijit widgets is by creating one shared instance of an editor per dgrid column using the editor’s editOn property. This editor plugin is designed to be used such that editors, including widgets, are not displayed until the user initiates interaction with the cell, and the editOn allows us to enable this behavior, and specify what type of event should trigger the editor. Typically, we might enable the editor with a click event, or possibly a dblclick event. For example:

var grid = new Grid({
	columns: {
		dueDate: {
			editor: DateTextBox,
			editOn: 'click',
			label: 'Due'
		},
...

When editor columns are configured with the editOn property, the cells will be rendered using the standard default high-performance rendering path that simply generates text inside of a cell. Only a single shared Dijit will then be created, and it will be displayed in the appropriate cell when the editOn event is triggered. In this case, the single Dijit editor will only be displayed in response to a click event.

One of the issues with this approach, is that typically the rendering of the grid cells might look quite different than the rendering of the Dijit controls. In some situations this may be desirable, clearly differentiating and highlighting the cell that is currently being edited. However, in some situations this might not be desirable, as it might not be clear to users to that the cells are editable. Visually indicating that cells are editable may be particularly important in situations where cells might be editable or non-editable in different situations. Different rows might be editable, different columns might be editable, or the cells might switch between editable and read-only over time (e.g. switching application modes). Rendered Dijit editors provide a distinct styling that visually invites editing.

However, we can mitigate this issue by styling the editable cells with presentation similar to Dijit editors. For standard text boxes, this could be as simple as creating an inner element with a border and appropriate spacing, that mimics a Dijit TextBox. We could create such an inner element by adding a renderCell method to create one:

columnDefinition: {
	editor: TextBox,
	editOn: 'click',
	renderCell: function (object, value, td) {
		put(td, 'div.pseudoEditor', value);
	},
...

And then we could add some styling. This will look similar to a Claro-themed TextBox (although again, you might actually want some differences to more distinctly highlight the cell that is being edited):

.pseudoEditor {
	border: 1px solid #b5bcc7;
	height: 13px;
	padding: 2px;
}

Other widgets may require more attention to provide similar styling. For example, if you wanted to mimic the dropdown button/arrow of a DateTextBox, Select, or ComboBox, you would need to provide a corresponding element (or psuedo-element) and icon. You might also want to listen for click events on this pseudo dropdown element, and in response to such a event, instantiate the widget and then open the dropdown of the widget after it has been rendered (usually done by calling the widget’s loadAndOpenDropDown method).

Customized Native Inputs with Event Delegation

There are situations where the editOn approach might not be ideal. If you are using validation, you may wish for the validation indicator to persist even after a user has moved on to other cells. With the editOn configuration, the widget will be removed once the user is done editing (on the blur event), and so validation won’t be naturally retained. Also, there may be situations where you wish to provide specialized input handling, that Dijit doesn’t provide. Or maybe you don’t want to load the Dijit dependencies (perhaps for lightweight mobile applications). While this is typically a more involved approach, it is very doable.

To begin, rather than configuring our editor to use a widget, we will define an input to use as the editor. We can do this by providing a string to the editor property value. This string will be used as the type attribute value for a native <input>. This will give us some basic editing capability. From here, we could then setup an event listener at the grid level, using the concept of event delegation, to listen for any events of interest from the editors. This can give us a chance to respond to click events to open any drop downs, or dgrid’s dgrid-datachange events to perform validation and add appropriate validation indicators to the cell. Here is an example of listening to dgrid-datachange events to perform validation:

grid.on('.field-someProperty:dgrid-datachange', function (event) {
	var cell = grid.cell(event);
	var value = event.value;
	var valid = isValid(value);
	// add or remove the error-state class based on if the value is valid
	put(cell.element, valid ? '!error-state' : '.error-state');
	if (!valid) {
		// prevent the value from changing
		event.preventDefault();
	}
});

We might want to build on this to add a mouse hover handler to show a tooltip with more validation error information.

The editor can easily be configured for a native input element based on an <input>. However, if you want to use another input element, such as a <select> element, this will require additional effort. This could be accomplished by writing your renderCell method to generate the <select> element and writing your own change event handler, and manually updating data values in response to changes in the input.

Another approach is to mimic a widget with the editor value that you have provided to the dgrid editor (make the editor think it is a widget). This is somewhat of a fragile approach, since it relies on undocumented interactions in the editor, but you can provide a function as an editor (if the editor is a function, dgrid treats it as a widget, and your function will be executed for each cell, as if it were a widget constructor), and assign a self-reference of the focusNode property, and define a connect to handle event handling, to handle the necessary calls and property interactions that dgrid will make to the widget:

someColumn: {
	editor: function (args) {
		var select = ... create the select or other input element
		// the editor keys of the focusNode to get the element
		select.focusNode = select;
		// provide the event handling function that the editor will use
		// to register for listening to change events
		select.connect = eventHandlerForTheseElements;
	}

Using custom renderers and custom event delegation handling, virtually any type of input can be created efficiently.

Again, we recommend optimizing the number of Dijit inputs within a grid to maximize performance. Creating Dijit inputs through a dgrid can have an impact on performance. For editors that can be appropriately styled while they aren’t being edited, the editOn approach can make it possible to only instantiate a single shared Dijit editor instance per dgrid column. If you require editors with persistent customized behavior, like validation, using native inputs with event delegation to customize the behavior may be your best option. If you are experiencing performance problems with grids in your application, we would love to help. A properly optimized dgrid is extremely fast and fluid, and you (and your users) shouldn’t settle for less.

Mar 19

Legitimate, memory-efficient privacy with ES6 WeakMaps

By on March 19, 2015 8:06 am

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. However, if you have been writing JavaScript for any amount of time, you know that there is no private keyword for object properties and methods. The best option we have prior to EcmaScript6 (ES6) to protect data is to hide it inside a closure. But this comes with problems of its own, notably that data must be shared across instances, deliberately removed in order to prevent memory leaks, or new privileged methods must be allocated each time the object is instantiated. Fortunately, ES6 brings us WeakMaps, which we can use to achieve legitimate privacy without the risk of accidentally blocking garbage collection.

Mar 17

Memory Consumption: the Externality of Programming

By on March 17, 2015 11:35 am

Performance is a critical part of most applications. Research continually shows that good performance is essential for a good user experience. Reasonable load times, smooth animations, and responsive interaction gives user a sense of interaction and immersion, whereas slow load times frustrate users, and choppy animation and interaction quickly makes an experience awkward and disconcerting. As developers, we wisely work for better performance by understanding performance characteristics, and verifying performance with tests. However, one aspect of performance can be particularly difficult to assess, and its effect can easily be underestimated. Memory consumption can have a large impact on performance, but in ways that can easily be missed and ignored.

Mar 6

Understanding Deferreds and Promises in Dojo

By on March 6, 2015 11:18 am

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.

Feb 27

Optimized Navigation: Isomorphic Resources

By on February 27, 2015 8:14 am

When building web applications, developers often face the dilemma of whether to use traditional server-side rendered pages, or client-centric applications that rely on Ajax/JSON data requests, with client-side rendering of data. These two approaches also tend to dictate navigation (among other things), leading to traditional page navigation or a single-page application (perhaps with hash-based navigation). With the traditional approach, content is delivered in HTML form, relying on browser-driven page loads for different views. However, modern applications with more sophisticated user interfaces, often use a single-page style, controlling events, view updates, and relying on Ajax-style communication with the server to load additional content, typically in structured object format, like JSON. The traditional approach naturally works well with search engines, and browser navigation and can be quickly rendered by the browser. Single-page applications facilitate well structured user interfaces, with clean separation of presentation and data. But is there a way to combine the best of both worlds?

Feb 18

From DOH to Intern: Updating Dojo core’s tests

By on February 18, 2015 10:11 am

Intern

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.

This was a very large amount of work, and we learned a number of interesting things along the way that should be useful to you in writing your own tests.

Feb 17

Online Dojo workshops!

By on February 17, 2015 1:36 pm

We’ve offered our full line-up of public Dojo training workshops for over eight years at locations around the world. Attendee response is always positive because people love that our instructors are actual, web developers themselves! “Lively”, “engaging” and “wow” are just a few words that describe our team of instructors; JavaScript and Dojo experts who understand and relate to the pain and joy that you experience every day makes our training workshops that much more worth it.

We think it’s a real shame that there are developers that have to go it alone because they are in remote locations or can’t travel to one of our many in-person workshops. So we spent countless hours and many sleepless nights creating a way to ensure that no developer misses out on the opportunity to learn best practices building web apps with the Dojo Toolkit!

We’re very excited to announced that we are now offering…

Online, public workshops!

Dojo Core: The Essentials
Dojo Core: The Essentials
March 9-10, 2015
US$400
Dojo Widgets: The Essentials
Dojo Widgets: The Essentials
March 11-13, 2015
US$600

We will be using our very cool, Dojo-based workshop tool to deliver four hours of workshops each day, where you can expect to learn the essentials of using Dojo core, Dijit, and dgrid while watching expert developers live code all the while having the chance to try it yourself and ask questions, real time!

Are you In?

Register now! Demand for this workshop will dictate how soon we’ll hold the next one!

If you have any questions, ask in the comments or contact us.

JavaScript Workshops