Meteor-Community-Packages / meteor-collection-hooks

Meteor Collection Hooks
https://atmospherejs.com/matb33/collection-hooks
MIT License
657 stars 92 forks source link

Client side hook #183

Closed chneau closed 8 years ago

chneau commented 8 years ago

I need to have a hook on a collection to notify some users that some other users have completed a job.

Basically, I added this to the onCreated of a template (properly removed() on the onDestroyed).

Jobs.after.update(function(userId, doc, fieldNames, modifier, options) {
  console.log('Job changed');
});

The client only hook changes done on the current window. If I duplicate the tab and do modifications to Jobs, the first tab doesn't hook at all. It's not the behavior I expected. It is normal ? How can a client hooks changes client sidely ? I'm using these packages:

aldeed:collection2 dburles:collection-helpers

matb33 commented 8 years ago

Have you considered running the hook on the server? The behavior you're trying to achieve doesn't sound right being done on the client

chneau commented 8 years ago

Hello @matb33 , thanks for the response. I did use "observeChanges" for what I wanted to do.

I think I just misunderstood how this package has to be used and in my case observeChanges was what I needed to use. (On client side, because my "completed" Jobs disappear somewhere else, I needed to create notifications to tell the user who has completed a job.)

By doing this I understood that on a server instance, this package hooks only what the instance do. Same on the client side, it hooks what the user do. And in my case, I wanted the user to be aware of what other users have jsut done.

matb33 commented 8 years ago

Collection hooks can still be used for your use case -- just define them on the server. You can use observeChanges but I find its API not as convenient (and there's no such thing as before.delete in its case)

chneau commented 8 years ago

My bad, by completed I mean one of the field of my Job is set to a date. So "changed" of "observeChanges" is fine for me (and is triggered even if the action is done on an other instance of Meteor). But on the server side I can see an interest using your package, for example if I have multiple instances of Meteor, you package will trigger only once (I will use multi meteor + nginx with sticky session). Not sure I'm doing good, I'm on a step where I try to scale Meteor.

matb33 commented 8 years ago

Using that technique with observeChanges means it needs to set-up a live-query and watch the data. Using collection-hooks, it's just intercepting the mutator method (i.e. update) and running code at that time, so no need for the extra overhead of watching a query. If you are concerned about performance/scale, this may factor into your decision.

And technically speaking, you have that observeChanges running on each of your instances, and were you using collection-hooks, the hook would be set-up on each of your instances.

I assume that when the "change" occurs, you'd be adding a doc to a "notifications" collection of sorts. With collection-hooks, on the instance where the user is making a "change", the insert of this notification would hit your db, and would propagate to the correct client (assuming you are doing a pub/sub of notifications). With observeChanges, you'll get the "change" event on each instance, so you'll be adding a doc to your "notification" collection for each instance, so many duplicates.