[dojo-contributors] Dojo 1.7 Goals: has() and granular dependency lists

Rawld Gill rgill at altoviso.com
Mon Mar 14 14:41:05 EDT 2011


I'm working on the 1.7 bootstrap (as discussed at the 2 Mar meeting) and this 
work addresses some of the goals Kris outlined. I'll try to get something for 
everybody to look at by the next meeting [i've been pulled away from this work 
with another issue, but still hopeful on this timetable].

I'll give an outline of this work below. You'll see that there are lots of 
design decision points.  My idea here is to get something working and then we 
can debate any critical decision points and modify code accordingly. I'm using 
my best judgment at each point, but *not* saying "this is the way it will be".

Here are the main points of the design/impl:

Bootstrap:
Today, we have a single bootstrap, dojo.js, that is used for various 
environments (browser, rhino, etc.). This will be replaced with environment-
specific bootstraps. We can decide the names later, but, for example:

  1. dojo.js: generic browser hosted dojo that includes AMD loader and back 
compat layer to sync load via dojo.provide/require.

  2. main-browser: generic browser hosted dojo that can be loaded by any AMD 
loader; I'll ensure that RequiresJs and bdLoad work.

  3. main-node: node-hosted dojo that can be loaded by AMD loader in node.

  4. etc.

Granularity: (this dovetails with Kris's goals)
Today, the boot sequence includes lots of functionality that is not possible 
to exclude. The big ones are the sync loader, DOMContentLoaded 
detection/processing, unload detection/processing, and browser sniffing. But 
there's also small stuff like console guarantee, OpenAjax registration, etc. 
Each chunk of functionality must be bracketed in a way that it can be 
excluded. There are three ways to bracket code:

  * pragmas--I want to avoid these
  * has.js
  * separate AMD module 

I am refactoring (dojo.js, bootstrap.js, hostenv_*.js, loader.js) into four 
modules:
  * dojo bootstrap
  * browser sniffing
  * DOMContentLoaded detection/processing
  * unload detection/processing

Smaller things like console guarantee are bracketed by has.js; e.g.

if(!has("dojo-guarantee-console")){
  //etc.
}

My overarching design goal here is to refactor orthogonal features into 
independent modules.

has.js:
I'm using has.js throughout the new bootstrap, and there are lots of design 
points to debate with has.js--I've had several with myself :) That said, 
here's my current plan.

The module dojo/has will implement has, that is, the function has and its 
methods, *not* the feature tests. The implementation is taken from the has.js 
project with the exception of the obvious things like the lengthy DOM test 
that is not needed for a browser-only application. I'll also provide an 
alternate module that simply aliases a preexisting global has.

The has.js feature tests are copied into a directory and made AMD loadable. 
(Basically what Kris has already done, but, unconditionally AMD modules).

An additional feature test module is included, namely "dojo", for things like 
"dojo-guarantee-console".

The *source version* unconditionally loads many of the has feature test 
modules (I haven't figured out which ones yet). This makes it easy to write 
code using has.js...the feature test is already loaded.

Built version of dojo and/or apps will...

  * discard all unused has feature tests
  * aggregate all feature tests into a single module
  * discard all build-time-known has applications and fold code accordingly
  * (optionally) rename the lengthy has feature names to use integers

The key benefits of this design:

  * minimizes complexity writing code (the test is already there; just use it)
  * minimizes size for release code (no unused tests are included)

Back compat to sync mode:
We need to support dojo.provide/require for the 1.x line. *Please* correct me 
if I'm wrong, dropping this support would make things better.

Therefore, optionally but by default, dojo boot will include a new impl of 
dojo.provide/require that will slip the loader into and out of sync mode and 
be 100% compatible with the current impl of these functions. In short, 1.6 
simulated AMD; 1.7 will simulate dojo.provide/require.

You can see there are lots of moving parts. I've done this a couple of times 
before (sans has.js) with my dojo-sie project, so I think it can be done.

Best,
Rawld





On Friday 11 March 2011 07:10:06 Kris Zyp wrote:
> There are a couple of additional overarching goals that I would like to
> see pursued in 1.7. First, we should start using the has() pattern for
> feature detection branching in our code. Here is the ticket for (and
> explaining) this enhancement:
> http://bugs.dojotoolkit.org/ticket/12431
> 
> Second, as our AMD support will be improved in 1.7, we should start
> using more precise dependency lists to facilitate highly optimized
> builds (only what is needed) and fewer runtime property lookups:
> http://bugs.dojotoolkit.org/ticket/12432
> 
> I don't think the entirety of the Dojo codebase necessarily needs to be
> upgraded to these two coding improvements, but we should try to perform
> these upgrades when possible on code that is actively maintained or
> developed, or heavily used modules.
> 
> Also, if anyone is interested here is patch for adding a module for
> supporting native JSON parsing (using the techniques listed above):
> http://bugs.dojotoolkit.org/ticket/8111
> <http://bugs.dojotoolkit.org/ticket/8111#comment:22>
> 
> Thanks,
> Kris


More information about the dojo-contributors mailing list