Dojo 2 updates – Week ending Jan. 27, 2017

Over the past few weeks, we’ve been working on several large improvements to widget authoring and theming with Dojo 2.


We’re currently using css-modules and css-next via PostCSS, a powerful tool for transforming CSS with JavaScript. css-next enables us to just write vanilla CSS with vendor prefixing done automatically, so there’s no need to learn the separate syntax of a CSS pre-processor such as SASS, LESS, or Stylus, just the new semantics of CSS.

This gives us several primary benefits for how themes are applied to widgets within Dojo 2:

  • Local scoping by default and obfuscated class names prevent class name collisions across widgets and from top level CSS rules
  • Full autocomplete/Intellisense for widget authoring, which extends to how CSS class names are specified. Only the locally scoped widget class names are available, which is very powerful
  • Users can import fully supported Dojo 2 theme variables into their custom widgets
  • CSS authoring is fully built into the Dojo 2 cli

Overall we believe this will provide a complete end-to-end authoring experience that makes theming much easier for TypeScript developers.

This work has either landed in master or is currently under review as PRs.

Simplifying widget state and property handling

Via our widget API, we promote the reactive principles of “properties in, events out”. By default, Dojo 2 widgets are stateless. Widgets are passed properties and implement a render function. Through refactoring to reduce and simplify the surface area of widgets, we have removed state from the widget API. This simplifies the authoring experience of widgets, leaving us with a very simple public API for widgets: `render` and `diffProperties`. Both functions have sensible default implementations.

We also provide capabilities for more advanced widget authoring, such as diff-ing single properties if needed, and adding behavioral traits via functional composition.

Usage of Dojo 2 widgets is documented in the widget-core readme.

Web components

Beyond our usage of Custom Elements for all Dojo 2 widgets, we have been working on support for making any Dojo 2 widget easy to export as a web component to use within other environments that support web components. While a web component will not have all of the benefits of using a widget inside a Dojo 2 environment, this will make it much easier to include a Dojo 2 widget within a non-Dojo application. For example, say you want to make dgrid available for use in non-Dojo applications? This will now be much easier to do with Dojo 2 widgets.

Initial support for web component utilities landed recently in widget-core. Support for exporting a single widget as a web component, and installing via npm, is currently under development.

Dojo 2 roadmap

As January draws to a close, we’re continuing updates on the Dojo 2 roadmap.

8 thoughts on “Dojo 2 updates – Week ending Jan. 27, 2017

  1. Hello Dylan,

    According to you, what is the percentage of rework to be done to migrate any dojo application from 1.11 to 2.0.


    1. Somewhere between 0 and 100%. I say that only half-joking. Both Dojo 1 and Dojo 2 are fundamentally things that act on JavaScript code.

      However, since Dojo 1.x was conceived, we’ve seen the following:
      * ES5, ES6, ES7, etc.
      * TypeScript
      * Mobile
      * Reduction in market share of IE6-8
      * HTML5
      * etc.

      In particular, ES6 and removal of IE6-8 from consideration allow a very different and more efficient way of building applications than was possible before.

      So, if you want to leverage all the new stuff, it’s a rewrite, though many of the concepts should be very familiar. Or, if you want to do things gradually, you can start adding Dojo 2 packages into a Dojo 1.x app, and migrate slowly over time.

      But to get the best of the modern world of JS and TS, you’ll probably find yourself over time rewriting everything, because so much of the language has changed over the past few years.

  2. are all dijit widgets going to be migrated to Dojo 2 ?. are is it just a framework just like angular 2?

  3. HI Dylan

    I know this is not a place to ask but does dojo has support like controller to attach to a parent div

    and user that controller point to target only the underneath elements

    like then a javascript file that only servers “point” and items below that. like in angular $scope.fuction() or $scope.variable

    it would be very useful, so that i dont get bothered when accessing dynamic tabcontentpane (tabs that get added dynamically )

    thanks in advance

    1. For tabs specifically, there are parent/child APIs (and with most container based widgets). There’s a widget registry, and a number of other things.

      It’s not done the way Angular is, but I think the Dojo approach is actually easier to work with.

      Dojo 2 does this quite a bit differently, but given that you’re using Dojo 1.x I don’t want to confuse matters.

      1. well i am doing it this way inside a content pane and am sure its not a clean way

        alert(“this event is from “+this.getParent().id+” components “);
        var parentID = this.getParent().id;
        require([‘dojo/query’,’dojo/on’,’dojo/ready’,’dijit/registry’],function(query,on, ready, registry){
        var button = query(“.dijitButtonContents”,parentID);
        var selectBox = registry.byNode(query(‘.myOption’,parentID)[0]);
        console.log(“Parent Node-> “+parentID);

        PRESS ME

        but if dojo has a controller think i can attach to a specific block i can just write all my events inside a separate file.

        1. Hi Serak, this is a bit of a confusing approach with a mix of pre-AMD and post-AMD APIs (e.g. use of dojo.hitch)… there’s definitely better ways to do this, but really I’d need to see a more complete example somewhere like JSFiddle where I can provide more detailed feedback?

Leave a Reply

Your email address will not be published. Required fields are marked *