defunctzombie
commented
10 years ago @visionmedia @MatthewMueller @ianstormtaylor @anthonyshort
As I am looking through these changes and the current codebase, I am questioning the need for Reactive#use and instead leaning towards a single options object to the Reactive constructor. Having a fluent api for the initial setup doesn't make sense here since we do the initialization once and bind on creation. So the .use has limited appeal to me. The alternative is to have some sort of .end like function which would actually trigger binding to occur or something.
One advantage I see to this is lazy-loaded instances where a user wouldn't call .end (or whatever it is named) until they are actually ready to render/display; but you can do that now by not instantiating anyhow. Having a .end does mean tho that a newly created Reactive instance is useless and won't do anything without a .end call. I dislike this because it just makes it that much more annoying to use in the simple case. Without a .end, we are back to the options object to pass things like custom Bindings, Adapters, etc. I like the idea of some sort of options object existing anyhow, the question is just where and how to include it in the workflow. One thing that I know for sure is that a Reactive instance needs to have the dom element (or string) to render. Everything else is optional (model, views, bindings).
ianstormtaylor
NOT FOR MERGE
This PR is for tracking progress on what will become reactive v1 (once all parties have agreed and code is in a happy place). Lots of this will be lessons learned and code I have already written in a different branch that I will port over to this one cleanly. Ordered by what should be done to make items further down possible.
fnon immediate call of Binding.change.If you would like to see additional features, please comment on them here and if accepted I will add to the list for v1 target.