Problem with "events" on "Template.field.viewmodel("field", function (template_data) {...}"

[thearabbit]

Events don't work on

Template.field.viewmodel("field", function (template_data) {
   return {
      events: {
         ......
     }
  }

[thearabbit]

And Could I use created, rendered and destroyed or not?

[dalgard]

You are right, they don't work when using a factory function. This is an error – I will fix it today.

[thearabbit]

I waiting you :+1:

[zimt28]

Why does this package have support for these kind of events anyway? Using the package properly I can't think of a situation where you'd need this. Using Meteor's existing syntax with ViewModel.findOne should be fine.

[dalgard]

I've given it some thought, and I think you're right, @zimt28 – I added them, because I wanted to reduce the amount of boilerplate syntax in cases where a viewmodel is declared, and also wanted to have the viewmodel as the context for the events (and hooks).

But I'm afraid that they might instead tempt people to use the viewmodel syntax even in cases where the viewmodel itself isn't needed.

I'm hereby deprecating the events property and will remove it in the version coming out later today.

I'm doing the same with the life-time hooks (created, rendered, and destroyed) for the same reason, but also for a couple of other reasons:

1. One of the points of this particular viewmodel implementation is to work together with Blaze and be very lean.
2. Bindings now have an init property that runs on rendered, so it's really easy to make custom bindings that initialize things like jQuery plugins.
3. The autoruns of the viewmodel can still be used as rendered hooks – if they don't register any dependencies, they will only run once.
4. The created hook is mainly used to attach stuff such as ReactiveVars to the template instance (used as a viewmodel), which is exactly the job of ViewModel. And the destroyed hook is rarely used.

I hope you are not too disappointed by this, @thearabbit? Please close the issue when you feel like it's, well ... closed.

[dalgard]

The viewmodel attached to a template instance is available on the instance as its viewmodel property (just like with manuel:viewmodel):

Template.mytemp.onRendered(function () {
  this.viewmodel.myvalue();  // Get myvalue from the template instance's viewmodel
});

I'll probably hold the name of this template instance property as a static property to the ViewModel class so that it can be changed – then a manuel:viewmodel and a dalgard:viewmodel should be able to exist side by side even on the same template.

[dalgard]

I'm closing this with 0.7.0.