Modules and dependencies known before the load

Kevin Smith zenparsing at
Fri Aug 15 06:27:17 PDT 2014

> > The structure of the graph has an effect on order-of-execution, though,
> > so adding edges can result in observable changes.
> Can you elaborate on this, just so I'm sure I understand it right?
The execution order is determined by a depth-first traversal of the
dependency graph starting with the node being loaded, where edges are
ordered.  So adding edges can have an effect on the traversal ordering.
 Execution order is in general not fixed, though, since the user can
initiate loads of different parts of the graph at arbitrary times.  Just
something to consider.

> > 2) The ability to prefetch resources, given a URL which is currently
> > loading.

As Juan pointed out (and I forgot) this can be done with

> >
> > For example, the user might want to specify up-front a portion of the
> > dependency graph so that resources in that graph can be downloaded in
> > parallel.
> Isn't that just something you can do one you have (1)? I'm not sure I'm
> following the distinction.

I think there's an important distinction here.  Let's say that you have
this dependency chain:

    A -> B -> C

So A depends on both B and C.

Let's say that the user has declaratively indicated that A also depends on
some other resource D, but A doesn't *actually* depend on D.  How should
things be modeled in that case?  Would it make sense to add an edge from A
to D?

If D is an "actual" dependency, then you would want to execute/initialize
it before A.  On the other hand, if it's just a "likely" dependency, then
you might want to load it (and it's dependencies) without initializing it,
using `Loader.prototype.load`, or perhaps some other mechanism.
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list