add base event hooks methods and implement a few

[jshimko]

Initial WIP implementation of event hooks to be used in places that can't be reached with Collection or Method hooks.

Methods

ReactionCore.Hooks.Events.add(hookName, func(doc));
ReactionCore.Hooks.Events.remove(hookName, funcName);
ReactionCore.Hooks.Events.run(hookName, doc, constant);
ReactionCore.Hooks.Events.runAsync(hookName, doc, constant);

Example usage

Accounts.onCreateUser(function(options, user) {
  // add a hook to alter the user object or do something with its data
  user = ReactionCore.Hooks.Events.run("onCreateUser", user, options);
});

Now you can pass any amount of functions into that hook from anywhere else in the app

// create a callback to run
function logUserEmail(user) {
  console.log("User being created with email: " + user.emails[0].address);
  // do whatever with the user doc and then return it 
  // to the next callback
  return user;
}

// add your callback to the hooks array created above
ReactionCore.Hooks.Events.add("onCreateUser", logUserEmail);

Currently available hooks

ReactionCore.Hooks.Events.add("beforeCreateDefaultAdminUser", callback(user));
ReactionCore.Hooks.Events.add("afterCreateDefaultAdminUser", callback(user));
ReactionCore.Hooks.Events.add("onCreateUser", callback(user));
ReactionCore.Hooks.Events.add("onLogin", callback(options));

[aaronjudd]

@jshimko see code climate, let's clean those up. I think the naming convention works.. and will let us move collection and method into the same namespace without being confusing.

[tdecaluwe]

Could we also use this for collection hooks? So we could write something like:

ReactionCore.Collections.Products.after.remove(function (...) {
  Hooks.Collections.run("afterRemove", ...)
});

This would make the collection hooks more testable. Spying on a hook now requires spying on private collection-hooks variables.

[ramusus]

@jshimko, don't you think your hooks system could be separate independent package for any meteor application, not only for Reaction?

[aaronjudd]

@ramusus agree. we've already discussed, we should probably move this along with our other hooks into a reaction-hooks package

[tdecaluwe]

On the separate reaction-hooks package, I think @ramusus makes a good point in #731. Shouldn't hooks related to accounts be defined in reaction-accounts?

[jshimko]

@tdecaluwe the core hooks code doesn't actually define any hooks. It just gives you the means to do it. The example accounts hooks mentioned above (onCreateUser, onLogin) are already in the reaction-accounts package. And I totally agree that's where they should be. :)

[ramusus]

Yes, I think the core hooks could be completely independent from reaction. Something like meteor-hooks? I didn't look into the code, but I suppose this project should be reusable in any meteor project. But reaction related hooks should be spreaded inside reaction-related packages, where they should belongs to. Like accounts, or PayPal or whatever..

[aaronjudd]

@jshimko 👍 Let's merge this, and refactor in the v0.12 branch as a package.