Looking Ahead to dgrid 0.4

By on April 29, 2014 10:22 am

dgrid, SitePen’s next-generation Dojo data grid, has been serving many users’ needs for over two years. Over that time, we have been steadily adding extensions, making improvements, and addressing issues. However, the process of reporting and fixing defects becomes an endless cycle — one we’ve arguably already been stuck in long enough — and it’s time to set our sights higher for the long run.

With that in mind, we’ve planned a couple of major changes for dgrid 0.4. While they’re not shiny new features, they are significant refactoring efforts that we have decided to undertake based on common pain points observed with dgrid 0.3. These efforts should result in a more stable and extensible code base, which will benefit dgrid’s users and ease the overhead on its maintainers, allowing us to set our sights higher in the future.

The Fate of Column Plugins

dgrid currently has a concept of column plugins, which are functions used to decorate a column definition object to add functionality to that column’s cells, such as editing capabilities, discrete row selection controls, or tree expansion. This pattern is distinct from the mixin pattern in that declare is not involved, and the target is a specific column rather than the entire grid.

While on the surface the column plugin API seems expressive, it can be awkward to implement. The editor and tree column plugins add methods to the grid instance to allow programmatic activation/expansion, which needs to be done via AOP using a reference to the grid automatically stored on the column definition, and initialization/cleanup can be tricky. Moreover, the functional style of column plugins quickly leads to extensibility issues, as it is easy to end up with large amounts of logic buried in a closure that is inaccessible to code wishing to extend it.

Due to these implementation-related issues, we have decided to convert dgrid’s column plugins to mixins. We have already converted selector, and the results have been encouraging. The code is easier to follow, and the conversion immediately resolved a couple of initialization/cleanup issues we had previously spotted, without any additional effort. We’re currently in the midst of converting editor, and will be converting tree once that is done.

An additional benefit to converting the column plugins to mixins is that users only need to learn one paradigm. We saw several cases where users attempted to mix column plugins into constructors using declare, which could cause unexpected problems.

What’s in Store for 0.4

dgrid currently uses the dojo/store API for its data interaction, which generally lends itself to simple and easy-to-use code. However, dgrid’s OnDemandList and OnDemandGrid components have brought some significant edge cases to light, largely involving dojo/store/Observable and paged query results. dgrid 0.3.13 largely worked around these limitations, but ideally these pain points could be resolved outside of dgrid, on the store end.

These issues, as well as others, have led SitePen to design and develop the next evolution of the dojo/store API. dgrid 0.4 will support this new API and will remove support for dojo/store in order to keep the code base manageable. The new store API will include adapters for the dojo/store API, making it possible to continue using existing stores when upgrading to dgrid 0.4.

We’ll be talking in depth about the new store API soon, so stay tuned!

What about shiny new things?

Since we found existing areas of dgrid that warrant significant improvement, our focus isn’t on adding new modules at the moment. However, we recognize that there are a number of common scenarios for which dgrid lacks an out-of-the-box solution. This is often intentional, as many of these scenarios don’t have one right answer. Rather than quickly adding an extension that pleases only a fraction of our users, or working far too long on an overly-generic solution, we decided to focus on creating more tutorials that cover these types of situations. We added two last month, discussing rendering all store data at once and making the grid adjust its height automatically, and rendering a summary row in the grid’s footer. Check them out if you haven’t already! We’ve got ideas for more that we’ll be adding in the coming months.


Work is already well under way towards the major changes for dgrid 0.4, and we hope to finish it up within the next few months. If you’ve got questions about dgrid, remember to check out the mailing list or #dojo on irc.freenode.net.