Extended Meteor.userId() and Meteor.user()

announce
1

Adding this package to your Meteor application:

  • makes Meteor.userId() work also inside the publish endpoint functions
  • prevents direct modification of the user’s profile from the client, which is otherwise allowed by Meteor
  • extends Meteor.user(userId) into Meteor.user(userId, fields) which now accepts an argument to limit queried fields (and thus function’s reactivity); userId is optional and if not specified Meteor.userId() is used instead
11 Likes
2

Wow, this.userId vs Meteor.userId() was by far the most annoying inconsistency for me, even more than this vs template vs Template.instance().

Kudos!

2 Likes
3

Thanks @mitar !!
Indeed, it was annoying and disallowed some usage of user related logic for me.

4

Well done, looks great.

5

This would be very nice for Meteor to have natively. Since pub functions are scoped to the client requesting a sub, it makes sense to provide familiar APIs for easy code re-use (for example, validation functions, etc).

I made a new idea for it on GitHub: https://github.com/meteor/meteor/issues/5882

6

What’s the diff bw
Meteor.user({username: 1})
and
Meteor.user().username
?

7

Meteor.user({username: 1}) limits reactivity only to the username field and returns the whole object. Meteor.user().username returns just the username. If you need username, the best thing is to do Meteor.user({username: 1}).username.

2 Likes