SafetyNet is an annual conference hosted by Pulsiam and is focused on trends in software for the safety industry. Because of our expertise in shaping the modern web and our ongoing work with Pulsiam’s application development efforts, I was invited to deliver a keynote about the past, present, and future of the web, as this industry begins to transition to web-based solutions.
We were recently asked about options for mixing Dojo widgets and Angular 2 components into the same application:
- Is it possible to render an Angular 2 component and Dojo widgets on the same page?
- Are there any special configuration settings needed?
- What’s the best way for Angular 2 and Dojo to communicate and/or send messages?
- What kind of complex challenges and communication issues should we be aware of?
- For an application that assembles many different components, if some of these are are Dojo widgets and some are Angular 2 components, how can we get them to play nicely together?
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.
Throughout the course of June, the dgrid StackOverflow tag saw a series of questions regarding usage of dgrid and dstore with the Django REST Framework. Based on the flurry of closely-related questions that popped up, I became quite curious as to the actual level of difficulty involved with this integration.
Over the holiday weekend here in the US, I decided to let that curiosity get the better of me. In this blog post, I share the results of that endeavor, stepping through the process of customizing a simple Django Rest Framework project to communicate with dgrid using dstore’s Rest store.
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.
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.
While a more recent advancement allows us use the HTML5 file API to retrieve contents from files, this approach is not universally supported in web browsers as yet. Instead, we will access data from user-uploaded CSV files using the following steps:
- Upload a file to the server
- Retrieve the file from the server
- Load the data into an easy-to-use format
While this release does not focus on new features, it is an exciting release because we refactored some important components and improved dgrid’s stability while making it more flexible and extensible. Let’s take a look at the most significant changes.
A better store for tomorrow
Dojo object store support in dgrid is an important and convenient way to populate a grid with your data. Connect a grid to an observable store and your grid will update automatically as modifications are made in the store.
Unfortunately in earlier versions of dgrid, there were edge cases that would cause a grid to get out of sync with an observable store. While dgrid 0.3.13 and later worked around many of these issues, ultimately this introduced a significant amount of code to deal with shortcomings of
dojo/store/Observable. dstore 1.0 introduces a new
Trackable mixin that is the evolution of
dstore/Trackable allows dgrid to stay in sync with all store updates much more easily.
Because of improvements dstore provides over the Dojo object store API, dgrid 0.4 no longer supports the Dojo store API. Take a look at the Using Grids and Stores tutorial to see dgrid and dstore in action together.
Pulling the plug on plugins
Column plugins provided an extremely useful and expressive way to add functionality to a grid’s columns, but some people found them a bit confusing to use, and they tend to be very difficult to extend. We decided to convert the column plugins from decorator functions to
declare mixins. Mixins are a familiar concept that are not only easy to use, but also easy to extend. Now you have the option to customize the column mixins as you do with any other dgrid component.
Inching towards the future
dgrid 0.4 is a few pounds lighter because we dropped support for IE 6, IE 7, quirks mode, and Dojo 1.7. dstore was designed for Dojo 1.8 and above, so dgrid 0.4 inherits this dependency. We’ve also removed old dgrid APIs which were already marked as deprecated during the 0.3 line.
Intern 2: dgrid has used the Intern as its testing stack for over a year. For 0.4, we’ve updated its tests to work with Intern 2, to continue to benefit from future fixes and enhancements.
Bower: dgrid 0.4 also includes a
bower.json, as we’ve received numerous requests for better bower support. Now you can use bower to install dgrid along with its dependencies in one command.
Step into the Laboratory
One thing dgrid lacked was a sandbox providing a comprehensive demonstration of its features. We’ve put together the dgrid Laboratory to help fill that void. Take it for a spin, and feel free to have a look at the code, too – it’s included in the dgrid repository!
Migrate on over to dgrid 0.4
Unfortunately, this dgrid release is not plug-and-play for everyone due to the extent of the valuable updates that we made. If you are using a Dojo object store or one of the column plugins, you will need to make some changes to your code when you upgrade to dgrid 0.4.
The good news is the changes are pretty straightforward, and the even better news is we have written a dgrid 0.4 Migration Guide to help you out.
For more details about the changes made in dgrid 0.4, please take a look at the dgrid 0.4 release notes. If you have questions or think you’ve found a bug, you can find links to the appropriate resources in the dgrid README.
Dojo has long distinguished itself with a robust and complete application architecture. And the foundation of this architecture has been the store interface, providing clean separation and consistent interface between presentation and data sources. We are committed to continuing to improve this architecture, and in this pursuit, we now releasing dstore, a next generation object store interface and set of data modeling components.
dstore is an exciting new package that provides a number of significant improvements over the prior data store framework, including a more fluent querying API, improved event notification, advanced cross-store filtering, and a more modular mixin system that allows us to easily combine components with alternate format support, advanced querying support, and more. In this post, we want take a brief look at these new features and improvements. From there, you can explore the tutorials and documentation that we have written for this new package.