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
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
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 matthewwr...@gmail.com
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,
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 an
On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson i...@hixie.ch 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
Hello again,
I'm looking at what the default behaviour of the Web's normalize hook
should be. I've read through the links people have posted about this
before, e.g. [1], but they tend to focus on the behaviour for sensible
inputs and ES6-only inputs, so I'm not sure the following cases are
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 only if
On Fri, 15 Aug 2014, John Barton wrote:
On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson i...@hixie.ch 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
Suppose you have an HTML import foo.html that declares two modules:
script type=module id=a ... /script
script type=module id=b ... /script
How should they refer to each other? For example, if module id=b wants to
import module id=a? I suppose the logical way is like this:
import #a;
On Fri, Aug 15, 2014 at 2:43 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 14 Aug 2014, John Barton wrote:
But since the only way the client can know that it needs a.js and
ES6 modules are immutable, but some things on the Web platform that might
have dependencies can have those dependencies change over time. For
example, CSS style sheets have a mutable object model, and one of the
things in that object model is their list of @imports, so you can
dynamically
Was just going through updating @esdiscuss when I noticed nobody really
answered this thread. Which is lame.
The meeting notes at [1] are hard to interpret given that the slides are still
MIA (Dave?). But essentially, import-into-namespace syntax is now `import * as
x from y`, replacing the
The ES Loader does not maintain a dependency tree. It maintains a table of
names-modules. So when the @import rules mutate, just load the new names.
Any new modules will be traversed for dependents and new name-modules
entries will be created. Well, assuming you figure out how to integrate CSS
On Fri, 15 Aug 2014, John Barton wrote:
The ES Loader does not maintain a dependency tree. It maintains a table of
names-modules.
Maybe I'm misunderstanding the ES6 loader spec. What's the Load Record
[[Dependencies]] list?
(If ES6 isn't maintaining the dependency tree, then this would make
On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 15 Aug 2014, John Barton wrote:
The ES Loader does not maintain a dependency tree. It maintains a table
of
names-modules.
Maybe I'm misunderstanding the ES6 loader spec. What's the Load Record
[[Dependencies]]
Thanks, Domenic. Very helpful!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Aug 15, 2014 at 3:06 PM, Ian Hickson i...@hixie.ch wrote:
Suppose you have an HTML import foo.html that declares two modules:
script type=module id=a ... /script
script type=module id=b ... /script
As we noted in another thread, Web devs no longer control servers. And
servers
18 matches
Mail list logo
