Yeah, the MVVM pattern definitely goes against traditional web SOC in favor of
a more pragmatic separation of business and interface logic, ie what JavaScript
runs my app vs what JavaScript runs my dom. This is especially useful when
generating multiple items from a template and having the click events,
show/hide, etc logic be added/removed for you. Click handlers can be done (and
more efficiently) through event handlers, but it is nice to be able to look at
the html and have a better idea of the actual user interface behavior.
> <div data-bind="visible: hasClickedTooManyTimes">
> That's too many clicks! Please stop before you wear out your fingers.
> <button data-bind="click: function() { numberOfClicks(0) }">Reset
> clicks</button>
> </div>
Ideally you wouldn't want to use this inline function for the reset and would
instead...
viewModel.reset = function () {
this.numberOfClicks(0);
};
<button data-bind="click: reset">Reset clicks</button>
The advantage, then is if you need to change the logic for resetting you change
it in your reset function in the viewModel. Or, when you need to change it
from a button click event to a hover event of something else, you just change
your bindings.
> The naming strategy for data- attributes seems simplistic and likely to have
> collisions with similar schemes.
KO only uses "data-bind", as far as attributes go, and then has a
bindingHandlers object internally which provides the usable
properties/actions/events to which you can bind, so you're limited to the same
type of naming collisions you see in any plugin system. Binding the click
event to an observable is done via addEventListener so you can use it alongside
other code that requires click if you need to.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
