Circumventing specific hooks

[Michał Powaga]

Is there a way to circumvent specific hooks? For example:

test.before.update('resizeImages', function (userId, doc, fieldNames, modifier, options) {
  // ...
});

test.withoutHooks('resizeImages').update({_id: "test"}, {$set: {test: 1}})

[Simon Fridlund]

test.direct.update

[Simon Fridlund]

https://github.com/matb33/meteor-collection-hooks#direct-access-circumventing-hooks

[Simon Fridlund]

Or do you only want to circumventing before and not after for example?

[Michał Powaga]

Suppose you have two hooks A and B. Direct access will circumvent hooks A and B. In some cases you may want to circumvent only hook A but still run hook B.

[Simon Fridlund]

To my knowledge this isn't supported.
One way to achieve it is to store the handler you get when adding a hook and use that to remove the hook before performing the action and after it's done add the hook once more and save the new handler.

[Michał Powaga]

Shouldn't this be supported? I think it's pretty common use case. I'd happily send a PR for this.

[Simon Fridlund]

Let's talk through a possible implementation before the PR?

[Michał Powaga]

Sure. See my proposed API at the top.

Another solution would be to use reference instead of string, e.g.

const resizeImages = test.before.update(function (userId, doc, fieldNames, modifier, options) {
  // ...
});

test.withoutHooks(resizeImages).update({_id: "test"}, {$set: {test: 1}})

[Simon Fridlund]

Today when when you do

const beforeInsertPostsHandler = Posts.before.insert((...) => ...);

You get the handler which is an object with remove and replace, maybe we could add collection/direct here and one could then use the beforeInsertPostsHandler.direct.insert(...) to run the insert without this hook.

Edit: this way we don't "pollute" the collection prototype even more.

[Michał Powaga]

Would test.direct.withoutHooks(resizeImages).update(...) be possible? I think it's more explicit. Also that would allow to disable many hooks at the same time.

[Simon Fridlund]

Maybe we can support .direct(options), it would be a "breaking" change but there are other potentially breaking changes in 0.9.0-rc4 so I'm thinking it's fine as long as we document the change.