Well, most of freeware authors seem to be timid when it comes to asking for donations
@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!
Thanks. I’ll update the navigation system…
Note that @sacha doesn’t work at MDG, he is the editor of the popular book Discover Meteor.
Anyway, there is a thread here:
Hey, Manuel! Could you advise a simple pattern for a state machine using Viewmodel?
Same way you would with a normal JS object. Here’s the proverbial turnslide:
Template.turnslide.viewmodel({
locked: true,
push() {
if (!this.locked()) {
// Enter (do something)
this.locked(true);
}
},
insertCoin() {
this.locked(false);
}
});
The docs have another example using the enter binding.
@manuel I’m having an issue when a template has the same name like a VM property and I do something like this:
Answer.html
<div class="comments">
{{#if comments.count}}
{{#each comments}}
{{>comment commentData=this}}
{{/each}}
{{/if}}
<div class="write">
<textarea placeholder="Kommentar eingeben..." {{b "value:comment"}}></textarea>
<i class="ion-chatbubble-working" {{b "click:addComment,class:{text-primary:canSave}"}}></i>
</div>
</div>
VM:
Template.answer.viewmodel({
comment: null,
commentAstro: null,
canSave:false,
astro:{},
comments() {
return Comments.find({answerId: this.astro()._id}, {sort: {createdAt: 1}});
}
}
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
.
There is no way around it as you have a name collision. You have to rename one or the other. I rename the templates.
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
template(name='tpl')
.ui.dropdown($b= "ref: regionDropdown")
Template.tpl.viewmodel
region:
reset: -> @regionDropdown.dropdown('set text', 'some text')
onRendered: -> @region().reset()
Logs Cannot read property 'dropdown' of undefined
reset: => @regionDropdown.dropdown('set text', 'some text')
doesnt work neither, as it passes document
context instead of viewmodel.
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.
Yeah, I get this. So is there a way to make it work? Or there is no such notion as a child property for a viewmodel property?
I’d just put the reset in the view model, not in an object of a VM property. If you must then make a function out of region:
Template.tpl.viewmodel
region: ->
that = this
reset: -> that.regionDropdown.dropdown('set text', 'some text')
Wow, that’s clever
You should be able to use a fat arrow too:
Template.tpl.viewmodel
region: ->
reset: => @regionDropdown.dropdown('set text', 'some text')
yep, doing it right now! works nicely
btw, how do you make code colored in this forum?
I just use Markdown’s triple tick blocks.
Can we have multiple if
bindings on an element? Or multiple conditions for if
Use an expression “if: condition1 && condition2”