On Wed, Jul 9, 2014 at 1:57 PM, Jussi Kalliokoski < jussi.kallioko...@gmail.com> wrote: ...
> I proposed (it was less of a proposal though, more an idea or an example > to spur better ideas) that we had a single dynamic exportable per each > module, and that could be an object, function, undefined for side effects > or anything. But, the important part was that it could also be a Promise of > what you want to export, allowing asynchronous module initialization. > > The use cases addressed include: > > * Optional dependencies (required for porting large amounts of existing > code to use ES6 modules). > * Async feature detection. > * Dependencies on things other than JS, such as stylesheets, images, > templates or configuration (e.g. a default language pack). > * Waiting on something to be ready, for example something like jQuery > could wait for DOM ready so that the API consumer doesn't have to. > > All of these can be done with the current design, however you cannot defer > the module being ready to be imported. So if you depend on these use cases, > you have to provide async APIs for things that are possibly synchronous > otherwise, not only imposing a performance penalty, but also a convenience > downer on the consumers of your API. > ... If I understand your question here, I think the current solution as adequate support for these cases. The current module loading solution mixes imperative and declarative specification of the JS execution order. It's a bit of a layer cake: imperative layer trigger declarative layers trigger imperative layers. The top imperative layer (eg System.import()) loads the root of the first dependency tree and parses it, entering a declarative specification layer, the import declarations. These declarations are then processed with Loader callbacks, in effect more imperative code, that can result in parsing and more declarative analysis. By design the declarative layers prevent all of the things you seek. This layer is synchronous, unconditional, wired to JS exclusively. The imperative layers support all of the use cases you outline, though to be sure some of this is more by benign neglect than design. By providing a custom Loader one can configure the module registry to contain optional, feature-detected modules or non-JS code. The Loader can also delay loading modules until some condition is fulfilled. I expect that multiple custom loaders will emerge optimized for different use cases, with their own configuration settings to make the process simpler for devs. Guy Bedford's systemjs already supports bundling for example. This approach concentrates the configuration activity in the code preceding the load of a dependency tree (and hopefully immediately before it). This seems like a better design than say commonjs where any module at any level can manipulate the configuration. The only unfortunate issue in this result is the decision to embed the custom loader in the global environment. This means that a tree of interdependent modules can issue Loader calls expecting a particular Loader to be in System so a custom loader will have to set/unset the global while loading the tree. Maybe we can experiment with modular loaders some time. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
