Binding handlers are defined by adding objects to the ko.bindingHandlers object, just like extenders. They are composed of an init and an update function.

The init function runs when the binding is first applied to the element either when ko.applyBindings is called or when the element is created by a control flow binding, such as template or foreach. It should be used for all one-time work such as attaching event handlers or disposal callbacks to the element.

The update function runs just after init does, when the binding is first applied. It runs again anytime when any observable dependencies are changed. The update function determines its dependencies just like a computed observable does. If an observable is accessed when an update runs, it subscribes to that observable. The update function should be used to keep the UI in sync with changes from the viewmodel:

ko.bindingHandlers.yourBindingName = {
    init: function(element, valueAccessor, allBindings, viewModel...

Binding handlers can range from very simple to whole applications by themselves. As the purpose of binding handlers is to translate between the presentation layer (HTML) and the viewmodel (JavaScript), the binding handler's complexity is directly related to the complexity of the UI interaction and the bound data. Simple tasks such as hiding or showing an element with animation will have very thin handlers, while data binding on an interactive map element will require much more logic.

ko.bindingHandlers.slideVisible = {
    init: function(element, valueAccessor...

So far, we've been looking at binding handlers that handle one or two properties and result in a fairly simple single-purpose control. In the previous example, we started looking at binding handlers that created new child elements, and this technique allows us to create much more complex binding behaviors. Bindings can also interact with complex elements such as charts or map controls (for example, a Google Maps widget), providing a clean API that the viewmodel can interact with.

In the first chapter, we spoke about containerless bindings; bindings applied through comments that created a virtual container around their "child" nodes. Now that we have a good understanding of how to create our own binding handlers, it's time to learn how to make them containerless bindings.

First, we are going to make a normal binding and then look at what we need to do to allow it to support the virtual elements. Let's say you want a binding that sorts its children elements. It would need to loop through them, check some property, and then rearrange the DOM so they were in order. Normally, sorting would be achieved by using a foreach binding against a sorted observableArray property, but we're going to make a sort binding that sorts on the width of the DOM node, which takes into account any CSS that may have affected it. The viewmodel would have a hard time getting this information to determine the proper sort order...

If you take away one thing from all these examples, it should be that binding handlers are solely responsible for interaction with the DOM. In our first example, we made the slideVisible binding as an animated replacement for the standard visible binding. This change from the normal "instant" hide and show to the "animated" hide and show was completely decoupled by our viewmodel. This is beneficial because it keeps these two pieces completely separated, allowing them to develop and evolve independently.

In this chapter, we covered simple and complex binding handlers, binding context management, and using the virtual elements API to support containerless bindings. In the next chapter, we will be looking at preprocessors for bindings and nodes.