Common Helpers

[aldeed]

The method used in this package is great. I'm thinking of deprecating virtualFields support in collection2 and telling everyone to use this package instead. It's better because the methods are called only as necessary.

Anyway, I suggest an option to define common helpers more easily. Like this:

One = new Meteor.Collection('one');
Two = new Meteor.Collection('two');
Three = new Meteor.Collection('three');
Four = new Meteor.Collection('four');

CollectionHelpers.addHelpers({
  creator: function() {
    return Meteor.users.findOne(this.createdBy);
  }
}, [One, Two, Three, Four]);

In apps with many collections that share many common properties, this could simplify the code a lot.

[serkandurusoy]

This would be a great pattern and has many use cases in common data access features such as the example given.

[dburles]

Hey, I was actually pondering this myself, I think this is a good idea. I'll have a play with some ideas over the weekend :)

[dburles]

How does this look?

// We can define Meteor.Collection.helpers as many times as we like
Meteor.Collection.helpers({
  dog: 'woof'
}, [Books, Authors]);

Meteor.Collection.helpers({
  cat: 'meow'
}, [Books]);

Books.findOne().dog; // "woof"
Authors.findOne().dog; // "woof"
Books.findOne().cat; // "meow"
Authors.findOne().cat; // undefined

[dburles]

Actually having thought about it some more, I don't think it's wise to attach the helpers method to Meteor.Collection as strictly speaking it's a constructor. Perhaps I'm being too strict, will ponder.

[dburles]

I'm still not 100% sure on this approach but here it is, please give it a try :)

[aldeed]

Awesome, thanks. I commented on the commit, but otherwise looks perfect. I often attach methods to constructor functions, using them as objects as well. I don't know if it's kosher, but it's fine with me. :)

I'll be able to test it out tomorrow.

[serkandurusoy]

Definitely +1

[dburles]

Cool good catch, not sure how I didn't notice that, aw well. I'll fix it up in the morning :)

[dburles]

Fixed https://github.com/dburles/meteor-collection-helpers/tree/common-helpers

[aldeed]

Perfect! Thanks for the quick turnaround. I can test tomorrow, but the code looks good to me.

[serkandurusoy]

@dburles when do you plan on releasing this on atmosphere?

[dburles]

Hey @serkandurusoy not 100% settled on the api yet however you can try it through meteorite by editing your smart.json and adding:

    "collection-helpers": {
      "git": "https://github.com/dburles/meteor-collection-helpers.git",
      "branch": "common-helpers"
    }

[serkandurusoy]

I keep dismissing how coupled with git atmoshpere is, thanks :)

[aldeed]

This works fine in my tests. No preference on the API, for me.

[dburles]

Hey guys, been thinking about this over the past few days. I think that it's easy enough to achieve this without needlessly adding further complexity to the package in the form of another api.

For example we can already achieve much the same thing by creating mixins, like:

// this might live somewhere like collections/lib/mixins.js
hasTimeHelpers = function(collection) {
  collection.helpers({
    formattedCreatedAt: function() {
      return moment(this.createdAt).format('MMMM Do YYYY, h:mm a');
    },
    formattedUpdatedAt: function() {
      return moment(this.updatedAt).format('MMMM Do YYYY, h:mm a');
    }
  });
};

// collections/authors.js
Authors = new Meteor.Collection('authors');

hasTimeHelpers(Authors);

Authors.helpers({
  fullName: function() {
    return this.firstName + ' ' + this.lastName;
  },
  books: function() {
    return Books.find({ authorId: this._id });
  }
});

[serkandurusoy]

From a personal/developer perspective, either way of declaring the common helpers looks just fine to me. Somehow, your first proposal felt more natural, though.

[aldeed]

I was doing something like your mixin example when I decided to suggest this feature. For some reason, it felt like having a built-in way would be better. However, you're correct that there doesn't seem to be much difference.

I might suggest mentioning this coding pattern in the readme, probably just pasting the example you posted here. It's probably fairly obvious, but it's always nice to see that a package author has thought of a certain scenario and has best-practice recommendations for it.

Otherwise, I'm okay with closing this.

[dburles]

Hey, thought i'd post this, here's another way to apply helpers across many collections.
This method is mush closer to the proposed API than the mixin method above.

// Time helpers
_.each([Books, Authors], function(collection) {
  collection.helpers({
    formattedCreatedAt: function() {
      return moment(this.createdAt).format('MMMM Do YYYY, h:mm a');
    },
    formattedUpdatedAt: function() {
      return moment(this.updatedAt).format('MMMM Do YYYY, h:mm a');
    }
  });
});

Not sure why I didn't think about it at the time

[queso]

Will this 'stack' so if I define a collection helper like this and then go into each collection and define more helpers, will they all get applied?

[aldeed]

@queso, yes it will extend. So they'll get added or if they have the same name, the one defined later will overwrite the earlier one.