I have a publish function as follows:

Meteor.publish('tasks', function (name) {
    var project = Projects.findOne({name: name});

    return Tasks.find({projectId: project._id});
});

Now assume that at some point changes are made to Projects with the result that the above Projects.findOne returns a different project and so the Tasks.find will return other tasks. However the changes made to Projects doesn't republish the tasks

I've used reactivePublish, but it turns out the package has issues (and also does not have any unit tests). So, is there an easy way to make this publish function re-publish when project changes ?

I have a publish function as follows:

Meteor.publish('tasks', function (name) {
    var project = Projects.findOne({name: name});

    return Tasks.find({projectId: project._id});
});

Now assume that at some point changes are made to Projects with the result that the above Projects.findOne returns a different project and so the Tasks.find will return other tasks. However the changes made to Projects doesn't republish the tasks

I've used reactivePublish, but it turns out the package has issues (and also does not have any unit tests). So, is there an easy way to make this publish function re-publish when project changes ?

• javascript
• meteor
• meteor-publications

• possible duplicate of Publish documents in a collection to a meteor client depending on the existance of a specific document in another collection (publish-with-relations) – David Weldon Commented Oct 16, 2014 at 8:05
• Why should you republish it? The cursor you return is Tasks. If you Tasks is changed, it should be automatically published. – waitingkuo Commented Oct 16, 2014 at 8:06
• I was actually looking for an answer without the use of some kind of plugin. For example, the answer in the other post suggests to use meteor-publish-with-relations This project was last modified a year ago. It will probably give me at some point the same issues I have now with reactivePublish – Jeanluca Scaljeri Commented Oct 16, 2014 at 8:34
• what are you subscribing to? Does the name change reactively in your subscribe? – Christian Fritz Commented Oct 16, 2014 at 13:29
• good point, it wasn't very clear. I've improved the question – Jeanluca Scaljeri Commented Oct 16, 2014 at 14:00

2 Answers 2

Overview

As of this writing, reactive joins are an unsolved problem. For a complete overview see Reactive Joins In Meteor.

Recommendations

I strongly recommend against using observeChanges directly. It's incredibly hard to get right, and easy to develop a memory leak. If you don't believe me, watch this video on EventedMind. It will make your eyes bleed.

There are several package-based solutions to this problem. The meteor guide recommends publish-composite.

If you find the idea of using a package-based solution to be unacceptable, have a close look at the Joining On The Client section from Reactive Joins In Meteor. It's clean but requires more waiting on the user's part. Also see my post on template joins if you prefer to active your subscriptions at the template level.

There is a new kid on the block now. A full server-side reactive publish solution. (Disclaimer: I am one of the authors.) It is designed so that you can use it normally as you would expect with autorun. It takes care of everything automatically.

Install the package by calling meteor add peerlibrary:reactive-publish.

With the package added you can then simply do:

Meteor.publish('tasks', function (name) {
    this.autorun(function (computation) {
        var project = Projects.findOne({name: name}, {fields: {_id: 1}});

        return Tasks.find({projectId: project._id});
    });
});

Exactly as you would expect. :-)

The important part is to limit fields in the first query only to _id, otherwise autorun will be rerun every time any field of the project document changes. You do not want that.