dalgard / meteor-viewmodel

Minimalist VM for Meteor
24 stars 2 forks source link

Improvements needed? #17

Closed KoenLav closed 8 years ago

KoenLav commented 8 years ago

Hi dalgard,

We're going to use your viewmodel instead of manuel's in one of our projects and I was wondering whether there are any improvements which need to be made? (Or are you content with the current feature set?)

I'd be happy to contribute.

dalgard commented 8 years ago

Thanks for your interest and for volunteering.

I'm actually quite content with the current API and feature set. What I find most powerful is creating custom bindings. I recommend using them for components and other functionality that should be encapsulated in a single element (take Pikaday as an example).

I don't expect there to be any more changes before version 1.0.0, but still want to wait a bit before bumping it.

Your feedback will be welcome, together with any questions.

KoenLav commented 8 years ago

Thanks for your quick reply.

I'll be sure to let you know if we run into anything, but so far it's worked great!

dalgard commented 8 years ago

Will you be using Jade in your project?

The reason I'm asking is that my Jade fork, which has improved syntax for bindings, is currently a bit behind – I need to make some decisions about whether to follow mquandalles version in regard to one or two features. Or whether to try to merge my improvements back into the main repo.

KoenLav commented 8 years ago

We will be using the default Blaze rendering engine.

dalgard commented 8 years ago

:+1:

daveeel commented 8 years ago

Hi @dalgard , I'm currently using Manuel's VM and your Jade package for using $b for Manuel's new binding syntax. Just curious, how much behind is your Jade fork? Ideally one Meteor Jade package is preferred.

dalgard commented 8 years ago

@daveeel: I think that it's mainly one feature that has been added to mquandalles package since I last pulled from it. I don't think there are any important bug fixes, but will have to look further into it.

I agree that one package is much preferred and will try to sync and possibly merge in the near future.