Arrays of functions and {{#each}}


Coming from a Java background, I tend to do my JS development with lots of Object-like things. My typical pattern is something like:

var MyObject = function(arg1) {
  if (arg1) {
    this._arg1 = arg1
MyObject.prototype = {
  get arg1() {
    return this._arg1;
  set arg1(val) {
    this._arg1 = val;
  customMeth: function(foo, bar) {
    // Do some stuff
MyObject.classLevelVar = 'someVal';
MyObject.classLevelMethod = function() {
  // Do some stuff

This seems to work well for my needs, and I even use this pattern along with Collection transforms to make my data act more like entities.

Recently, however, I started working on an app that required me to register some of these classes into an array and then loop through them in the UI for display. These Classes in particular were not stored in a Collection of any means, but rather represented some means of a UI component that the user was able to re-arrange and interact with and such. Naturally I went with {{#each myWidgets}} in the template with a myWidgets helper that simply returned an array of my Widget classes, defined like the example above. Unfortunately I got an error:

Exception from Tracker recompute function:
Error: {{#each}} doesn’t support arrays with elements of type function

I have some fairly obvious work-arounds, like creating a new array of just the bits and pieces I need and returning that, but it got me thinking that my approach for creating Classes in general was flawed.

Is there a more preferred way to create objects that would lend itself to be more compatible with Meteor, in particular the {{#each}}? I am hoping I can get a more “expert” opinion than my own as to whether my efforts to try to use Classes are misplaced.


Give us exact usecase and code, cause there must be some sane way how to implement your functionality.

But functions and classes in template? Why you would need that? That is view part, so to mix data+html elements, not functions.


The question isn’t on how to make the code work. As I said, I have some work-arounds already that work just fine. The question is, am I going about creating Classes in a bad way, and even deeper should I be making everything a Class to begin with? I rather like the pattern of making things this way…it seems cleaner, and as long as I am defining the parts of the Class within one .js file it makes it easier for me to find, but this error made me think that I was introducing an element into the code that was bad in some way.