Open creynders opened 9 years ago
Worth noting - I consider hooks and hooks-fixed to be deprecated. hooks-fixed only exists because I don't have push access to hooks and hooks has several critical bugs. grappling-hook is worth investigating, I like the idea of collaborating on code where possible, but there are 3 features / things that I really need from a hooks library going forward -
1) Executing hooks attached to a different object. In mongoose we need to recreate hooks every time we create a new doc or subdoc, which is pretty wasteful (see Automattic/mongoose#2809). Much of the point of kareem was "attach hooks once to schema, call them from wherever" as opposed to "execute complex logic to add hooks to prototype every single time a doc is created." I may be able to implement this with callHook's context param but I want to be sure.
2) 100% test coverage. It's not a guarantee of being bug-free, but it's a good start.
3) Promises support. See Automattic/mongoose#2754. Mongoose does a lot of nasty things to make hooks play nice with promises. Kareem doesn't have built-in support for promises, but being able to do execPre()
, execPost()
, and wrap()
gives me the ability to just use mongoose's promises.
I'm curious to see if I can do 1) and 3) with grappling-hook. What do you think?
Unless I misunderstood you 1) is already possible with context
. And 3) is top of my wish list :smile:, i.e. it's the next thing I'll be working on.
Agreed on 2) and I think there's still some edge cases to be investigated there. If you start warming up to the idea, I'll aim for getting grappling-hook pass all mongoose hook-related tests to start off.
@vkarpov15 just a heads-up on the release of v3.0.0 of grappling-hook, which has full promise support. It's library-agnostic, i.e. you can use any Promises A+ compliant library with it.
There are some notable differences with how kareem does things: functions registered to post
are executed before the final callback is called. E.g.
instance.pre('save', function(){
console.log('pre:save');
});
instance.post('save', function(){
console.log('post:save');
});
instance.save = function(cb){
console.log('saving');
cb();
};
instance.save(function(){
console.log('final callback');
});
#output:
pre:save
saving
post:save
final callback
Would you consider having this kind of changes to mongoose pre/post? Or do you want it to be 100% backwards compatible?
Sorry, forgot to mention the features: (terminology: hooks=the functions you register other functions to, middleware=the functions you register to hooks, i.e. in the above example 'save' is the hook and the functions registered to pre:save and post:save are middleware)
pre
/post
)err
object and thenable hooks catch all errors (thrown or otherwise) and call the rejectedHandler of the final promise.Kareem actually does the same thing re: post hooks being executed before the final callback. Mongoose really should be doing that going forward.
Grappling hook is looking pretty sweet, I'm gonna take a look at it when I get a chance. Thanks for the great work :)
@vkarpov15 ah, now I see, you're using both hooks-fixed and kareem in mongoose. If there's anything I can help out with, let me know!
Hi @vkarpov15
First a little background before I come to my question. I'm a core team member of keystone and recently we needed some hooking functionality. So I started scouring over the many hooking modules (
hooks
,hooks-fixed
,kareem
, etc) and thought kareem definitely looked the most promising. However, we also needed a bunch of things that weren't provided out-of-the-box so at first I tried to adapt kareem to our needs. As it always goes, I ended up writing my own hooking module from scratch, thinking it would be faster to write one than adapting yours (it probably wasn't :smile: ) Anyway, this becamegrappling-hook
. Due to the fact we use and exposemongoose
inkeystone
I really wanted to make thepre
andpost
registration API compatible to mongoose's, in order to present users with a single hooking API, whether they're hooking into mongoose or keystone. It's not 100% compatible ATM, but will be pretty trivial to do so. Anyway, I can imagine you have a LOT of work with mongoose and was wondering if you'd be interested in considering using grappling-hook in mongoose. I had a superficial look at mongoose and it seems to me it would cost me very little effort to makegrappling-hook
a drop-in replacement for both kareem and hooks-fixed, but providing a bunch of extra functionality out-of-the-box, e.g. parameter passing to pre middleware, more granular control over post sequencing, a number of sugary methods which allow you to introspect middleware et cetera. Granted, it was a superficial look and I'd definitely need to compare performance with kareem. In our case performance is not such an issue, so I definitely haven't optimised the hell out of it. Just giving you a heads-up that I wrote something similar, and will actively maintain it, with promises integration on the roadmap for instance.Please do not misunderstand me, I'm not suggesting this because kareem is badly written or so AT ALL (again: AT ALL). My main motivation is that I really want to help make keystone the best it can become and to us it would be really cool to be 100% sure the hooking mechanism in keystone and mongoose is identical. And the benefit I think it could have for you is being freed of a small yet essential part of functionality of mongoose. If it doesn't interest you: I TOTALLY understand, if so, sorry for bothering you with this silliness.