dalgard / meteor-viewmodel

Minimalist VM for Meteor
24 stars 2 forks source link

Reactive methods #14

Closed avalanche1 closed 9 years ago

avalanche1 commented 9 years ago

Hey, @dalgard! Are methods in your VM 'reactive', like you've asked Manuel here - https://github.com/ManuelDeLeon/viewmodel/issues/95?

dalgard commented 9 years ago

They are not.

I'm not sure, but as I recall, my question arose either before I discovered the undocumented autorun hook, or as part of a discussion with Manuel about which pattern works better – having children write to parents (inversion of control) or having parents read from children.

On the subject of these two patterns, I tried out various versions of both, but the former presented so many problems, that I decided to base dalgard:viewmodel around the latter. Both viewmodel packages lack central features for fully supporting an IoC version of (nested) viewmodels – most notably, a dependency injection scheme. I prefer to keep things simple.

If you care to elaborate, I'm very interested in hearing about any use case you might encounter, where missing features pose a problem.

Thanks.

dalgard commented 9 years ago

Wait. My question, that you're referring to – while being related to my experiments with various patterns – probably had to do with not being able to use viewmodel methods as proxies for normal properties on the viewmodel, because these properties couldn't be retrieved without registering a dependency.

That discussion was unfolded in this thread: #92

It ended in Manuel suggested to use Tracker.nonreactive. In my package, property getter-setters instead have a nonreactive method for retrieving the value nonreactively:

Template.example.viewmodel({
  regex: null,

  value(new_value) {
    if (_.isString(new_value)) {
      let regex = new RegExp(new_value);
      this.regex(regex);
    }
    else {
      let regex = this.regex.nonreactive();  //!
      return _.isRegExp(regex) ? regex.source : "";
    }
  }
});

EDIT: No, this can not have been the issue either. The code above doesn't make any sense – there's no reason why the same method would set a value reactively and get the same value nonreactively. It would have to be in the context of an autorun.