On Wed, Feb 24, 2016 at 7:35 PM, Caridy Patiño <[email protected]> wrote:
> inline (but again, we should move this conversation to the loader repo > where you will get more people looking at your questions)... > > https://github.com/whatwg/loader/issues/130 > On Feb 24, 2016, at 7:57 PM, John Lenz <[email protected]> wrote: > > > var exports = System.loader.registery.get('path/file.js'); > > > No, the registry contains Module Status Objects. > Right, I'm just frame the general idea > > On Wed, Feb 24, 2016 at 3:53 PM, Caridy Patiño <[email protected]> wrote: > >> There is no such thing as a `key` in 262 (module spec). The `key` is a >> concept defined by the loader, and there it is not opaque. >> > > I don't see where the value of the key/meaning of the key is defined. Can > you be more specific as to what it is required to be? > > > The registry is essentially a Map of Module Status Objects. Users will > have control over the keys associated to a Module Status Object via the > "resolve" hook. > Right, for my purpose, if it can be "any loader defined value" that makes it an opaque value. Generally a library won't control the environment it is loaded in. > > As for retrieving the module exports, you have to go thru the APIs that >> will guarantee that those exports are ready to be consumed, and those are >> the `import` statements, the `import()` calls, and >> `Reflect.Module.evaluate()`, you have no other way to access those exports >> in a way that is reliable. >> > > "import", "import()" and "evaluate" all force a load and a wait. Forcing > a load is distinctly not what is desired here. I understand that a load > could be "under way" but if one wanted to wait they would simply call > "import()". > > > No, if you go thru the loader, it will be asynchronous to guarantee that > the module and its dependencies are ready and evaluated. > "wait" here meant "wait for the promise to resolve". > > I need to know if a module is loaded and ready, if it is I want the module > exports immediately. > > > No, the closest you can get to that is by doing this: > > ``` > let moduleStatusObj = System.loader.registry.get(key); > if (moduleStatusObj.module !== undefined) { > // you’re lucky! you have access to the exotic namespace object of the > module > } > ``` > > In user-land, when you have access to an exotic namespace object, its > module is guarantee to be instantiated, but there is not guarantee to be > evaluated, or its circular dependencies evaluated, which you will have to > force by calling `Reflect.Module.evaluate()`, which returns a promise that > resolves once the module graph is ready to roll. > Doesn't the "stage" tell you if it is "ready to roll"? > > On the other side of the coin, what if the entry is not in the registry? > Are you planning to fork the logic in your code to go and attempt to load > it? > Nope, in this case, continue without it. > /caridy > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
