在Meteor（MongoDB）中按另一个集合中的值搜索一个集合

Question

I'm building a Twitter clone, and I've hit a wall with sorting.

Here are my collections:

Tweets:
  createdAt: Date
  body:      String
  userId:    String

Events:
  createdAt: Date
  type:      String (either 'retweet' or 'like')
  tweetId:   String
  userId:    String

When a user clicks 'retweet', it creates a new Event document which tracks the tweet and user IDs.

Then, when I view a user's profile page, I do a search for all Tweets either composed by the user, or where a 'retweet' Event exists with that user Id. I do a reactive join on the server so that the Tweets collection has all the necessary tweets.

The problem is sorting: I'm sorting all Tweets by their createdAt value. If I retweet a Tweet that was created yesterday, it'll show up in my feed below any of my own tweets in the last day.

In other words, I need a way to sort Tweets either by their own createdAt field, or by the createdAt field of an associated Event if such a thing exists.

---

I'm not opposed to restructuring my models if there's a better way to do this. I had thought about creating a new Tweet whenever you 'retweet', but the problem is that each Tweet has a likeCount and a retweetCount . If I create a brand new Tweet whenever it's retweeted, and someone likes or retweets the retweet, all the numbers would be wrong (or there would be an absurd amount of denormalizing-updating required).

Answer 1

1. Make sure you always create an event for each tweet
2. Use the [reywood:publish-composite] https://atmospherejs.com/reywood/publish-composite ) package to publish the Events collection sorted by the Event.createdAt key and limited to however many events you want to show.
3. In your template, do {{#each events}} instead of {{each tweets}}
4. Use a template helper to return the body of the tweet

Helper:

Template.myTemplate.helpers({
  events: function(){
    return Events.find({},{sort: {createdAt: -1}});
  },
  body: function(){
    return Tweets.findOne({ _id: this.tweetId }).body;
  }
});

This would be a normalized approach. For performance and given that tweets are short you can just copy the body field from each tweet into the Events document.