Increase limit in publish when new documents are added

I have been trying to figure out a way to approach this. I am working on a messenger like feature with infinite scroll that fetches new items from bottom to top. Limit is set on the client side within the subscription. What I am looking to achieve:

  • Increase the query limit within publish (server side) that user is subscribed to when new documents were added to the whole collection, without having to do a round-trip server-client-server

Right now I am using count to evaluate the changes in the collection not constrained by limit. Within my Publish I have:

  • Total count via publish-counts package

  • Find with limit params given by the subscription.

I am already using an observer on my Publish cursor, and thus when a new message is added to the collection, I am preventing the delete in ‘removed’ observer.

Is there a way to store params on the server side in a Publish function? I feel that would be more elegant and would allow me to differentiate between user deleted messages and collection shifts. I don’t really want to observe the whole collection as I feel it would be really taxing on the performance. I would appreciate it if someone knows and shares a better way to do it, thanks

1 Like

you can do it in low level publish API, send initial payload to client and than just continue with observeChanges and if added than send another data to server. And you can decide when to call remove from server side too.
In official documentation is nice example.

@shock Thanks for the advice, I just came back from a long walk and realized I have been approaching it wrong since I was trying to handle it on the server side. I tried to tail the oplog changes via observeChanges, increase the limit on the server side by new messages and then send the collection changes to the client.

I will just:

  1. prevent remove (keep the document) on the client side

  2. increase the limit non-reactively on the client side

  3. send that new limit with next subscription reactive trigger on infinite scroll.

I think that’s the valid way of achieving correct number of documents and preventing re-drawing of documents due to collection shifts as I am fetching the newest first.