I have a list of comments in my page which the user can upvote.
I want these comments to be sorted by the number of upvotes.
However, since the Comments collection is reactive, once a user upvotes a comment, the order of the comments changes reactively, which I don't like because it's very confusing for the user (the comment goes on top and it seems like it disappeared).
I still want the comments to be somewhat reactive (when someone adds a new comment or updates it, it should appear on the page without refreshing).
I don't mind if the user has to refresh the page to see the comments sorted by upvotes.
How do I make the order by number of upvotes non-reactive?
This is the template:
{{#each comments}}
{{>comment}}
{{/each}}
and the helper:
Template.post.helpers({
comments: function() {
return Comments.find({},{sort: {numberOfUpvotes: -1});
}
}
I thought about using Tracker.nonreactive(), but I'm not really sure how this would work.
Thanks
From a UX perspective, the answer is easy: animations! When they upvote, they SEE the post move up the chain. I think discover meteor has this exact example in the last chapter of the book, so just give it a read & it'll walk you through how to use uihooks (or just check out their github).
Disabling reactivity until a refresh, although possible, is kind of ugly. If you wanted to do that, just do a Comments.find({postId: 'foo'},{reactive:false}); in your helper.
Can you show us how you subscribe to that collection? The way I would subscribe in that situation is:
return Comments.find({}, {sort: {numberOfUpvotes: -1}, reactive: false});
Related
I'm trying to save user content on blur and am encountering a weird UI freeze after the save that I've never seen before.
A simplified version of the template:
{{#each UserSession.getQuestions}}
<textearea class='question'>{{UserSession.getVal this._id}}</teaxtarea>
{{/each}}
In other words, we iterate over a cursor from the Questions collection that selects all questions a user must answer, and we populate the textarea with a value from the UserSessions collection that contains this user's response to that question. For what it's worth, the textarea is actually in its own template (there are other things to show in there so i figured best to keep them isolated).
The user can modify the content of his response, and then I have an event handler that basically does this:
"blur .question": function(e) {
var val = $(e.target).val();
var questionId = this._id;
var userSessionId = Meteor.user().getSessionId();
var modifier = {$set: {}};
modifier["$set"]["questions." + questionId + "] = val;
UserSessions.update({_id: userSessionId}, modifier);
}
The update succeeds but the browser freezes for about a second after the save executes, so that if the blur is triggered by a user clicking on another element, that element doesn't come into focus cleanly. This is a problem because I also want to do periodic saves while the user is typing, but when I do that, the hiccup interrupts the typing: the resulting experience is pretty brutal.
The interesting thing is that the browser only seems to freeze when the property being updated is an object or in a list. In other words:
UserSessions.update({_id: userSessionId}, {$set: {"questions.questionId": "someVal"}}) causes the freeze, as does UserSessions.update({_id: userSessionId}, {$set: {"lastSavedAt": new Date()}}).
However, UserSessions.update({_id: userSessionId}, {$set: {"someOtherProp": "someVal"}}) works fine.
I've tried several different approaches, including an async client-side pattern and executing the save via Meteor Method in a if (Meteor.isServer) block -- all the same result. Must be something to do with the publication updating, but it happens even when i set the publish function query to {reactive: false}.
I'm out of ideas. Your help, as always, is greatly appreciated.
Thanks in advance,
db
Ok I think I figured it out. For anyone else who has this problem, if you're using Iron Router you should check it for un-necessary dependencies. In this case it was the router being re-run that clogged up the works, because the data hook included a reactive find request on the UserSessions collection. I set reactive to false and specified the fields to prevent a recomputation, and everything smoothed itself out.
I have an app where I want to display a counter of elements I have in one of the collection.
To do so I use a helper that I call in my HTML file {{nbPosts}}
UI.registerHelper('nbPosts', function () {
return Posts.find().count();
});
But to display it I need to subscribe to the whole Posts collection.
It does not seem right to me, any suggestion to do that in a better way without sending the whole collection ?
Thanks,
It depends on whether you need this to update the data reactively (which I think is not the best idea), or not. If reactivity is not important you can just use a server method, so
Meteor.methods({
'nbPosts': function () {
return Posts.find().count();
},
});
If you need reactivity you can implement a custom publish method, just like in this example. Just keep in mind that this will be a lot more expensive in terms of server usage, and so a much less efficient.
The easiest way would be to have a collection that just keeps track of the number of posts, and update it whenever a post is inserted or removed.
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?
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.
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
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.
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
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.
If I change a Session var and trigger a re-subscription via autosubscribe, is there any callback mechanism to wait until the 'latest' data is down from the server? [1]
If you take a look at this gist you'll see some code that logs the content of a collection over time as the subscription changes. A relevant section of the output:
at Subscribed; comments are: first post on #1 - second post on #1
at Flushed; comments are: first post on #1 - second post on #1
at Subscription complete; comments are: first post on #1 - second post on #1 - first post on #2 - second post on #2
So, even after (a) calling .subscribe, (b) calling Meteor.flush (c) being inside the onReady callback for the .subscribe; there is still stale data in the collection, and only in the 3rd case is the 'correct' data in there.
I realise that reactive templates and .observe will eventually receive the correct data and things will 'settle' into the correct state. But is there some way we can tell that we aren't there yet?
For instance, most of the meteor example apps (and my own apps) are prone to jerking around a bit (similar to a FOUC) while data is added + removed from a subscribed collection. If we could tell that a subscription was 'loading' we could do something about this.
[1] Obviously the data on the server is constantly changing, but as you'll see in the gist, I can't (without a timeout) find a point where it's even correct. Thus my use of 'valid' in the question.
A very simple and common use case
Take the madewith app; when you first load it up it appears that there are no apps registered, until after the data comes down the wire and the apps suddenly appear.
The reason for this is that Meteor.subscribe has been called, but the data has not yet come down the wire. But there's no easy way for the template to tell that the data is pending and that it should show a 'loading' template. In madewith they actually do something when the data has loaded, but this is a callback and thus breaks out of the normal meteor way of doing things (i.e. reactive coding).
It would be much nicer (IMO) to be able to write something like:
{{unless apps_loaded}}{{> loading}}{{/unless}}
and
Template.madewith.apps_loaded = function() { return !Apps.isComplete(); }
Interesting question.
The right place to be notified for new subscriptions is the onReady callback. Notice the logging that happens there always includes your new data. Checking at (a) and (b) aren't useful, because there's latency between calling subscribe and when all the data arrives from the server.
The underlying problem is there's no equivalent onRemove callback that runs once the data for a just-stopped subscription has been removed. Moreover, autosubscribe deliberately starts new subs before stopping old ones, to avoid flicker.
What's the real use case? Most of the time such a callback isn't necessary, because templates can also restrict their queries to the data that should be in scope. In your example, the template helper that renders comments might query only for comments with the current post_id in the Session, so there's no harm having extra comments in the database.
Something like this:
Template.post.comments = function () {
return Comments.find({post_id: Session.get('post_id')});
};
That permits strategies more sophisticated that the generic autosubscribe function, like subscribing to comments for the last three posts the user has viewed. Or, subscribing to the first few comments for each post, and then separately subscribing to a post's full set of comments only when that post is selected.
I've come a bit late to the meteor party, so I don't know the history behind when meteor features have been added, but just for completeness it is now possible to do this using template-level subscriptions and 'subscriptionsReady' :
[js]
Template.myTemplate.onCreated(function() {
this.subscribe('myData');
});
[html]
<template name="myTemplate">
<h2>my Template</h2>
{{#if Template.subscriptionsReady}}
// code to loop/display myData
{{else}}
<p>Please wait..</p>
{{/if}}
</template>
Is there a way to subscribe to the Meteor Session object so that a reactive template view automatically renders when data is .set on the Session object? Specifically the key/name and value data?
I have a similar question related to rendering Meteor Session object data when iterated over. This question is specifically different on purpose. I want to get an answer out on an alternate way and possibly better way to do the same thing.
I do not want to have to call Session.get('name'); This use case is because I don't know the names in the Session object.
So, I would like to be able to have something in handlebars that allows me to
Psuedo code...
{{#each Session}}
{{this.key}} {{this.value}}
{{/each}}
Unsure about subscribing to the session, but for the second part of your question, you can use this:
Template.hello.session = function () {
map = []
for (prop in Session.keys) {
map.push({key: prop, value: Session.get(prop)})
}
return map
}
then in your template:
{{#each session}}
{{key}} {{value}}
{{/each}}
Not sure if there's a more elegant way but it works.
I don't think so.
Have a look at https://github.com/meteor/meteor/blob/master/packages/session/session.js. It's actually reasonably simple. The invalidation happens in lines 45-47. You'll see calling Session.set invalidates anyone listening to that key specifically (via Session.get) or to the new or old value (via Session.equals). Nothing in there about invalidating the session as whole.
On the other hand, considering how simple it is, it wouldn't be super hard to write your own data structure that does what you want. I'm not sure what your use case is, but it might make a lot of sense to separate it from the session.
Yes you can subscribe to Session values.
Take a look a the docs for autosubscribe:
http://docs.meteor.com/#meteor_autosubscribe
// Subscribe to the chat messages in the current room. Automatically
// update the subscription whenever the current room changes.
Meteor.autosubscribe(function () {
Meteor.subscribe("chat", {room: Session.get("current-room");});
});
This code block shows one way to use this. Basically any time the value of "current-room" is changed Meteor will update the views.
EDIT
I misunderstood the initial question and decided I need to redeem myself somewhat. I just did some tests and as far as I can tell you can currently only subscribe to collection.find() and session.get() calls. So you can't subscribe to the whole session object or even to the keys object.
However, you can set a Session value to an object this may not be the most elegant solution but this worked for me on keeping track of the keys object with some hackery to keep from getting a circular object error.
var mySession = {
set: function(key, val){
var keys = Session.keys,
map = {};
Session.set(key, val);
for (var prop in keys) {
if(!(prop === "keys")){
map[prop] = keys[prop];
}
}
Session.set('keys', map);
}
};
This gives you something that looks a lot like original functionality and can help you keep track and update templates as you add or change Session values.
Here's my template helper (borrowed from previous answer):
Template.hello.keys = function() {
map = [];
keys = Session.get('keys');
for (var prop in keys) {
map.push({key:prop, value:keys[prop]});
}
return map
};
And here's the actual template:
<template name="hello">
<div class="hello">
{{#each keys}}
{{key}} {{value}} <br />
{{/each}}
</div>
</template>
This way you can just call mySession.set("thing", "another thing") and it will update on screen. I am new to Javascript so someone please let me know if I'm missing something obvious here, or let me know if there is a more elegant way of doing this.
While accessing the session object in this manner is doable .. You're not drinking the cool-aid.
In other words, Meteor excels in the respect of having publish/subscribe. Its not clear (to me) how much data you've got to put into the Session object before a browser crashes; I would rather not find out.
You would merely put all your session dependent code in a Deps.autorun() function to plug into subscriptions as mentioned in an earlier answer. Any time a session changes it'll modify the subscription; you can attach a ready callback, or use subscription.ready() checks to initiate specific actions, but ideally you'd structure your templates in a way that you could use rendered/destroyed functions, taking care to use {{isolate}}/{{constant}} when possible.
What you're getting at is kind of a difficult way to do something simple; and may not adhere to changes in meteor in the future; we can always be assured publish/subscribe will function as expected... Given Session is such a simple object.. whats to say someone designs something better shortly.. and it gets merged into meteor; and you're left with some weird workflow based on custom objects that may not break the Session; but may impact other parts of your interface.