Modules and dependencies known before the load

Matthew Robb matthewwrobb at gmail.com
Fri Aug 15 06:58:26 PDT 2014


Let me clarify that when I suggest a mechanism for execution phase I am
really asking for a loader hook that could allow user code to enable such a
thing. Not asking that it be built into the loader spec.


- Matthew Robb


On Fri, Aug 15, 2014 at 9:56 AM, Matthew Robb <matthewwrobb at gmail.com>
wrote:

> In YUI's Loader config you can set up hooks that specify another module
> that "triggers" this module. It's the reverse of a dependency. You may want
> to say that ModuleX should always be loaded before ModuleA-ModuleD. You
> might even want to create this dependency based on environment conditions.
> The common case here is polyfills but I have used it for other things as
> well.
>
> I am curious what the reasoning is to not provide a mechanism in the
> loader to allow the dependency graph to be adjusted in some manner? It
> seems reasonable to me that you should be able to add dependencies to a
> module at any time. These are not imported dependencies just load and
> potentially execution dependencies and it WOULD be great if this mechanism
> provided a model for specifying execution phase. Again similar to YUI's
> "before", "after", and "instead" values for the "when" property of its
> condition blocks in loader configuration.
>
>
> - Matthew Robb
>
>
> On Fri, Aug 15, 2014 at 9:27 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>
>>
>>> > 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
>> Loader.prototype.load.
>>
>>
>>>  >
>>> > 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.
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140815/657bfe16/attachment-0001.html>


More information about the es-discuss mailing list