AMD Spec Enhancement: onResourceLoad

[EisenbergEffect]

I'm not sure where or how to best discuss this, but I'd like to propose a new feature as part of the AMD specification. In require.js there is a "private" hook called onResourceLoad. By supplying a function require.js will call you back each time it completes the loading of a module (or any resource for that matter). It provides contextual information, the module id and access to the defined module, more or less.

As it turns out, having a hook like this is very powerful if you are building a framework or AMD-based tooling. It opens up a bunch of interesting possibilities. A few examples are: convention based coding via module id and module relationships, aspect oriented programming via altering modules after they are defined, logging, automatic pub/sub between modules, etc.

The hook should be fairly trivial in most loaders. require.js already has it. I forked almond and was able to add it in a minute or two with only 4 lines of code. There is also a pull request for dojo which adds a similar hook.

Given the low amount of effort, small overhead, and extensive possibilities this opens up, I think it is worth seriously considering as an addition to the spec.

How shall we proceed?

[EisenbergEffect]

That sounds excellent. Obviously it would be great to have this kind of thing available as part of the ES Module Loader....and I've love to have a smooth transition from current libraries into the new ES stuff. How can I help in the process?

On Friday, June 14, 2013 7:00:47 PM UTC-4, James Burke wrote:

I would like see us try to work out if we can start adopting the ES
Module Loader APIs as that will transition better to ES land:

http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders

That spec is still under construction, but is up to date with their
latest thinking.

I am hoping to start prototyping with it just to see if we can adapt
it for AMD code. I think it has some weaknesses though still. For
instance, their normalize hook probably needs to allow for async
return so we can load a loader plugin to finish the normalization.

But also, for your use case, if you can see how it could meet your
needs that may be useful feedback to give to the ES folks that are
working on that spec.

Another first pass on this would be just for other loader implementers
to list out any related calls to what you describe, to see if there is
emergent common ground.

James

> --
> You received this message because you are subscribed to the Google Groups
> "amd-implement" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to amd-implemen...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[James Burke]

I would like see us try to work out if we can start adopting the ES
Module Loader APIs as that will transition better to ES land:

http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders

That spec is still under construction, but is up to date with their
latest thinking.

I am hoping to start prototyping with it just to see if we can adapt
it for AMD code. I think it has some weaknesses though still. For
instance, their normalize hook probably needs to allow for async
return so we can load a loader plugin to finish the normalization.

But also, for your use case, if you can see how it could meet your
needs that may be useful feedback to give to the ES folks that are
working on that spec.

Another first pass on this would be just for other loader implementers
to list out any related calls to what you describe, to see if there is
emergent common ground.

James


On Wed, Jun 12, 2013 at 10:07 PM, EisenbergEffect
<r...@bluespireconsulting.com> wrote:

[James Burke]

Reading the draft specs might be a place to start. That is how I am starting, and trying to make some code along those lines. Nothing concrete yet though.

James