This.ready with Meteor.publish null?

crapthings · January 31, 2018, 12:59am

if i have a publish with name null and it require user login to use.

Meteor.publish(null, function () {
if (!this.userId)
return vs return this.stop() vs this.ready()

return Test.find()
})

do i have to stop or set ready there, or just return is okay

jdsplit · January 31, 2018, 1:18am

I usually do something like that :

Meteor.publish('settings', function() {

  const uid = Meteor.userId()
  if ( ! uid ) {
    return [] // Declares that no data is being published
  }

  ...

})

crapthings · January 31, 2018, 1:28am

yes, but what if publication’s name is null,

does it need ready or not.

crapthings · January 31, 2018, 1:34am

it looks like official package write return null

github.com

meteor/meteor/blob/devel/packages/accounts-base/accounts_server.js#L756


};


accounts._server.publish(null, function () {
  if (this.userId) {
    return accounts.users.find({
      _id: this.userId
    }, {
      fields: toFieldSelector(accounts._autopublishFields.loggedInUser)
    });
  } else {
    return null;
  }
}, /*suppress autopublish warning*/{is_auto: true});


// XXX this publish is neither dedup-able nor is it optimized by our special
// treatment of queries on a specific _id. Therefore this will have O(n^2)
// run-time performance every time a user document is changed (eg someone
// logging in). If this is a problem, we can instead write a manual publish
// function which filters out fields based on 'this.userId'.
accounts._server.publish(null, function () {
  var selector = this.userId ? {