Loader Hooks and State

[EisenbergEffect]

Loader Hooks and State

Currently, we have the following possible states:

• fetch
• translate
• instantiate
• link
• ready

We also have the following hooks:

• resolve
• fetch
• translate
• instantiate

This is certainly not my area of expertise, but there's a bit of a mismatch here that bothers me. Of particular concern to me is that the entire process of loading a resource is not accessible via hooks. The hooks seem to cut off at the instantiate phase, whereas I believe they should follow through to the ready phase. There's also a bit of an inconsistency at the beginning, with a missing resolve state.

I believe there was recently some talk around removing the locate hook, so it seems there's still issues to be discussed around this topic and I think it's pretty critical that we get this right.

Note: I realize stuff has only recently been moved over here and there's still lots of work to do. I just wanted to jump in early on an area that's particularly important to me and my community.

My personal interest is in having a ready hook which would allow me to receive the fully executed module instance along with its metadata. There are a number of important scenarios that this would open up:

• Insight - Track loads, load times, runtime usage patterns, tracing, etc.
• Instrumentation and AOP - Dynamically instrument or transform code based on the runtime context.
• Metaprogramming - Use metadata defined in instances to generate code on the fly.
• Registries - Application-Specific optimized catalogues of loaded modules for use by frameworks/libraries.

I'm sure there are other uses as well. One technique I've used repeatedly across multiple module loaders for a number of years now is to tag exports with their module id of origin, thus enabling convention-based programming, ala Rails. It's not possible to do this reliably 100% of the time without a ready hook of some sort.

I've also attempted to proxy module.execute but this technique doesn't work for real ES6 modules. So, it's not adequate...not to mention that it seems like a hack. Issue #9 is related to this. @matthewp shows a technique for using instantiate. He's got a different scenario, but hits some similar types of inconsistencies.

So, I'd love to see additional refinement in this area. And, as I've mentioned, I'm particularly interested in a ready hook. I'm also pretty sure I've heard this requested by others in different forums including @jrburke and @guybedford (Though I could be wrong, because it was quite some time ago.)

Looking forward to working through this and very excited to see the renewed effort on the loader.

[guybedford]

A post-instantiate hook could certainly be useful. Note that the module object would have the exports, but wouldn't be executed yet in ES6 since execution is late, making this not quite as simple as expected. It's only dynamic modules (CommonJS etc) that are executed during the link stage. I'm not sure of the technicalities here further myself, so perhaps others can clarify.

[EisenbergEffect]

I'd like to learn a bit more about how that works as well. For my own uses, I would need a consistent way to get the executed module, regardless of whether it's ES6 or dynamic.

[guybedford]

So the way it is written currently - the Module object is created as a reflective module record - http://whatwg.github.io/loader/#reflective-module-record. It exists with its bindings at the time of linking (which is after instantiate). The requestReady method then actually calls execution on the module (in turn ensuring execution of its dependencies, this is in the ES6 spec, not this one) - http://whatwg.github.io/loader/#request-ready.

The issue is that executing Module A, can result in executing Module B. Because the code that executes Module B here is not part of the pipeline, I'm not sure how it would be possible to spec a post-execution hook, as it is actually the ES6 spec driving this process.

I can just try and explain the details (badly) though - others will be able to comment on the actual viability.

[guybedford]

An alternative might be to ammend all methods that return module objects to ensure post-operations are applied.

[guybedford]

Note that the module instance exists as a unique entity before execution, just with no exports. Would that be useful?

[EisenbergEffect]

Unfortunately no. I actually need the exports for my own use cases. I'm thinking of a hook that would be called after a module's exports are ready.

[guybedford]

Evaluation is defined in the ES6 specification, not this one. See https://people.mozilla.org/~jorendorff/es6-draft.html#sec-moduleevaluation. There are no hooks available for evaluation that I can see.

[guybedford]

The best bet may be through module reflection added to the source itself through translate.

[EisenbergEffect]

So, if I have module A that imports module B and then A is imported...Isn't there some point where the loader knows that B is ready and now A can be executed? Isn't there some point when it knows that A is finished executing and can return it to the caller?

[guybedford]

No - this execution is all in the ES6 spec. As far as I'm aware the loader has a module object for A, then asks to make sure A is executed, then returns the module object. The module object exists before execution, there's not sense of it being undefined then defined, but rather simply moving from an unexecuted to executed state.

[guybedford]

As I say though - I have limited knowledge of the spec interactions and am just inferring, @dherman, @caridy or @wycats can most likely comment more clearly on the true viability.

[EisenbergEffect]

Hmm. Well that's disappointing to me. Seems like there isn't as nice an integration with the loader as I would have hoped.

@guybedford Can you elaborate more on the module reflection idea? For my own use cases, I basically have an export and I need to figure out what module it was originally exported from (not re-exported).

[guybedford]

The loader registry may well be iterable in which case you could probably do a sort of reverse lookup. It may be worth creating an issue to track this.

[matthewp]

#17

[EisenbergEffect]

I could iterate every module in the registry...and iterate every export to find a match, then tag the exports with the matched module id....seems kind of expensive, but maybe it would work since I don't need to do it except in certain scenarios...