Dojo FAQ: Why is there an underscore before some module names?

By on November 5, 2013 11:51 am

In general, Dojo uses the following naming conventions:

  • _UpperCamelCase: mixin classes/modules
  • UpperCamelCase: base classes or constructors to instantiate
  • _lowerCamelCase: private/protected vars, or internal methods that may change between point releases (not typically used for a module name)
  • lowerCamelCase: singletons (or normal methods when used within a module)
  • _base: modules that were historically included in the default Dojo base build


Dojo provides a powerful inheritance mechanism with the dojo/_base/declare module, including most of the benefits of multiple inheritance with the mixin pattern. Dojo has adopted, and encourages the convention of, prefixing mix-in module names with an underscore to make it clear that these modules should only be used as mixins, not used stand-alone (do: instantiate dijit/Dialog directly; don’t: instantiate dijit/_DialogMixin directly).

What about dojo/_base?

The modules under dojo/_base have a special history. Prior to Dojo 1.7, Dojo’s had not adopted AMD as its module format, because it did not yet exist. If you loaded dojo.js, you automatically had access to all the “base” modules directly on the dojo global. If you wanted to use other methods, such as, or dojo.cookie, you had to explicitly load them first. With the transition in 1.7 to full AMD support, when you load dojo.js in 1.7+, you now have a “baseless” dojo – the modules in dojo/_base are not automatically available – they must be explicitly loaded. So the underscore in “_base” doesn’t indicate anything special anymore – it’s part of a legacy naming scheme that made sense before Dojo adopted AMD.

In Closing

When used appropriately, mixins provide very powerful and flexible composition opportunities. If you look in the Dijit source code, you will see many mixins – you should strive to understand these, as many of them are very useful when developing your own custom modules. If you find yourself thinking, “I like this widget, but it doesn’t quite work like I want, I need to customize it to work the way I want” — look at the module’s source! It may be composed of a handful of mixins that you can use as the basis for your own module, allowing you to customize it perfectly to fit your needs while easily inheriting extensive functionality.