Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Always unblock? #2

Open
aldeed opened this issue Oct 27, 2014 · 8 comments
Open

Question: Always unblock? #2

aldeed opened this issue Oct 27, 2014 · 8 comments

Comments

@aldeed
Copy link

aldeed commented Oct 27, 2014

I'm trying to think of a case when I would not want to unblock my publish function. The only case would be if I'm using the published data to pass as an argument (from the client) to another publish function. However, if I'm doing that, I would always have that code in an autorun, so it will rerun once the data from the first publish function arrives.

So I think it's safe to unblock all functions always, in which case, maybe you could make a version of this package that automatically unblocks all?

Am I overlooking something?

@arunoda
Copy link
Member

arunoda commented Oct 27, 2014

No you are not :)

I'm unblocking most of my publications. But some of the initial meteor related publications (like hot code reload related) must run with blocking.

What kind of API we are looking for? any ideas?

@aldeed
Copy link
Author

aldeed commented Oct 27, 2014

Hmm, if reload needs to block, then it might have to wait until MDG improves their pub/sub.

I was thinking I could just meteor add meteorhacks:unblock-all-publish and be done with it. :)

I feel the same way about Meteor methods. I unblock 90% of them, so shouldn't it really unblock by default and have this.block() when blocking is necessary? Oh well.

@arunoda
Copy link
Member

arunoda commented Oct 27, 2014

this.block() I think that's a good way to think about this issue.

But the real issue is this won't go into core anytime sooner(may be never) how hard we speak :)

@lorensr
Copy link

lorensr commented Jul 28, 2015

Is the null publication one of the ones that needs blocking? Eg

Meteor.publish null, ->
  if @userId
    Meteor.users.find @userId,
      fields: 
        services: 0
        server: 0
  else
    null

@arunoda
Copy link
Member

arunoda commented Jul 28, 2015

Hmm. Nope.
You should not write null publications at all.

@lorensr
Copy link

lorensr commented Jul 28, 2015

I thought this is the universal subscription that's in every app to get user data?

http://support.kadira.io/knowledgebase/articles/379961-what-is-null-autopublish-publication

@arunoda
Copy link
Member

arunoda commented Jul 28, 2015

Ah! yep. You mean about the core null publication.
Yep, there are using a null publication to send user data.

On Tue, Jul 28, 2015 at 9:53 AM Loren Sands-Ramshaw <
[email protected]> wrote:

I thought this is the universal subscription that's in every app to get
user data?

http://support.kadira.io/knowledgebase/articles/379961-what-is-null-autopublish-publication


Reply to this email directly or view it on GitHub
#2 (comment).

@crapthings
Copy link

for always unblock

export default {

  safeMethods(methods) {
    const _methods = {};

    _.each(methods, (method, methodName) => {
      _methods[methodName] = function () {
        return _isUserLogin(this, arguments, method);
      }
    });

    Meteor.methods(_methods);
  },

  safePublish(name, func) {
    Meteor.publish(name, function () {
      this.unblock();
      return _isUserLogin(this, arguments, func);
    });
  },

  safePublishComposite(name, func) {
    Meteor.publishComposite(name, function () {
      this.unblock();
      return _isUserLogin(this, arguments, func);
    });
  },

  safePublishTransformed(name, func) {
    Meteor.publishTransformed(name, function () {
      this.unblock();
      return _isUserLogin(this, arguments, func);
    });
  },

}

function _isUserLogin(ctx, args, fn) {
  return ctx.userId
    ? fn.bind(ctx)(...args)
    : ctx.error(new Meteor.Error('unauthorized'));
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants