Writable computed observables

Beginners may wish to skip this section - writable computed observables are fairly advanced and are not necessary in most situations Normally, computed observables have a value that is computed from other observables and are therefore read-only. What may seem surprising, then, is that it is possible to make computed observables writable. You just need to supply your own callback function that does something sensible with written values. You can use a writable computed observable exactly like a

with binding

Purpose The with binding creates a new binding context, so that descendant elements are bound in the context of a specified object. Of course, you can arbitrarily nest with bindings along with the other control-flow bindings such as if and foreach. Example 1 Here is a very basic example of switching the binding context to a child object. Notice that in the data-bind attributes, it is not necessary to prefix latitude or longitude with coords., because the binding context is switched to coords. &

visible binding

Purpose The visible binding causes the associated DOM element to become hidden or visible according to the value you pass to the binding. Example <div data-bind="visible: shouldShowMessage"> You will see this message only when "shouldShowMessage" holds a true value. </div> <script type="text/javascript"> var viewModel = { shouldShowMessage: ko.observable(true) // Message initially visible }; viewModel.shouldShowMessage(false); // ... now it's hidden view

Virtual elements

Note: This is an advanced technique, typically used only when creating libraries of reusable bindings. It’s not something you’ll normally need to do when building applications with Knockout. Knockout’s control flow bindings (e.g., if and foreach) can be applied not only to regular DOM elements, but also to “virtual” DOM elements defined by a special comment-based syntax. For example: <ul> <li class="heading">My heading</li> <!-- ko foreach: items --> <

value binding

Purpose The value binding links the associated DOM element’s value with a property on your view model. This is typically useful with form elements such as <input>, <select> and <textarea>. When the user edits the value in the associated form control, it updates the value on your view model. Likewise, when you update the value in your view model, this updates the value of the form control on screen. Note: If you’re working with checkboxes or radio buttons, use the checked bindi

uniqueName binding

Purpose The uniqueName binding ensures that the associated DOM element has a nonempty name attribute. If the DOM element did not have a name attribute, this binding gives it one and sets it to some unique string value. You won’t need to use this often. It’s only useful in a few rare cases, e.g.: Other technologies may depend on the assumption that certain elements have names, even though names might be irrelevant when you’re using KO. For example, jQuery Validation currently will only validate

textInput binding

Purpose The textInput binding links a text box (<input>) or text area (<textarea>) with a viewmodel property, providing two-way updates between the viewmodel property and the element’s value. Unlike the value binding, textInput provides instant updates from the DOM for all types of user input, including autocomplete, drag-and-drop, and clipboard events. Example <p>Login name: <input data-bind="textInput: userName" /></p> <p>Password: <input type="password"

text binding

Purpose The text binding causes the associated DOM element to display the text value of your parameter. Typically this is useful with elements like <span> or <em> that traditionally display text, but technically you can use it with any element. Example Today's message is: <span data-bind="text: myMessage"></span> <script type="text/javascript"> var viewModel = { myMessage: ko.observable() // Initially blank }; viewModel.myMessage("Hello, world!

template binding

Purpose The template binding populates the associated DOM element with the results of rendering a template. Templates are a simple and convenient way to build sophisticated UI structures - possibly with repeating or nested blocks - as a function of your view model data. There are two main ways of using templates: Native templating is the mechanism that underpins foreach, if, with, and other control flow bindings. Internally, those control flow bindings capture the HTML markup contained in your

submit binding

Purpose The submit binding adds an event handler so that your chosen JavaScript function will be invoked when the associated DOM element is submitted. Typically you will only want to use this on form elements. When you use the submit binding on a form, Knockout will prevent the browser’s default submit action for that form. In other words, the browser will call your handler function but will not submit the form to the server. This is a useful default because when you use the submit binding, it’