Dojo FAQ: Why doesn’t Dijit recognize my dgrid instances?

By on March 5, 2014 8:56 am


SitePen’s next-generation grid component, dgrid, is designed to be modular and lightweight, allowing you to only load what you need. It has been designed to work well in Dijit-based UIs, but functionality specific to interacting with Dijit is provided in a module that is not loaded by default. Without this module, two common problems often occur:

  • The dijit/registry module will not find dgrid based on its ID
  • The grid will not size correctly when placed inside a layout container widget, such as dijit/layout/BorderContainer

Both problems stem from the fact that while dgrid’s API is compatible with Dijit, it is not in fact a Dijit widget at its core. Dijit layout containers depend on Dijit’s registry to identify their children, and the Dijit registry is of course designed to locate only Dijit widgets, not arbitrary HTML elements.

You can resolve these problems by mixing the dgrid/extensions/DijitRegistry module into your grid:

], function (declare, OnDemandGrid, DijitRegistry) {
    var grid = new (declare([OnDemandGrid, DijitRegistry]))({
        store: myStore,
        columns: myColumns
    }, 'grid');

The dgrid/extensions/DijitRegistry module adds and removes dgrid instances from the Dijit registry upon creation and destruction, and also contains considerations for various Dijit layout widgets, including a special resize implementation.

Learning more

If you’d like to learn more about dgrid, a number of tutorials are available on, and additional information on each of dgrid’s components is available in the project’s wiki. We also cover Dijit and dgrid extensively in our Dojo 201 Workshop.


  • Deepak Anand

    This is useful to know.. But I am curious to know why Dgrid is not a Dijit widget. Was that because the Dijit infrastructure does not scale to complex widgets i.e. complex model/data, nested widgets etc ? Or maybe Dgrid came before Dijit ?

  • dgrid came after Dijit but before AMD which is the main reason. The idea was to implement the same lifecycle as Dijit, but to make dgrid as small as possible so we didn’t have to include all of Dojo and dgrid to make it work.. Also, we were first starting to think about how Dijit could be simplified for Dojo 2 (though we’ve gone much further since then). Some of our older articles such as , , and talk about some of the considerations.

    That said, if you include all of Dijit in your app already, then the extra cost to make dgrid a Dijit is minimal, hence the extension.

  • Deepak Anand

    Appreciate the quick response. thats good to know.
    Do you have any additional thoughts around using the Dijit framework to create complex widgets such as dgrid … are there more things to consider from a widget author point-of-view ?

  • The short answer is yes.

    We spend about half a day covering concepts for creating widgets in our Dojo 201 workshop ( ). Some of these details appear in various blog posts on SitePen, but our Dojo 201 and 202 workshop series probably has our most comprehensive coverage of tips for building widgets.

  • Andrew Finnell

    The most frustrating part of dgrid NOT being a Dijit Widget is that you lose all MVC capabilities on the Grid’s. As the MVC functionality relies upon Stateful and value existing on _WidgetBase you cannot bind a model which contains data to a grid. It blows my mind that this much effort has been put into the MVC binding framework and it’s incompatible with Grid because Grid is not a Widget. The DijitRegistry does not make Grid a Widget but only simulates enough of what’s needed to get it into the registry and started. It’s missing the binding capabilities. Quite sad that dgrid is used by so many yet was written as though dijit didn’t exist even though it did.

    Between dojo, dojox, dijit, dstore, and now dgrid it appears the designers rotate every 6 months and we end up with completely incoherent and half-bake features each release. This has all been a wonderful test in patience with Javascript debugging to figure out why something as simple and logical as data-dojo-props=”collection: at(‘rel:’, items)” will never work on a dgrid. There’s no reason why it shouldn’t be derived from _WidgetBase with collection internally bound to value.

  • Hi Andrew, Apologies for the frustrations we’ve caused you. The primary reason we originally went down this route was that _WidgetBase was, at the time, far too large for creating a performant mobile widget. We expected Dojo 2 to arrive a lot more expediently than it has, so we didn’t expect this length of divergence.

    One of the challenges we face is that we rarely receive and significant feedback on the things we create until after we release them. This invariably leads to work needing to be done after we release. While we do work hard to consider all scenarios, we tend to focus first on the things that we think of (which is probably obvious, but worth stating).

    That said, there is no reason this cannot be made to work with a bit of effort. The real answer is that dojox/mvc should be updated to not assume that everything worth tracking is a Dijit and/or exactly matches the syntax in _WidgetBase, but rather the mechanisms for tracking state should be configurable, as dgrid supports getters/setters in the same manner, just with a different syntax.

    We’ll see if we have an easy fix for that. My impression is that we would have fixed that years ago, but no one has asked, possibly because dojox/mvc is not the most widely used part of Dojo.

  • Andrew Finnell

    Thank you for the response. I whole heartedly agree about changing the assumptions that Dojo MVC makes. In a one way bind there is no reason the target property has to be Statefully nor ‘value.’ Perhaps it is something I’ll look into contributing unless there is another binding framework one could suggest.

    I’m not suprised more peope don’t use MVC, however, they should as to me IT is the view model framework. Perhaps others roll their own or setup all the binding in Javascript. However, declarative ought to beat programmatic everytime except it seems dojo as a community has stayed away from becoming like XAML or other declarative UI languages.

    I would love the chance to have a one on one with one of the designers regarding best practices when using dojo. There seems to be a split brain design. Once you start using HTML id’s on pages registry conflicts happen. So then we move to widgets for everything and use attach point. however, there are plenty of articles which claim Widgets should be used sparingly.

    So the derailment question for this thread is: How do you create a proper MVC application where there is ever one initial page loaded and everything else is loading dynamically.

    Creating a Dialog twice which uses href will cause errors if anything in the dialog is id’ed. It’s a catch 22 and I haven’t found a single article or paper that uses Dojo to create a full multi-view multi-document product. Any assistance would mean a great deal to me.

  • Let me start with the Dojo 1.x view of the world, and then move into the Dojo 2 view of the world.

    We had started to work on a better app framework for Dojo 1.x, in the form of an MVVM framework called Mayhem, , and the largest app we’ve seen built with it is at .

    That said, Mayhem is already out of date with the change, and we are currently focusing more of our efforts on getting Dojo 2 done. Even so, I think there are enough good things in there that would help you understand some of our thoughts around MV* architecture on top of Dojo 1.x.

    The challenge with MV* in a browser is that there are significant complications in syncing between the DOM and your data model, so the idea is to basically created a virtualized view (virtual dom) and synchronize with that in JS instead. With Dojo 1.x, to avoid id collisions, you would probably need something to manage UUIDs for widget instances.

    The concept of markup vs. programmatic is really that it’s nice to be able to pre-render the UI first, and then run your app in some scenarios. With Dojo 1, you could use _AttachMixin, which allows you to bind a widget instance to a DOM structure in page, rather than a separate template. The goal was to make them the same, but there have always been small differences between the two. With Dojo 2, the aim is to have markup and code follow the same code path wherever possible, though it will probably always be easier to express more complex concepts in code than in markup.

    In terms of how to create a proper MVC app in a browser, I think the answer is that because of the way DOM binding work, it needs adjustments. is a talk that we gave a few months ago that touches on this somewhat.

    With Dojo 2, we’re building state tracking, actions, stores, routing and more into the default approach to building apps, which itself has a robust way to track state and data that is probably closest to something like Redux.

    It’s still early, but you can see the progress on Dojo 2 at .

    We’d be happy to have a live chat with you about Dojo architecture, please feel free to reach out via our contact form to schedule a discussion with us.