Today I’m confused about reactivity concept behind VM…
Docs say: All view model properties and methods are available as template helpers.
Meteor docs say: Under the hood, each helper starts a new Tracker.autorun. When its reactive dependencies change, the helper is rerun. So, helpers are reactive computations.
And then VM docs say: ViewModels are reactive **data sources**. That means you can use the properties and methods anywhere you would use a reactive source.
Whoa…
So, am I right saying that
VM props (and meths) can be used in Spacebars as helpers, but they do not substitute helpers.
VM meths don’t rerun even if they have a call to reactive data source inside.
And I don’t understand how can a function (VM method) be a reactive data source, not computation? What does that mean?
VM meths don’t rerun even if they have a call to reactive data source inside.
They do rerun when the reactive data source inside changes. This is as long as there’s an autorun that uses the VM method. If no one uses the VM method then it won’t rerun, even if the reactive sources inside change.
And I don’t understand how can a function (VM method) be a reactive data source, not computation? What does that mean?
“reactive source” is the shorthand used to mean a function that at some point calls .depend()/.changed() on a Tracker dependency object. You can have a “reactive source” without a Tracker dependency object but you rarely, if ever, see it in practice.
A computation is basically a function that keeps track of other functions (usually added with autorun) that need to re-run when the computation is invalidated (for practical purposes think of .changed() called on one of the dependencies.
Just want to say a big thank you to @manuel. I really enjoy working with ViewModel, especially version 2. Compared to “normal Blaze” it gives me a real structure and a more “component orientated” way of doing this. I’ve developed my last 2 projects with it and yeah, never thought that I could do it so fast and without any big struggle.
Yeah, I got it. I’ve to say that this “donation” function is a little bit hidden. I only got it because I wanted to see a video and there was a comment from Manuel that we need to subscribe.
@manuel, when I tell people about Viewmodel, I often notice them experiencing same issue with documentation.
As it is now, Viewmodel features are divided into three categories. But when you open any of them, you don’t see the others. You only see the link back which doesn’t really tell people anything.
So imagine that I talk with somebody on the net and this person struggles with state. What I do is I link them to https://viewmodel.meteor.com/docs/viewmodels#share and explain how it can help in a particular use case. But then we talk about Viewmodel and after some time or even many days I realize that they don’t even know that such features as bindings exist in Viewmodel. Because from the place where they entered documentation, there’s no list of them available, or even the link to bindings from the existing category.
It’s certainly better than it was before the last layout changes. But I believe it still could be more convenient to navigate, like f.e. on http://astronomy.jagi.io or at http://guide.meteor.com.
I don’t know if that was discussed earlier, but still worth asking - what are the possibilities that ViewModel will get official endorsement from MDG? I for one liked Blaze more than React/Angular and Blaze + ViewModel seems like an ideal solution for Meteor to me, because it was built specifically for Meteor, unlike React/Angular.
Can we get a comment about this from @sashko, @sacha or another MDG member? I personally think it would be very cool of Meteor officially endorsed this view layer and didn’t abandon Blaze altogether.
Also, I would like to take this moment to thank @manuel for his awesome work (I did subscribe to videos, least I can do). I’m really impressed about the pace of development of this package, he is closing Github issues much faster than they appear, which is outstanding. Please keep up the good work!
In this example the problem is {{>comment}}, it doesn’t include the template “comment”, because I’m having a property defined that is also called “comment”. So I’m running into an context issue. Is there any way to solve this? I only knew Template.dynamic but I also want to commit the commentData property to the comment template, without writing a helper for it (which I would need when I’ve to do Template.dynamic template=‘comment’ data=commentObjectHelper.
Docs say: Properties themselves can have properties and methods of their own. And: view model method 'this' always refers to the current view model.
But this code doesnt work
In your case reset isn’t a method of the view model, it’s a method of region. this.regionDropdown fails because this is the region object, which doesn’t have the regionDropdown property.