Integrating the Webs' dependency systems

Juan Ignacio Dopazo jdopazo at yahoo-inc.com
Thu May 29 16:03:13 PDT 2014




On Thursday, May 29, 2014 6:31 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>
>On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
>> >
>> > - some people want to predeclare a bunch of scripts and their 
>> >   dependencies, without actually downloading any of them ahead of time, 
>> >   and then later, when they're needed, have the entire tree downloaded 
>> >   all at once. 
>> 
>> At the moment we're doing this by running static analysis tools on the 
>> ES6 modules and using the information from the dependency tree to know 
>> how to download all of them at once.
>
>
>Right, it's relatively common for people to do this. Not just for scripts, 
>indeed, but also for style sheets and other resources. Ideally the browser 
>would take care of this logic for the author.
Yes. The author would still have to provide the dependency tree upfront (I wrote this for exactly this use case https://www.npmjs.org/package/module-graph) , but it's something that would be nice if the browser Loader did.
  
> > - sometimes, even a file that is not downloaded immediately upon being 
>> >   referenced by another file might still want to be precached, so that 
>> >   when it _is_ needed, it's already locally available
>> 
>> The Loader object is actually a dictionary, so it acts as its own cache. 
>> You can call loader.fetch() yourself without the module being executed 
>> in order to cache it.
>
>
>The idea here is that the browser would be able to determine when it's 
>best to preload the file; the author would just want to tell the UA that 
>the file is something worth precaching, not actually do it.

I think this would get along well with the <module> tag. If the browser had an attribute that said if any remote resource (images, stylesheets, modules) may be preloaded, then it would just have to hook into loader.fetch() to tell the ES Loader that it already started preloading the module.

> > I'm having difficulty understanding the spec for the instantiate hook. 
>> > Does it get called before the fetch hook? Is there some way to 
>> > dynamically add dependencies later?
>>
>> The lifecycle of a module request is normalize -> locate -> fetch -> 
>> translate -> instantiate. Instantiate doesn't actually execute anything 
>> until all of the dependencies have gone through the same 5 steps.
>
>
>
>
>Aha, ok.
>
>
>Is there a way to add dependencies before the "fetch" hook is called?


Not without jumping through some hoops. But the dependencies aren't really what matter at the "fetch" stage. You can fetch other resources, which will generate internal LoadRecords for them, without specifying they're dependencies.


When is the "fetch" hook called in the current ES6 logic? As soon as 
>"locate" provides a URL?
Yes. It's promise based though. "locate" may even take time (we're using this to do the opposite of prefetching: generate a single HTTP request from multiple imports).


Juan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140529/a66a8c98/attachment-0001.html>


More information about the es-discuss mailing list