I am new to web development and have just started using/learning javascript and so my knowledge is limited, to say the least. But isnt what you are saying easily achievable through backbone.js.(by calling a set on a model and triggering an event which the view catches and updates itself.)
Just to be clear -- the Backbone.js "party line" is that automatic 2-way binding between views and models is usually undesirable.
The model contains the "truth" -- the current state of the app. Views should be bound to models and automatically update when the model changes.
But when the view changes, the reverse is not the case. You don't want every checkbox click, radio button twiddle, and keystroke to be causing your model to change ... thereby emitting changes which may cause other pieces of your app to re-render, changes which may cause Ajax requests to persist the model state to the server, and so on.
Instead, most apps have a "save" button for some changes, a mouse click for others, or drag and drop, or a gesture, or an "undo" link.
It's much more convenient and flexible to allow your app to react to DOM events as it needs to, instead of having specific model attributes hard-bound to concrete DOM elements. ... that said, if the latter is your cup of tea, there's a plugin for that.
It took me a while to figure it out, but the model concept in Backbone doesn't completely correspond to the model concept in Amber.
Backbone, at least as I practiced it, has a model that very closely corresponds to what goes over the wire. You observe stuff on that, you react to events, the event observers react and update the model and as a result the model is sent over ajax.
Amber, again as I practice it, has a model that corresponds to the complete application state of a particular component of the page. If you have a checkbox that doesn't 1-1 match with something you'd send to your server, you create an attribute on your model purely to track the state of that checkbox and wire up observers to update the appropriate "real" attributes you're sending to the server. This is not immediately apparent when looking at the two frameworks but I find the difference to be crucial.
I started using backbone the day you open sourced it since I had a personal version of more or less the same thing that was twice the code and less elegant. I found that it was fantastic as long as you could do idempotent DOM updates (i.e. innerHTML) but got lost as soon as I wanted to start adding sub components that needed to be initialized and I was back to dealing with a lot of event twiddling and dom manipulation for updating the view. I believe the split in state between the DOM and application model causes this complexity which is avoided in Amber by having all client side application state in one place. I think I could apply the same ideas in Backbone but I haven't tried since switching over.
Neat. Do you have any open-source examples of this simpler "client side application state in one place" up on GitHub? I'd love to take a peek.
I think that I'd tend to agree with your interpretation -- you write:
> [In Amber] If you have a checkbox that doesn't 1-1
> match with something you'd send to your server, you
> create an attribute on your model purely to track the
> state of that checkbox ...
That sort of approach would be against the Backbone "party line". A large part of the point is to have your canonical state for a given resource in one place: the model. If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.
The allAreDone propery. It's not something you'd have in the canonical data you'd send to/from the server but exists as a property so it can be observed and so the template bindings can manipulate it.
> If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.
The model is more checkboxy but the checkboxy bits are initialized from the canonical bits and your sync equivalent has to strip them back off. This is annoying but less annoying than DOM twiddling.
I would like to strongly agree with your statement about idempotent DOM updates v. subcomponents. This question (re-render entire unit or manually sync model changes with individual jQuery dom changes) is one of the first things I try to think through when using JS MVC patterns. It is a huge pain when you have nested controls for nested models.
This is dead on, however I say it's a client code implementation detail that the object the view is bound to is the same one other parts of the app are bound to. Two way bindings about marshalling data out of the dom into JS land, and unfortunately developers seem to pick the wrong JS land object to store the view data in: the model. The model is best viewed as the client's best understanding of what is on the server: the canonical state of the modeled object in the world. Changing the value of inputs doesn't change the state of the object in the world until you press the save button. You do still want a canonical place for view bindings to bind to, so that different views of the same object are guaranteed to stay in sync (think the slug in an index as well as the detail view in a show action), and I say its not worth sacrificing this guarantee because we can't structure our code around binding to non-canonical representations. This suggests the edit views should be bound to something which knows how to apply itself to the model, so that upon saving, the canonical place can remain as such and updates with the new data.
In Batman we really want to make this other object a reality and have been scheming about "draft" versions of models for quite a while, but still haven't quite nailed down how to do it when things like associated objects enter into the mix.
> Changing the value of inputs doesn't change the state of the object in the world until you press the save button
This is key. If the UI is linked, checkbox by checkbox, field by field, to the model, then we've created the brittle situation where the user is, in effect, directly manipulating the "business objects". Such a scheme ends up imposing (at least) implicit design constraints when modeling the app (steering the developer away from the best or most logical decisions when they would make the rigidly linked view layer unwieldy), and similarly shackling the UX design to the model setup. Which makes for a worse app. These should be related but separate concerns; a smart user experience will require some logic, marshalling, and abstraction.
I think what you've pointed out is true. Once I learned BB, I've always felt like I had to decide between fast views with KO, or scalable logic with BB. When the modelbindings plugin came into my life, I was super excited to potentially have the best of both worlds.
It was immediately obvious to me, the downsides you suggested. In my simple case it was an append interface, not an edit interface, so I stubbornly worked around it by creating orphaned models that are bound to my user editable view, and then get added into the app focused collection once submitted.
> thereby emitting changes which may cause other pieces of your app to re-render, changes which may cause Ajax requests to persist the model state to the server, and so on.
Hmm, really that sounds like poor application design than anything else.
I mean to me in an MVC binding the View to the Model bot ways is critical. The Model should be smart enough to track changes and only persist them on specific request.
And your app code should say "hey Model, I am going to query the server now - are you saved?" or "Hey - I have this new data timestamped X, or do you have something more recent?".
... sure, it depends. But there are even more reasons than over-propagation of change events to avoid strict two-way model/view binding.
One of them is that the data often isn't the same. The view displays a computed value from the model, and the model should receive the "real" value upon a change. For example:
When the DOM element is chosen, the model's value should be "article", not "NYT Article" ... and perhaps the change should happen immediately, and perhaps the change should happen only after a "Save" button is clicked.
With concrete two-way binding, you may spend more time configuring all of your DOM elements, and configuring when your models should be considered "changed", and when they shouldn't -- than you gain by tying them together in the first place.
These are simple changes to make under Knockout.js and I assume Amber.js too. It's easy to see how to do this from the Knockout.js tutorial. A model/view binding system won't slow these kinds of customizations down.
But that situation is already solved in the MVC world; with filters, callbacks and validation.
Having just finished a pretty complex "application" of this sort (which cannibalized Knockout to get what I needed...) my view is that most stuff does not need any sort of filtering. Or if it does (and the big example I could give here would be timestamps) a lot of the filtering can be standardised.
I have found you can get the best of both worlds by building a smarter model layer. For example, if your models are inherently versioned, you can just fork off a new version and then either commit it or discard it.
Meanwhile the view gets to have really rich two-way interaction with the model, which is a big win for keeping presentation logic and model logic separate.
As an example: whenever the value of one field alters the available choices for another field, it's better to capture that logic in the model. Then you can write a view that focuses only on how to display choices, not which choices need to be displayed.
In SproutCore 1.x you have SC.NestedStore, which allows a transaction-like experience where the checkbox in your case can be wired to a property on a model instance (or controller representing the same) that is derived from this nested store. This way your changes are not to the main instances of your model, but to alternate instances in a nested transaction-like state.
I agree with the same philosophy (or the very least have the ability to control the symmetry of the binding). I have been working on a binding library that allows you to have control over the binding (one-way, two-way) and which objects can be observed. It is simply a framework for defining hooks which provide APIs for defining channels (bindings) between various objects. There are hooks for jQuery, Zepto, Backbone, and plain objects: http://bruth.github.com/synapse/docs/
Absolutely -- the bit that we're discussing is one of the areas where SC 2.0 / Amber diverges, and more importantly is the heart of Yehuda's claim that "if you’re a Backbone fan, I think you’ll love how little code you need to write with Amber".
Personally, I see no problem with two-way bindings to views. If your app is well architected it should be able to handle those changes. That said, it's not difficult to set up a buffer to store changes until you "save", if that's what's desired.
Sure, but if I only want certain pieces of the view to update when their corresponding model value changes, as opposed to re-rendering the whole view, I have to build an update method that does so. Not horrible in the scheme of things, but awful nice to not build manually. Is Amber.js essentially re-rendering views in their entirely, or is it more precise with its binding updates?
Another difference I suppose would be binding classnames and attributes to your model may require several lines of jQuery to manipulate, vs I believe in amber.js its done by naming convention and an options object (to use different class names).
i am currently developing a library [0] that separates `what you want to do` from `what should actually happen`.
so if you have a model with some changing attributes you can write your view like this:
class View extends Backbone.View
template: (api) ->
new dynamictemplate.Template schema:'html', ->
@div class:'item', ->
@text 'default'
api.bind 'type', (type) =>
@attr 'class', type # changing the class to the new type
api.bind 'content', (content) =>
@text content
@end()
render: () ->
api = {}
_.extend(api, Backbone.Events)
@model.bind 'change:type', (model, type) ->
api.trigger 'type', type
@model.bind 'change:content', (model, content) ->
api.trigger 'content', content
tpl = @template(api)
tpl.on 'end', -> # when the rendering is done
@el = tpl.jquery # fresh build dom element by jquery
$('body').append(@el) # add it to the dom
if you want to use this you have to run render only once.
now every time the model changes the event handlers in the templates get triggered and updating it too, but what happens is that jquery sets the attribute class or the text of the div.
if you don't like to write _all_ your templates as functions i'm currently writing a tool for this library where you can use an already working html file to mask the functions, so you have to write only a subset of the resulting design but getting the full output:
now if you emit the 'content' of 'api' the text of <div class='item'> gets updated by jquery. note that you don't have to write the class attribute because the tag name is already matching, but the result will have the class='item' attribute.
i really don't know if this solves the actual problem or but i really would love to see others thinking about how to solve it (or help me getting on with this lib :P).
i allready have some ideas about writing a debug tool where every html tag that you write as function gets an special border which highlights when you change the properties like setting text and attribute or by adding new tags (look at the demo where i add tags after the templates is rendered).
ps: i hate using the data-* attribute to hook models to the dom because thats first totally ugly and second the designer doesn't want to touch it (and shouldn't! because it is _not_ part of the design).
