Question: subscribe with unblock and then later do a blocking subscription

[funkyeah]

I am wondering what would happen if you pass whether to unblock or not in a subscribe and then later re-subscribe with block.

An example of the pattern I want to support is subscribing to data used to populate a dropdown menu. When I render the page I know I need to get that data eventually but because the data is used in an a drop-down it is lower-priority to get . So originally this.unblock is good. But then lets say a user clicks the drop-down and the data hasn't loaded yet. At that point I would like to re-subscribe without unblocking since that data is now time critical.

Is this something that should work as shown below? Is there any merit to the idea of extending unblock into a priority/yielding scheme, where lower priority publishes yield to higher priority ones?

  if Meteor.isServer    
    Meteor.publish 'mycollection',  (unblock) ->
      if unblock
        @unblock()
      Collection.find({})

  if Meteor.isClient
    # eventually want the data but not critical
    Meteor.subscribe('mycollection', true)

    # need the data to render properly
    Meteor.subscribe('mycollection', false)

[arunoda]

Your code will work.
But keep in mind, meteor's wait queue is a typical queue.
One method or subscription could block all the DDP messages for a given
client.

On Sun, Apr 5, 2015 at 9:55 PM funkyeah [email protected] wrote:

I am wondering what would happen if you pass whether to unblock or not in
a subscribe and then later re-subscribe with block.

An example of the pattern I want to support is subscribing to data used to
populate a dropdown menu. When I render the page I know I need to get that
data eventually but because the data is used in an a drop-down it is
lower-priority to get . So originally this.unblock is good. But then lets
say a user clicks the drop-down and the data hasn't loaded yet. At that
point I would like to re-subscribe without unblocking since that data is
now time critical.

Is this something that should work as shown below? Is there any merit to
the idea of extending unblock into a priority/yielding scheme, where lower
priority publishes yield to higher priority ones?

if Meteor.isServer
Meteor.publish 'mycollection', (unblock) ->
if unblock
@unblock()
Collection.find({})

if Meteor.isClient
# eventually want the data but not critical
Meteor.subscribe('mycollection', true)

# need the data to render properly
Meteor.subscribe('mycollection', false)

—
Reply to this email directly or view it on GitHub
#4.

[funkyeah]

Definitely, and that I why this unblocking should be done on large subscriptions if not critical for rendering while it should not be used for when the data is absolutely necessary.

Do you know what would happen with the code below?

and/or is this a correct assesment of it?

1. The first sub/pub to aCompleteCollection starts a DDP connection to the client, and the Collection cursor starts to be sent to the client and simultaneously incrementally added to that clients Mergebox
2. The second subscription is received and because the the first publication was called with this.unblock the first DDP connection yields and that collection pauses being added to Mergebox
3. The second publication checks to see if the partial cursor returned is already in the Mergebox, if it is it opens a DDP connection and returns a this.ready, if it isn't it opens a DDP and sends the collection followed by this.ready()
4. Once the second publication is finished it closes that DDP connection, then the publication/sending of aCompleteCollection is resumed over a new DDP connection and also again starts to add the remaining portion of aCompleteCollection to the Mergebox (or is does this start all over again?)

  if Meteor.isServer    
    Meteor.publish 'aCompleteCollection',  (unblock) ->
      if unblock
        @unblock()
      Collection.find({})

    Meteor.publish 'aPartialCollection',  (neededDocumentID) ->
      Collection.find(neededDocumentID)

  if Meteor.isClient
    # eventually want the data but not critical
    Meteor.subscribe('aCompleteCollection', true)

    # a short time later we call this
    Meteor.subscribe('aPartialCollection', id)

[funkyeah]

Sorry to pester but any idea what would happen in this scenario and/or if it would be safe?