ViewModel 2 - A new level of simplicity

Well, most of freeware authors seem to be timid when it comes to asking for donations :blush:

@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 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 or at

1 Like

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…

1 Like

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:

  locked: true,
  push() {
    if (!this.locked()) {
      // Enter (do something)
  insertCoin() {

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:


<div class="comments">
        {{#if comments.count}}
            {{#each comments}}

                {{>comment commentData=this}}

     <div class="write">
            <textarea placeholder="Kommentar eingeben..." {{b "value:comment"}}></textarea>
            <i class="ion-chatbubble-working" {{b "click:addComment,class:{text-primary:canSave}"}}></i>



comment: null,
commentAstro: null,

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

  .ui.dropdown($b= "ref: regionDropdown")

    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:

  region: ->
    that = this
    reset: -> that.regionDropdown.dropdown('set text', 'some text')

Wow, that’s clever :thumbsup:

You should be able to use a fat arrow too:

  region: ->
    reset: => @regionDropdown.dropdown('set text', 'some text')
1 Like

yep, doing it right now! works nicely :smile:

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”