Meteor: server side sort in publication not behaving as expected on page change

Question

I have the following setup: Im listing all items on the frontpage (publication frontpageItems) and listing selected items on a userpage (publication userpageItems). Im sorting the items on both pages on a lastactivity field and im doing this on the server side publication and not on the client side since I want the frontpage to be static once loaded.

Whenever the page loads initialy everything sorts fine, ie: 1,2,3.
When I navigate from frontpage to the user I have a subset of 2,3 for example
When I navigate back to frontpage the sort is as follows: 2,3,1

I assume this is because meteor caches the items, but the sort order is definitely wrong here. Refreshing the frontpage makes the sort correct again.

Is there any way to fix this? ie, clear the subscription on page switch for exampe? Im using iron-router btw to subscribe to the publications before page load. Adding client side sorting + reactive:false on the client solves my problem btw, but I cant use this since I DO need reactivity on the limit of the subscription for pagination/infinite scrolling.

Or, as a workaround, is it possible to disable reactivity on the client for sort, but keep it for limit?

kiewietr · Accepted Answer · 2014-05-13T15:33:02.493

As David mentioned below I do needed sorting on the client so I hold on to that and tried some different directions using my publication to achieve some sort of partial reactivity on the client.

I ended up implementing a publication with an observeChanges pattern and sort on lastactivity on the client side. This publication makes sure that:

Initially all items are send to the client (within the limit ofcourse)
Whenever an item is changed, it removes the lastactivity field and doesnt update that but all other attributes are updated and send over to the client
Whenever an item is added its gets a later lastactivity value then beforeLastactivity variable and thus is not added
Increasing the limit for infinite scrolling keeps working

When a client refreshes everything is send down to the client again because beforeLastactivity gets updated

Meteor.publish('popularPicks', function(limit,beforeLastactivity) {

    var init = true;
    var self = this;

    if(!beforeLastactivity)
       var beforeLastactivity = new Date().getTime();

    if(!limit) {
       var limit = 18;
    }

    var query = Picks.find({},{
       limit: limit,
       sort: { lastactivity: -1 }    
    });

    var handle = query.observeChanges({
       added: function( id,doc ){ 
          if(init){
             if(doc.lastactivity < beforeLastactivity)
                self.added( 'picks', id, doc );
          }     
       },

       changed: function( id,fields ){
          if(fields.lastactivity)
             delete fields.lastactivity;

          self.changed( 'picks', id, fields );
       }
    });

    var init = false;

    self.ready();

    self.onStop( function(){
       handle.stop();
    });

});

score 0 · Answer 2 · edited May 23 '17 at 12:06

As I explained in the answer to this question, sorting in the publish function has no affect on the order of documents on the client. Because you are using a limit, however, sorting on the server does affect which items will be on the client.

I've read the rest of your question a dozen times, and I'm unclear exactly which situations require reactivity and which do not. Based on the phrase: "I want the frontpage to be static once loaded", I'd recommend using a method (instead of a subscription) to load the required items (maybe when the client connects?) and insert the data into a session variable.

Based on our discussion, if you could get an array of ids which you want to have appear on the page you can reactively update them by subscribing to a publish function like this:

Meteor.publish('itemsWithoutLastActivity', function(ids) {
  check(ids, [String]);
  return Items.find({id: {$in: ids}}, {fields: {lastActivity: 0}});
});

This will publish all items with ids in the given array, but it will not publish the lastActivity property.

However, the documents received from your initial subscription will also still be reactive - here's where it gets really tricky. If you leave that the first subscription running, your sort order will change when items get updated.

One way to deal with this is to not subscribe to the data to begin with. Make a method call to get an ordered set of ids and then subscribe to itemsWithoutLastActivity with those ids. You will need to come up with a creative way to order them on the client - maybe just an {{#each}} which iterates over the ids and each sub-template loads the required item by id.

Hi David, thx for your answer so far, I thought sort in the publish did work because on first load everything sorts fine. But this is not always the case then and is it just a coincidence the sort seems to work ok initially? Static might be a bit misleading here because I only want the sort order to be static once loaded, but still want reactivity on some of the other attributes of the shown objects. Thats why im thinking about some custom publish which doesnt update when lastactivity changes, but im not sure how that will affect the initial loading of the objects. — kiewietr, May 12 '14 at 06:59
It may be that they appear sorted the first time because of the order the DDP messages arrive on the client, but you should always sort them yourself. I'll add some other ideas to the answer and we can keep iterating. — David Weldon, May 12 '14 at 17:01
Your answer seems like a solution direction, however, I succesfully implemented a publication with observeChanges this morning and that seems to do the job. If you see anything thats not optimal or inefficient, please let me know! Again, thx for your help. — kiewietr, May 13 '14 at 15:29

Meteor: server side sort in publication not behaving as expected on page change

2 Answers2