Open funkyeah opened 9 years ago
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 notifications@github.com 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 https://github.com/meteorhacks/unblock/issues/4.
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?
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)
Sorry to pester but any idea what would happen in this scenario and/or if it would be safe?
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?