Recommended pagination package?

Can anybody recommend a pagination package for Meteor? I have been using Alethes: Pages but it seems to publish all fields of all documents, which is heavy on the server and very bad if you want to show a paginated list of users - I can’t find any way to prevent it from publishing sensitive information such as emails.

I’m not keen to write my own because pagination seems like the kind of standard feature where I should use a package instead of spending time reinventing the wheel.

Or does anybody know a way to limit the fields that Alethes: Pages publishes? I can’t find anything in the docs.

Thanks for any suggestions.

You can always clone the package into your packages/ folder and “fix it” there.

1 Like

You’re not the first one asking:

Thanks @Peppe_LG! I’ve had a look at that example and it seems that if I put in any fields in the auth function, the Users collection now only returns the public fields that it should show.

I’m using Meteor.users.find().fetch() in the console to check what data is published about my users.

this.Users = new Meteor.Pagination(Meteor.users, {
  itemTemplate: "user_thumbnail",
  templateName: "users",
  perPage: 12,
  availableSettings: {
    filters: true,
    sort: true
  auth: function(skip, sub){
    var userSettings = this.userSettings[] || {};
    var userFilters = userSettings.filters || {};

    var update = {};
    update["profile.public_docs_count"] = {$gt: 0}; // this construction is required to query a child property

    var _filters = _.extend(
        { $or: [update, {_id: sub.userId}]}, userFilters); // Only return users with published docs, and the user themself

    var _options = {
      limit: 12,
      skip: skip,
      fields: { username: 1 }
    if (typeof userSettings.sort === "object") 
      _options.sort = userSettings.sort;
      _options.sort = { 'profile.name_sort': 1}; // lower-case version of username
    return [_filters, _options];

It seems odd that setting fields: {username: 1} in _options should hide the sensitive fields such as emails but still show profile. However this is giving me the behaviour I want for my user list, so that’s great.

It’s only the profile of the currently logged in user you see, right? profile is a special field, which you should avoid using.

Good gracious! It never occurred to me that there would be a part of the database that can be written to from the client after you’ve removed Autopublish and Insecure. Thank you. I’ve added code to deny client updates:

update() { return true; }

Had I known this I would not have used profile, but at this point it should be OK now I’ve denied client updates? It’s not ideal but refactoring it this minute would take time I don’t have, and there’s not a huge amount of data in there.

Yes, I think so (haven’t done any Meteor programming for ~3 years, so I’m starting to get a bit rusty ^^’).