Direct collection access

[rclai]

@matb33 said in Meteor-Community-Packages/meteor-collection-hooks#118:

I am, although there's one more thing I think your end needs to handle, which is direct collection access. I'd like to still offer users a way to circumvent collection hooks while still allowing other collection extensions, but it would be great to also offer the option for users to circumvent all collection extensions at once.

[rclai]

@matb33, can you elaborate more regarding "allowing users a way to circumvent collections hooks" and "circumventing collection extensions at once"?

What would your ideal API look like for all this?

[matb33]

So this is a really good question, and so I had to dig through your code in more detail to try and answer.

Now that I have, I think that perhaps your current incarnation of collection-extensions isn't quite doing enough. It doesn't appear to be taking responsibility for the actual method wrapping, which I think is important to abstract away from any consumer of collection-extensions.

For example, in the collection-hooks fork you made, I see this:

Meteor.addCollectionExtension(function () {
  CollectionHooks.extendCollectionInstance(this, (typeof Mongo !== 'undefined' && typeof Mongo.Collection !== 'undefined' ? Mongo.Collection : Meteor.Collection));
});

I'm saying that collection-extensions should go a bit further than that and actually take over responsibility for pretty much this stuff:

  // Wrap mutator methods, letting the defined advice do the work
  _.each(advices, function (advice, method) {
    // Store a reference to the mutator method in a publicly reachable location
    var _super = collection[method];

    Meteor._ensure(self, "direct", method);
    self.direct[method] = function () {
      var args = arguments;
      return directOp(function () {
        return constructor.prototype[method].apply(self, args);
      });
    };

    collection[method] = function () {

That way we are only wrapping each of the collection methods once, and collection-extensions can offer an API to add/remove/manage the various extensions (collection-hooks being one of them).

Are you following what I'm getting at? Is this deviating too much from what you originally intended? To me this seems like the sweet spot.

[rclai]

Okay, that makes sense, so essentially you'd like for this package to take care of wrapping not just the Mongo.Collection constructor but also its methods? Isn't that essentially going to cause a huge part of your package to become part of this package? I'm referring to the advice code that you have.

I'm trying to figure out how you or anyone else would like to consume this package for things other than hooks.

I think that if you explain how you plan to solve this issue I'll have a better idea of what to do on this end.

As a matter of fact, would it be too much to ask for a PR just to get things started?