How to make Meteor reactive on sub-items, but not parent - meteor

Question

I've got a Newsfeed idea that I wanted to build with Meteor, but I'm having a bit of a struggle figuring out how to make the news feed itself constant, that is not reactive, but update the sub-items (comments, likes, etc) as soon as they're updated.
I've got everything stored in a single collection, and I'd like to keep it that way if possible. So the collection is setup like this:
[
{
title: 'A random title',
date_created: '01/01/2001',
comments:
[
{'message': 'Lorem ipsum', date_created: '01/01/2001'},
[...]
]
},
[...]
]
So what I'd like to do is have the newsfeed non-reactive, so that when a new news item is inserted or updated, the template holding the list of news won't get re-rendered. But if a comment is added, deleted, or someone likes the news feed, I'd want that to get updated right away in the template.
I've been trying to figure out how to use {{#isolate}} and {{#constant}} but to no prevail.
Here's my client side JS:
Template.group_feed.feed_data = function() {
var feed = Newsfeed.find({}, {
sort: {updated_time: -1},
limit: 10,
reactive: false
}).fetch();
return feed;
};
I set reactive: false so that it doesn't update the template, but that makes it static also when comments or likes are updated. So I'm guessing there's a better way to do this then to make the whole collection non-reactive.
Here's my template code:
<template name="group_feed">
<div id="feed-wrapper">
<ul>
{{#each feed_data}}
{{> group_feed_item}}
{{/each}}
</ul>
</div>
</template>
<template name="group_feed_item">
<li>
<h1>{{title}}</h1>
<div class="comments">
{{#each comments}}
<p>{{message}}</p>
{{/each}}
</div>
</li>
</template>
Anyone got a nice way of achieving this?

Answer 1

You have two options here. (I'll use coffeescript for my pseudocode)
use observeChanges:
NewsCursor = NewsItems.find()
NewsCursor.observeChanges
changed: (id, fields) ->
if fields.comments
Session.set ("commentsForId"+id), fields.comments
Split your data into two collections: one for the posts and one for the comments.
If you don't do one of those, {{isolate}} isn't going to help you. With your current data setup, Meteor just sees whether the post changed or not, and updates any templates when it does; it doesn't keep track of which part changed.

Answer 2

I did not test it, but I guess it would be most straightforward to limit the subscription of the client, thus reducing data transfer an eliminataing the need for the preserve:
it would be something like:
on server:
Meteor.publish('tenItemsBefore',function (time) {
Newsfeed.find({updated_time: {$lt time}}, {
sort: {updated_time: -1},
limit: 10
})}
on client, in reactive context eg. in Meteor.autorun():
Newsfeed.subscribe('tenItemsBefore',Session.get('lastUpdate'));
on client, triggered by an event eg. refresh using router package:
Session.set('lastUpdate', (new Date()).getTime());
hope that helps,
best, Jan

Answer 3

I'm pretty sure the problem is that you are returning an array rather than a cursor.
It seems that Spark behaves differently with the two.
Remove the .fetch() from the end of the feed query.
For more information about how this stuff works, I would strongly suggest looking at Chris Mather's great presentations at http://www.eventedmind.com/
Specifically, the one on reactivity in slow motion illustrates the difference between an array and a cursor:
http://www.eventedmind.com/posts/meteor-ui-reactivity-in-slow-motion
UPDATE: In my original answer I didn't fully understand problem - my apologies, so the bit about removing the fetch() will not help you. Here are a couple of options you might want to explore:
Using the Meteor.observe or Meteor.observeChanges to watch for changes to the comments field and updated the DOM with code ('by hand').
Create a custom collection on the server side that publishes just the comments from your original collection. So I'm not suggesting you change the data model as stored in mongo, just publish a different view of it. With this way it might be easier to continue to use templates to update the comments.
After initial loading of the collection, make a note of the viewed item ids, and then subscribe to the collection passing a list of ids to watch (or date range). This would require a new publish function that took a array of ids, and filtered the returned documents. This approach would prevent new documents disturbing what you had on screen, and you would still get comment changes, but you would also get deletions and field changes that affected non-comment fields.
Hopefully one of these approaches may fit the bill for you.

Answer 4

In case for some reason you don't want / cannot restrict the data seen by the client with publish or if new posts with earlier post time could be inserted and destroy the preservation the above solution wont work.
Therefore I suggest a different solution to more directly achieve preservation:
On opening the posts save the _id's of the watched posts in a non reactive way as by:
Session.set('watched',
_.map(
Newsfeed.find({}, {
sort: {updated_time: -1},
limit: 10,
reactive: false //not sure wheather you need both, as #StephenD
}).fetch(), // pointed out sth. fetched is non reactive by default
function (obj) {return obj._id;}
)
);
and:
Template.group_feed.feed_data = function () {
return Session.get('watched');
};
Template.group_feed_item.item = function () {
return Newsfeedd.findOne(this);
};
as well as a small update in the html (where with saves you from definining an extra template):
<template name="group_feed_item">
<li>
{{#with item}}
<h1>{{title}} - {{_id}}</h1>
<div class="comments">
{{#each comments}}
<p>{{message}}</p>
{{/each}}
</div>
{{/with}}
</li>
</template>
best, Jan

Answer 5

From the docs (emphasis mine) - http://docs.meteor.com/#find
Cursors are a reactive data source. On the client, the first time you
retrieve a cursor's documents with fetch, map, or forEach inside a
reactive computation (eg, a template or autorun), Meteor will register
a dependency on the underlying data. Any change to the collection that
changes the documents in a cursor will trigger a recomputation. To
disable this behavior, pass {reactive: false} as an option to find.
Note that when fields are specified, only changes to the included
fields will trigger callbacks in observe, observeChanges and
invalidations in reactive computations using this cursor. Careful use
of fields allows for more fine-grained reactivity for computations
that don't depend on an entire document.