Changing dependencies
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 parsing for dependents.
jjb
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 my life a lot easier, since I could maintain all the dependency information outside of the Web's default Loader, without having to worry about browsers having to implement duplicate logic. So if I have indeed misinterpreted the spec to that extent, that would be very good to know!)
On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson <ian at 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]] list?
The dependencies for the Load. Once the load is complete the record is not needed.
To be sure this is based on my old implementation experience. But as you say the modules are static so the dependency info is not useful after the load.
jjb
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 change a style sheet's dependencies.
Assuming we are implementing all CSS loads through the ES6 module loader system, what's the appropriate way in which I should spec reactions to changes to a CSS object's @import rules?