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!
The best place to read about what’s new is in the release notes, but here’s a run-down of the most important parts.
Removal of extra dependencies
dgrid has shed its dependencies on put-selector and xstyle, opting instead to rely on Dojo’s
dom-construct module and simply bundle all components’ structural styles together into
dgrid/css/dgrid.css by default. As an end-user developer, this means you’ll now need to load
dgrid.css explicitly via
link tag or
@import, since xstyle won’t be around to load it for you with its
However, this also means you now have two fewer packages to install and include in builds (though of course only the modules your application actually depends upon would be loaded at runtime regardless). It also potentially simplifies builds as far as CSS is concerned, since you don’t need to account for optimizing the structural CSS that was being dynamically loaded by xstyle’s
css AMD plugin.
Reorganization of CSS using Stylus
A natural follow-up to the removal of xstyle was to organize the CSS using the Stylus preprocessor, which we’ve been successfully using in projects for the last few years. This provides benefits for both structural styles and skins.
While the structural styles for all components are included in
dgrid.css by default, they’re still organized by component in Stylus, so if your project also uses Stylus, it’s possible to import dgrid styles directly for just the components you use.
Where the use of Stylus really shines, though, is in the refactoring of the styles for dgrid skins. All skins now operate by defining a series of variables, then call a common
skin.styl which outputs a set of dgrid styles based on the variables that are set. (They can optionally apply further customizations after importing
skin.styl as well.) Now you can create a custom dgrid skin using Stylus in a snap!
Dojo 1.11 is also introducing a new flat theme, including support for this new dgrid skin structure.
More information is available in the documentation. You can also see the variables used in the existing skins to get a feel for how it works.
Goodbye, IE 8; Hello, Intern 3
Many Web developers thought IE 8 was effectively dead last year when Microsoft ended support for Windows XP. Another nail is about to be put in the coffin when Microsoft drops support for all but the most recent version of IE on each supported OS. As such, we’ve decided it’s time to move on, and we don’t plan to spend any more time supporting IE 8. We’ve also updated dgrid to use Intern 3 for testing, which doesn’t support IE 8 either.
That being said, we haven’t yet dropped existing IE 8 considerations from dgrid, so it should continue to work as well as it has in the past.
But wait, there’s more!
The release of dgrid 1.0 is accompanied by several related releases:
- dgrid 0.4.1 contains all of the fixes that went into 1.0, without the new features, for those not yet ready to make the jump (though upgrading from 0.4 to 1.0 should be very simple).
- dstore 1.1.1 and 1.0.3 contain API fixes complementing some of the cleanup performed in dgrid 1.0 and 0.4.1.
In order to upgrade to either of the new releases of dgrid, you should upgrade to one of the new releases of dstore as well.
What else is in store?
dgrid 1.0 is mostly a stability and clean-up release from 0.4. dgrid is already used in plenty of production Web applications, and in our experience it is more robust and efficient than other grid components we’ve had experience with, some of which are already well past 1.0.
We did originally plan on additional refactoring prior to 1.0, but we’ve made reasonable progress with the time we’ve had, given that we’ve also been busy starting on Dojo 2. So in many ways the 1.0 release signifies that we’re starting to think about 2.0!
As such, we have begun to think about how dgrid will fit into the big picture of Dojo 2’s renewed stories around object composition and data management. dgrid 2.0 will almost certainly be a rewrite, given that it will be written in TypeScript, against Dojo 2’s APIs. We of course intend to inherit as much functionality from dgrid 1.0 as is reasonable, but it may be organized differently, in an attempt to improve maintainability, better accommodate edge cases when components interact, and also reduce the amount of code loaded depending on what components you use.
We’ve also heard several users express interest in being able to use dgrid within frameworks such as Angular and React. Technically there’s nothing outright preventing this today, other than that code would need to be written to facilitate easily creating and configuring instances without needing to dig into details specific to dgrid’s end (such as AMD loader configuration and use of
declare), and that you would need to create a streamlined build of Dojo 1.x to include within your non-Dojo application. Given the demand, we expect to be giving this some thought in the near future: what would be useful in the way of adapters, facilitating distribution of a version of dgrid with dependencies included that you can easily drop in, and whether there’s anything else that can be done on dgrid’s end to improve the experience for non-Dojo users of dgrid.
We encourage everyone currently using dgrid 0.4 to try out 1.0, as it should be a relatively easy upgrade. For users still on 0.3, we would highly recommend reading the 0.4 release notes and migration guide first, as all of its information is equally applicable for an upgrade straight from 0.3 to 1.0.
If you’re not quite ready to jump to 1.0, at the very least we would suggest upgrading to 0.4.1 for the many fixes it provides, without the breaking changes.