Meteor - Why should I use this.userId over Meteor.userId() whenever possible?

Question

Judging from this comment by David Glasser in the GitHub issues:

this.userId is the primary API and Meteor.userId() is syntactic sugar for users new to JavaScript who might not understand the details of successfully using this yet

It seems like we should use this.userId whenever possible (such as inside a method function, where you can use both), and only use Meteor.userId() inside publish functions. If this assumption is correct, why?

(Referring to the relevant bits of the code would also be helpful, I can't seem to find it)

Spindle

possible duplicate of Meteor.userId vs Meteor.userId() – Orthopsychiatry

@Orthopsychiatry That question is with regards to Meteor.userId vs Meteor.userId(). This question is with regards to this.userId vs Meteor.userId() – Spindle

There is an answer that seems relevant. It specifically references your question. Sorry if it isn't. – Orthopsychiatry

@Orthopsychiatry Thanks for trying to provide a relevant link, but in a method function, where you can use both this.userId or Meteor.userId(), why choose one over the other? – Spindle

Consider performance as a factor. That is the main reason for using this.userId rather than Meteor.userId – Jerboa

Answer 1

Your question seems to conflate Meteor.userId() and Meteor.user(). The body of the question seems to be asking about the former while the subject line is asking about the latter. I'll try to address both.

1. On the server, within a publish function, calling either Meteor.userId() or Meteor.user() will cause an error. Instead, use this.userId or Meteor.users.findOne(this.userId), respectively. However, note that the publish function is only called when a client subscribes. If you want the publication to change when the user record changes, you'll need to observe() the cursor returned by Meteor.users.find(this.userId) and take appropriate action when the record changes.

2. On the server, while a method call is being processed, Meteor.userId() and Meteor.user() will correspond to the ID of the calling user and their record, respectively. However, be aware that calls to Meteor.user() will result in a DB query because they are essentially equivalent to Meteor.users.findOne(Meteor.userId()).

   Directly within a method call, you can also use this.userId instead of Meteor.userId(), but you are unlikely to see a significant performance difference. When the server receives the method call, it runs your method implementation with the user's ID (and some other info) stored in a particular slot on the fiber. Meteor.userId() just retrieves the ID from the slot on the current fiber. That should be fast.

   It's generally easier to refactor code that uses Meteor.userId() than this.userId because you can't use this.userId outside of the method body (e.g. this won't have a 'userId' property within a function you call from the method body) and you can't use this.userId on the client.

3. On the client, Meteor.userId() and Meteor.user() will not throw errors and this.userId will not work. Calls to Meteor.user() are essentially equivalent to Meteor.users.findOne(Meteor.userId()), but since this corresponds to a mini-mongo DB query, performance probably won't be a concern. However, for security reasons the object returned by Meteor.user() may be incomplete (especially if the autopublish package is not installed).

Nonna

Thanks for the spot, I did mean Meteor.userId() and have corrected the question title. Everything in your answer is quite clear and confirms what I have been reading. Would it be possible for you to expand a little on "Since Meteor.userId() will work deeper in the call stack"? In your previous comment, you said "Meteor.userId() doesn't query the DB or consume any significant extra resources." - then what does it do? I haven't been able to find this piece of code in the source code. – Spindle

Thanks for the edit, although I can't claim to understand the code you linked to, I do understand a little more how Meteor.userId() works now. Also thanks for giving an alternative viewpoint to the comment in the question, that using Meteor.userId() may be better because you can port the same code elsewhere, maybe on the client. Thanks again for you answer. – Spindle

Answer 2

Simply speaking, Meteor.userId() queries the DB everytime you use it. In client side ( logically ), it looks fine - since we have minimongo.

In server side, using Meteor.userId(), consumes extra resources on SERVER, which, at times is undesired.

Now, this.userId is more over like a session variable m ie it will have a value only when there is a userid attached with the current session. And hence,using 'this' reference wont go and fetch the database everytime, but rather than that it used the active session userId.

Consider performance as a factor. That is the main reason for using this.userId rather than Meteor.userId

Jerboa

Calling Meteor.user or Meteor.userId from publish functions cause an exception. ie, these are available any where in the server except publish functions, while this.userid is available ANYWHERE. Also, it is clear that Meteor.user Meteor.userId etc fetches the user object from the mongo (via Accounts object ) - See github.com/meteor/meteor/blob/devel/packages/accounts-base/… – Jerboa

Meteor.userId() doesn't query the DB or consume any significant extra resources. However, on the server, Meteor.user() does. – Nonna