Repository navigation
Merge Projects? #4
Description
Activity
Hi Sivli,
I think this could work. I like the idea of starting as simple as possible, with every property reactive unless a user specifies that they want it to be nonreactive. And I don't want to break the public API I have since I use it in a lot of apps (I think the
clean()method is pretty simple too).However, improving efficiency and functionality on the internals of the package is something I'm definitely interested in doing over time, and I would like to add some features as well.
Perhaps we could start working on a new branch? Could you come up with a simple list of things you think we could add and I'll try to get that together as well.
Thanks,
Jon
Great to hear Jon,
I have been doing a lot of thinking about whats the best way to tackle this. I have a few things I am doing all at once but I feel they are all inter connected. For example Meteor and Migrations makes me want to start up reactive-schema again, which depends on reactive-objects.
However I feel a selling point of your package is its clean simplicity. Maybe the best option is adding hooks into yours and me building a reactive-object-extended package that adds logic like "is changed" and "restore defaults". I am definitely working on that list but I may post it on Kadira Hub and add a link to it here. Assuming you have no issues?
@jonjamz I like what you did here. Your code here is a lot cleaner then mine over in reactive-objects. Do you have any interest in merging them into one? I am thinking keep your code but add more helpers, like
ReactiveObjects.isReactiveProperty.Its also worth noting that http://docs.meteor.com/#reactivevar_pkg offers "setting the value to the same value as before has no effect", which I feel could be added an object to object setting.
I also always wanted to add something like an
isChanged?boolean on a property level. That would make doing reactive validations a lot easer.Thoughts? Ether way I expect to keep working on this so let me know as you can.