Easier ViewModels


#1

I’m toying with changes to the ViewModel package. With the upcoming version of Meteor (1.0.4) it’s going to be even easier to define the viewmodels. Check out the proposed changes and let me know what you think.

The summary is that instead of doing:

Template.leaderboard.created = ->
  this.vm = new ViewModel('leaderboard',
    players: -> Players.find {}, { sort: { score:-1, name: 1 }, fields: { _id: 1 } }
    selected: null
    addPoints: -> Players.update @selected(), { $inc: { score: 5 } }
  ).addHelper 'players', @
  
Template.leaderboard.rendered = ->
  this.vm.bind @
  
Template.player.rendered = ->
  new ViewModel(
    _id: this.data._id
    player: -> Players.findOne(@_id())
    select: -> @parent().selected @_id()
    isSelected: -> @parent().selected() is @_id()
    info: -> @player().score + ' ' + @player().name
  ).bind @

You would do:

Template.leaderboard.viewmodel
  players: -> Players.find {}, { sort: { score:-1, name: 1 }, fields: { _id: 1 } }
  selected: null
  addPoints: -> Players.update @selected(), { $inc: { score: 5 } }
, 'players'

Template.player.viewmodel (c) ->
  _id: c._id
  player: -> Players.findOne(@_id())
  select: -> @parent().selected @_id()
  isSelected: -> @parent().selected() is @_id()
  info: -> @player().score + ' ' + @player().name

#2

A bit offtopic, but I really wish your code examples were not in Coffeescript and your API wasn’t optimized for Coffeescript.


#3

Quadruple like!

I appreciate developers’ use of coffeescript but it is essentially javasript, the platform (meteor) is written in javascript, so it would benefit both the community and the package authors if they provided their documentation/examples/api at least with javascript counterparts.

Philosophically, I believe coffeescript should be used only internally and what’s facing the outside world should be whatever the standard is, in meteor’s case, javascript.

But again, I do like the viewmodel package and @manuel’s work, so kudos for taking the time in further improvin it for 1.0.4


#4

I’ll never understand the visceral reaction some people have towards Coffeescript since “it’s just Javascript” (minus the unnecessary crap) and no one’s taking their curly braces and semi-colons away (you can still use good old Javascript for everything).

I do find “it’s optimized for Coffeescript” to be funny because then all Javascript libraries are “optimized” for Coffeescript. Just take a look at a Meteor example:

Template.hangout.helpers({
  people: function() {
    return People.find();
  },
  fullName: function() {
    return this.first + " " + this.last;
  },
  greeting: function() {
    return "Hello " + this.first;
  }
});

and the Coffeescript counterpart:

Template.hangout.helpers
  people: -> People.find()
  fullName: -> @first + " " + @last
  greeting: -> "Hello " + @first

ZOMG! Meteor is optimized for Coffeescript!


#5

@manuel, I have to disagree. I don’t know CoffeeScript (and have no time to invest in it right now) and, because of that, there are packages I cannot use. ViewModel is anoying but ok. A better example is peerdb.


#6

I still don’t know why we’re even talking about Coffeescript since pretty much all examples in the documentation are in both Javascript and Coffeescript. Is it so hard to click the “Javascript” button in the code sections?


#7

Alright, real talk now, and keep in mind that I like the ideas of ViewModel and I do recommend it in all location people ask for 2-way data-bindings:

  • Last time I looked at ViewModel.meteor.com, it didn’t have examples in JS, only Jade + Coffeescript. This is completely unreadable to me, a person who kinda knows Coffee and uses Jade. I can read white-space sensitive languages easier if they are in my text editor (where I can make the tab size bigger, or highlight the indent) or if the language is actually well designed to be readable (like Python).
  • Last time I looked at the source, it had no comments or a high-level implementation documentation. I also had to compile the source to JS first, which is fine but is an extra step for your contributors.
  • I naturally assumed that the website didn’t change. It is incorrect to rely on our first impressions and not reevaluate the library later, but we all have so much time to spend on every project (sad but true).
  • By making coffee examples the default, you are cutting out a lot of people who don’t know coffee at all and people who don’t have a good coffee2js compiler in the backs of their minds running 24/7 (like me). It is in your interest to make the library easier to use and read for a wider audience of people, given that it is already limited to the audience of Meteor users.
  • Some of the examples are optimized for Coffee (or at least looked like that to me) because they overuse the @ symbol, which in JS code would be quite lengthy with this., they pack a long expression into one line, etc.

This block took me extra time to go to coffeescript.com, opening the online compiler, pasting this block and finally being able to understand that 'players' is the second argument to viewmodel method and is not a broken part of the object (the first argument). Also, notice how your long lines of packed expressions wrap over multiple lines making every indent a bit more confusing.

I appreciate the effort of building an interesting bindings library that I personally recommend to people. I also appreciate the efforts of putting up a website with examples and docs. But if you use coffeescript, be sure you are ready to face people who find it an absolute worst syntax that ever compiles to JS.


Plead to make github repo link and readme mandatory for packages
#8

You convinced me. I’ll make javascript the default when I update the docs for the upcoming release.


#9

As someone having this problem with documentation written in CS, I thank you for this.

Maybe I’d be able to read CS better if people used parenthesis when things are not clear, at least in documentation. It is supposed to be more readable than Javascript so any time the lack of parenthesis makes it harder to understand then defeats it’s purpose. In my case, I thought , 'players' was an argument to the Players.update method.


#10

It’s easier to write, not to read.


#11

I’ve always found .net developers’ aversion to Javascript to be quite peculiar. It’s not uncommon to see this “What? Javascript? Hell NO! (close tab)” attitude. I never thought Javascript developers would have the same attitude towards Coffeescript.

Of all the things people could complain about (hating MVVM, 2-way data binding, view models, etc.), “How dare you use Coffeescript for your example!” didn’t cross my mind.


#12

@manuel I’d like to stress a few things I’m sure are shared by many others.

Your use of CS was something like the elephant in the room. Your work is both open and good so we would not dare bring our frustration up, mostly out of respect. So I see this thread as a relief to long repressed emotions :wink:

CS vs JS is pure preference. I’m aware that there is long history of flame wars on that topic, but the outcry in this thread reflects none of that. Mostly, pure frustration from people who prefer JS against not being able to follow documents and examples provided solely or even primarily in CS (and perhaps even jade and stylus)

For those who come from languages like python, cs might be great, but for those who mentally perceive code structure through braces and such, cs may come as a mistery that is hard to grasp. And for many of us, embracing a javascript-only environment by itself is a huge leap of faith. Perhaps we are not yet ready for coffeescript.

So there; it is not a “how dare you” against cs rather a “pretty please” for js.


#13

:-1: for coffeescript. jokes aside, I think this is an awesome package. Having tried to build an app with Angular + Meteor, I can’t wait to give this a shot. I’m so excited I did a quick write up: http://stlouiswebservices.com/meteor-2-way-data-binding/


#14

Thank you @manuel!
With all the due respect for the great work you and other Meteor hackers do, I gladly agree with @slava and others that CoffeeScript is not very well designed for reading. The Zen of Python.

Dear package authors, if you want to make it easier for people (and organizations) to adopt your work and contribute, then please make it [both the source & docs] easy to read and comprehend (one of the core goals of the Open Source), especially in view of security issues with the community packages.