On Fri, Aug 15, 2014 at 2:43 PM, Ian Hickson wrote:
> On Fri, 15 Aug 2014, John Barton wrote:
> > On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson wrote:
> > > On Thu, 14 Aug 2014, John Barton wrote:
> > > >
> > > > But since the only way the client can know that it needs a.js and
> > > > jquery.js
On Fri, 15 Aug 2014, John Barton wrote:
> On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson wrote:
> > On Thu, 14 Aug 2014, John Barton wrote:
> > >
> > > But since the only way the client can know that it needs a.js and
> > > jquery.js is if the server tells it [...]
> >
> > There's at least four way
>
>
> I think it would be reasonable for us to say that all the dependency
> declaration mechanisms are equivalent in that they all cause the target
> dependency to be "executed" (whatever that means in the context).
OK. The "instantiate" hook allows you to specify arbitrary dependencies,
but on
On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson wrote:
> On Thu, 14 Aug 2014, John Barton wrote:
> >
> > But since the only way the client can know that it needs a.js and
> > jquery.js is if the server tells it [...]
>
> There's at least four ways this can happen:
>
> - the server tells the browser
On Fri, 15 Aug 2014, Kevin Smith wrote:
> >
> > 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 a
On Thu, 14 Aug 2014, John Barton wrote:
>
> But since the only way the client can know that it needs a.js and
> jquery.js is if the server tells it [...]
There's at least four ways this can happen:
- the server tells the browser that it needs file a.js when the server is
sending index.html
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
wrote:
> In YUI's Loader co
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
>
>
> > 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 start
On Thu, Aug 14, 2014 at 2:20 PM, Ian Hickson wrote:
> On Wed, 13 Aug 2014, John Barton wrote:
> > On Wed, Aug 13, 2014 at 3:52 PM, Ian Hickson wrote:
> > > On Wed, 13 Aug 2014, John Barton wrote:
> > > > On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson wrote:
> > > > >
> > > > > Suppose a page has
On Wed, 13 Aug 2014, John Barton wrote:
> On Wed, Aug 13, 2014 at 3:52 PM, Ian Hickson wrote:
> > On Wed, 13 Aug 2014, John Barton wrote:
> > > On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson wrote:
> > > >
> > > > Suppose a page has this markup:
> > > >
> > > >
> > > > > > > whenneeded>
> >
>
> For prefetching we're calling LoadModule() for all the dependencies we
> want to prefetch in the Fetch or Locate hooks.
>
Ah - just saw this - cool.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
>
>
> If I understand what you're saying correctly, then yes (assuming that
> those dependencies are also acted upon promptly, rather than only after
> "fetch" has returned).
>
I see two related abilities here, and I'm not quite sure if you want one of
them or both:
1) The ability to add nodes (a
For prefetching we're calling LoadModule() for all the dependencies we want to
prefetch in the Fetch or Locate hooks.
For example, Systemjs has a System.depCache option which allows you to define
dependencies ahead of time. Here's the hook implementation:
https://github.com/systemjs/systemjs/blo
On Wed, Aug 13, 2014 at 3:52 PM, Ian Hickson wrote:
> On Wed, 13 Aug 2014, John Barton wrote:
> > On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson wrote:
> > >
> > > Suppose a page has this markup:
> > >
> > >
> > > whenneeded>
> > >
> > > import "a";
> > > // ...
> > >
> >
>
On Wed, 13 Aug 2014, Kevin Smith wrote:
> >
> > Ideally I think we should adjust the ES6 module system to support
> > loading and compiling code (though not necessarily executing it) for
> > dependencies at or around the "fetch" hook.
>
> It seems like it should be possible, in principle, to add
>
>
> Ideally I think we should adjust the ES6 module system to support loading
> and compiling code (though not necessarily executing it) for dependencies
> at or around the "fetch" hook.
>
It seems like it should be possible, in principle, to add dependencies to a
load record at any time prior t
On Wed, 13 Aug 2014, John Barton wrote:
> On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson wrote:
> >
> > Suppose a page has this markup:
> >
> >
> >
> >
> > import "a";
> > // ...
> >
>
> Your example will just work if you just use
>
>
> import "a";
> // ...
>
Your example will just work if you just use
import "a";
// ...
When this module is compiled the other two will be loaded and compiled.
jjb
On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson wrote:
>
> One of the problems I'm running into when it comes to trying to integrate
> ES6 modu
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. The problem can essentially be
summarised
20 matches
Mail list logo
