Hooks with a callback

[jogly]

I was wondering if the option to support asynchronous functions from within a hook (supposedly by using a done callback passed in as a parameter to indicate continuing on with the actions/hooks) was on this project's timeline? It certainly would be a nice feature to have, since I have one slightly CPU intensive sync method inside a hook that I would prefer to use the async version of.

[dxg]

Whilst the actual question will have to be answered by dresende, I have a question of my own (and forgive me if I misunderstand):

What's the benefit of having a CPU intensive task in an asynchronous callback?
Async solves the problem of I/O blocking operations, not cpu intensive ones.

[jogly]

Absolutely correct, and as I described my problem it wouldn't solve anything. But I can break my one CPU intensive task into many less intensive smaller tasks as functions to give as much time back to the thread as possible.

[dresende]

But you're saying you need to do it before the Hook finishes? I'm not sure if we can detect if the user will call done or not. Maybe by the number of arguments of the anonymous (or real) function passed to the Hook. Or maybe by forcing people to return false or something. What would you suggest to avoid breaking current implementation?

[jogly]

I certainly understand the question. Maintaining the current functionality is definitely important. I'm currently battling two notions in my head. First, your idea of working with the return value. This would suit my purposes splendidly, but I would personally be shy suggesting that, solely because that would reduce the flexibility of the hook to future ideas to fit one use case (unless there are other folk who also would benefit?).

The other is a duplicate hook with an 'Async' post-fix (or other identifier) for every synchronous hook. I dislike this idea primarily because I dislike duplication; it can get messy. I've seen many reputable libraries include synchronous versions of asynchronous functions, though. The converse couldn't be too out of the ordinary, and it would maintain the return value's flexibility.

Apologies, this doesn't really answer your question, but they're thoughts and neither implementation should break current functionality.

[jogly]

I don't know how I missed this in your original comment, but after re-reading I noticed your suggestion for number of arguments. By checking the arity (length) of the function passed as a hook you could tell if the user included, and is expecting to call, the done argument. This would be my personal choice as it does not break functionality and the hook remains flexible. Unless, of course, I've misunderstood something fundamental...this is known to happen.

[dresende]

Yes, that was my suggestion. The only thing that could break it would be to use any kind of async library that might add arguments to the call. I'm going to try this, I think Function.length is standard and not deprecated.

[dresende]

Ok, I added this only for beforeRemove hook. Perhaps only the before* should have this async behavior, the rest it doesn't make sense. Take a look at test-hook-before-remove-wait.js test file.

If the hook function does not have the arity of the hook (in this case, none) + the next() function, it will assume the hook as no objection and so it will continue without waiting. If you want to just do something or check something and there's no problem to continue with execution just call next(). If you want to abort just call it with an Error as first argument. That error will be passed to the Model.remove callback.

[dresende]

I forgot to mention I will add this to more hooks if this implementation looks OK.

[jogly]

I can't think of a use case for the after* hooks, but I can't presume to deny they exist. My request was specifically for the before* hooks anyway :). The test scenario looks like exactly what I needed. Ill pull the commit when the other hooks are in place. Thanks! Faster than I could have hoped for.

[dresende]

OK, there's information about this in the Readme. If you find anything missing just point it out :)