Consider sugaring for more uniform API

[dalgard]

When writing deny and allow rules, the signature looks like this:

collection.allow({
  insert: function (user_id, doc) { ... }
});

Would you consider overloading the API of collection-hooks so that instead of a plain object, the before (and after and so on) property was a function which took a dictionary in the same manner as allow?

Since functions are also objects, the current API could go on completely unchanged – the new function would just be some sugar, passing things on to its own sub-method.

I would look more pretty and be less confusing, I think:

collection.before({
  insert: function (user_id, doc) { ... }
});

  Just to make clear what I mean, the implementation would look something like this:

Mongo.Collection.prototype.before = function (dict) {
  Object.keys(dict).forEach(function (key) {
    var method = this.before[key];
    if (typeof method === "function") method(dict[key]);
  });
};

Mongo.Collection.prototype.before.insert = function (callback) { ... };

...

[matb33]

I had actually written it this way at some point. I opted for the current way because it was less common to need to declare insert, update, remove etc in the same block of code, whereas with allow/deny, one would almost always declare these in the same area.

I wouldn't say "case closed" just yet, but something to think on.

[dalgard]

True. Mainly, I think it would look nice :) It's nice when things are written in the same way.

[matb33]

I'll leave this design decision to Meteor core devs should they choose to eventually roll collection hooks into core.