Viewmodel is overhead?

[comerc]

Q: I think we should also start thinking about making the Viewmodel approach the standard in Meteor -- currently people are still wiring up events and templates manually. We already have a few packages in regards to viewmodels https://github.com/dalgard/meteor-viewmodel and http://viewmodel.meteor.com

A: I really disagree with the idea of making Viewmodel standard. The beautify of Meteor has always been that it doesn't make decisions for you. There are plenty of bad view model implementations (including viewmodel.meteore.com which is buggy, slow, and doesn't play nicely with blaze, doesn't "interop" as it were). There are plenty of options for what you tack onto the MV* that meteor is, and components and view models are among them. What I love about flow components (and possibly blaze components) is that I can write all the behavior in actions, and then just call the right actions from events. Now the event is just a binding. Making a specific type of view model standard tells newcomers to the platform that Meteor is MVVM not MV*

A: I'm also leery of baking any MVC assumptions into the next iteration of Blaze. One of the strengths of the component approach is that it's agnostic to one's MVC interpretation; and works equally well with client-side interpretations as it does server-side interpretations. The Blaze.View() API is bad enough, and has caused all sorts of problems and misinterpretations and headaches. And while the viewmodel package may have some good technology in it; for some of us, using it's API is like using a camera-obscura, where everything is flipped upside down. Some of us prefer to design our apps using CSS as our View, since CSS manages what gets rendered out of the ViewPort and exposes controls for all the opthamology/photonic features, such as color space, opacity, pixel density, media queries, etc. You know, the stuff that gets rendered onscreen and blasted into a user's eyeballs and that they view. In such a client-side interpretation, the dalgard:viewmodel package is misnamed rather badly, and simply a state-controller.

A: ViewModel doesn't play nice with models returned from collections. ViewModel is good for like a web form that only sends an email. If you are rendering models, perhaps to update them, you actually create more work for yourself by using ViewModel than by using your models with AutoForm. The reason is you get the data out of the form via 2 way binding, but it's only in the state of the ViewModel component. Now you still gotta pass it to your actual model. ViewModel is overhyped. It's only good for the simplest least dynamic of use cases. Any time you use real models from the database you need a slightly lower level of abstraction, but if used properly (i.e. as just described) you actually have a lot less work than if you used ViewModel.

https://meteor.hackpad.com/Proposal-for-Blaze-2-bRAxvfDzCVv#:h=Viewmodel

My actual favorites: https://github.com/themeteorites/blaze-magic-events https://github.com/peerlibrary/meteor-reactive-field + 'this' inside helpers & events

[ManuelDeLeon]

What's the question?

[comerc]

I want to try viewmodel, but I'm afraid, that wrong choice with overhead code. AutoForm makes life easier at the prototype stage, but has restrictions of customization. I'm looking for the best tools for the replacement of AutoForm.

[ManuelDeLeon]

The thing is that this isn't a replacement for Autoforms. ViewModel doesn't generate any code for you. It just simplifies the way you develop your UI. It's a different way of doing things; one that requires less plumbing. I've never used Autoforms, mainly because I've never felt the need, but I've heard people say they've stopped using Autoforms after using ViewModel for a while.

[ManuelDeLeon]

In summary, if you're looking for some kind of code generator then this isn't it.

[comerc]

I know that ViewModel doesn't generate any code for me. I'm going to go the other way. :)

[ManuelDeLeon]

Then try it. Pick any template of your application and rewrite it using ViewModel. You'll see that your code will be cut in half. Let me know if you have questions when converting the code. On Apr 13, 2016 5:04 PM, "comerc" notifications@github.com wrote:

I know that ViewModel doesn't generate any code for me. I'm going to go the other way. :)

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ManuelDeLeon/viewmodel/issues/230#issuecomment-209684730

[comerc]

The question is whether the tools needed to facilitate the development, or they interfere with the development. For example. I was very attracted to this package in its simplicity, but this question adds complexity to my code. But you have solution to this issue.

[comerc]

I just would like to know your opinion on the remarks cited at the beginning of this topic.

[comerc]

I'm sorry, I found a great example. This will help me.

[ManuelDeLeon]

Let's see, where to start...

The objections on that thread are made by people who misunderstand the role of ViewModel. They seem to think it's an MVC framework for Meteor. One is complaining about models (M in MVC, which has almost nothing to do with ViewModel ). The other one is railing against MVC (which ViewModel is not).

As for events, you're certainly free to use them but you'll find that it's cleaner and simpler to declare the events in the markup. On Apr 13, 2016 5:42 PM, "comerc" notifications@github.com wrote:

I'm sorry, I found a great example https://github.com/ManuelDeLeon/phonebook. This will help me.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ManuelDeLeon/viewmodel/issues/230#issuecomment-209692111

[ManuelDeLeon]

Btw, if it means anything, I've never heard of anyone doing a project with ViewModel and then going back to Blaze. The only people who stopped using it are the ones who needed SSR and switched to React. On Apr 13, 2016 6:11 PM, "Manuel De Leon" manueldeleon@gmail.com wrote:

Let's see, where to start...

The objections on that thread are made by people who misunderstand the role of ViewModel. They seem to think it's an MVC framework for Meteor. One is complaining about models (M in MVC, which has almost nothing to do with ViewModel ). The other one is railing against MVC (which ViewModel is not).

As for events, you're certainly free to use them but you'll find that it's cleaner and simpler to declare the events in the markup. On Apr 13, 2016 5:42 PM, "comerc" notifications@github.com wrote:

I'm sorry, I found a great example https://github.com/ManuelDeLeon/phonebook. This will help me.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ManuelDeLeon/viewmodel/issues/230#issuecomment-209692111

[comerc]

As for events, you're certainly free to use them but you'll find that it's cleaner and simpler to declare the events in the markup.

But I still may use true 'this' of ViewModel instead of Template.instance().viewmodel.myValue() in my ViewModel methods!