Modules and dependencies found during the load (before instantiation)
johnjbarton at google.com
Mon Aug 18 13:32:48 PDT 2014
On Mon, Aug 18, 2014 at 10:55 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 13 Aug 2014, Ian Hickson wrote:
> > One of the problems I'm running into when it comes to trying to
> > integrate ES6 modules with HTML and new HTML-based dependency features
> > is the way that I can't tell ES about dependencies I know about before
> > the data is actually fetched and instantiated.
> Another example of where we have something like this is HTML imports. The
> "fetch" hook for HTML imports needs to actually be the hook that does all
> the parsing, since HTML loads incrementally. (For HTML imports, the
> "translate" and "instantiate" hooks are essentially no-ops.) This means
> that the in-band dependencies for HTML imports are found during the
> "fetch" hook, and need to be set up right away. For example, if an HTML
> import contains a <script type=module> block, that inline module needs to
> be added as dependency of the import itself (so that the import's 'load'
> event doesn't fire until all internal modules are loaded). It it contains
> an <img src=""> element, that needs to be added as a dependency as its
> loading. This is similar to the "instantiate" hook adding dependencies,
> except that it has to happen earlier due to the incremental parsing.
Can we explore the opposite question: how much does the HTML dependency
problem really overlap the ES dependency problem?
To the first approximation these are the same problem: given the root of
graph, load all of the nodes of the graph. The solution to this generic
problem is well known and the code, while not trivial, is not very complex.
As soon as we go beyond this first level, the problems diverge. In fact I
think your posts make the case that the character of these problems differ
on so many points that code reuse is unlikely and algorithm reuse unwise.
In particular the reason we -- 'we' being you and me -- can't understand
the ES spec is (evidently) that it supports loading a graph of mixed nodes
(ES and legacy) with different assumptions about circular references. HTML
is unlikely to have the identical requirements on circular references and
it's legacy (script tags, document.write, mutable declarations, HTML
imports) has quite different issues.
It seems to me that a better design for HTML dependency loading would
integrate with the ES Loader rather than attempt to mutate it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss