Skip to content
This repository has been archived by the owner on Jun 15, 2021. It is now read-only.

Before and after package load callbacks #53

Closed
beatgammit opened this issue Jul 6, 2011 · 3 comments
Closed

Before and after package load callbacks #53

beatgammit opened this issue Jul 6, 2011 · 3 comments

Comments

@beatgammit
Copy link
Contributor

Sometimes modules behave differently when other modules are also 'installed', especially for having a premium and free version of a webapp. I have hacked up my own way, but it is just that, a hack. It would be nice to have an API for doing this.

This could be built in ($.packages), or it could be made into a separate module that can be plugged into the API.

Making something as simple as before and after load callbacks would make it easy to make something like this, and also could provide the ability to make some pretty cool package-management modules (loading bars, lazy-loading of modules, etc).

Perhaps attaching it to provide could do the trick:

  • provide.before
  • provide.after

There would have to be a way to ensure that the module that is attaching callbacks to the provide method is executed first. I can't think of a clean way without requiring the module to have a specific 'keyword' in it's package.json.

It might, alternatively, be nice to have an event module. Provide could emit an event that could be listened to. This would have the same requirement as the other way, unless ender delays emitting events until all modules have been loaded. This seems a little messy to me, but I guess it could work.

I don't know the best way to do this, or even if the current setup can easily support this.

@fat
Copy link
Contributor

fat commented Jul 16, 2011

huh? You lost me -- could you provide a small code sample of what you're talking about?

@beatgammit
Copy link
Contributor Author

If I wanted to build a package that keeps track of all of the modules loaded:

(function () {
    var modules = [],
        $ = require('ender');

    // called just before the module is loaded
    $.provide.before = function (moduleName) {
        modules.push(moduleName);
    };

    // callback would have the value of the module's module.exports
    $.provide.after = function (module) {
        // or do something smarter, like getting data from modules
        if (init in module) {
            module.init();
        }
    };

    module.exports = modules;
}());

This is just a simple example. If events were used, this would be even better, since multiple packages could use the events:

(function () {
    var modules = [],
        $ = require('ender');

    $.on('provide', function (moduleName, module) {
        // some distinguishing feature
        if (init in module) {
            modules.push(moduleName);
            module.init(moduleName);
        }
    });

    module.exports = modules;
}());

I can see this being useful for people (like myself) that want to put all of their code in ender, but their code is modular, so they can't depend on all modules being there. Instead of a messy try-catch, they can just use a module db to keep track of modules they're interested in.

This same idea can be used in development to create a test-suite that performs unit tests on modules in a browser environment. This could help automate testing between browsers.

What do you think about it?

@fat
Copy link
Contributor

fat commented Jul 29, 2011

Alright -- sorry for taking so long to get back to you!

That makes sense now -- thanks for clearing it up.

I think i would prefer this to live outside the ender-js library. In fact -- i feel like this would be a perfect "plugin" for ender (as a separate package).

Just wrap the original provide and require methods, and make sure you build the plugin into your ender lib first :)

Doing that will give you lots more room to add a proper event system and all that hottness -- stuff we couldn't really get away with adding here. Sound good?

I'm going to close this -- but feel free to reopen if you would like to continue to make it's case to be added to the core of the lib.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants