Hello! Are you currently developing with Knockout? Much has changed in the landscape of client-side libraries since Knockout was considered a popular choice, but there still seem to be many successful projects using it today. I would love to hear about the interesting things that you are building with Knockout in 2019.

For the last several years, I have been working with React on the front-end (and Node on the server-side) while working on LeanKit. So, while I have been having lots of fun with JavaScript, I haven’t had a chance to do anything new with Knockout lately. I would really enjoy spending time getting caught up and helping out in the Knockout world.

Looking for feedback on these questions:

• What would be useful for me to spend some time on?
• What are your biggest challenges with Knockout in 2019?
• Are there new plug-ins that could be created to solve a problem?
• Should I update many of my existing libraries to have modern code and a up-to-date build system?
• Any other ideas come to mind?

Reply in the comments or send me an email at ryan@knockmeout.net. Thanks!

In this release cycle, we welcomed Brian Hunt to the core team and he has brought some great energy and contributions to the project. Steve and Michael once again made the bulk of the major changes in this release along with a number of other pull requests from the community.

Components refinements

We received lots of great feedback regarding Knockout’s component functionality. Many developers seem to be having great success using this style of development. For 3.3, we focused on a few low-level enhancements that should provide some increased flexibility.

Synchronous Flag

Components were always rendered asynchronously previously, even when the template/viewModel were already cached. Now, the component registration can include a “synchronous” flag to indicate that the component should render synchronously, if it can. In the case where you have many nested components, this can help alleviate issues with reflows and/or flickering while rendering. The syntax would look like:

1
2
3
4
5

ko.components.register("my-component", {
    template: "<div data-bind=\"text: firstName\"></div>",
    viewModel: { require: "myModule" },
    synchronous: true
});

Working with component child nodes

In Knockout 3.3, you now have options for working with the child nodes contained inside of a component. There are three enhancements that go together targetting this area:

1- The template binding can accept an array of DOM nodes directly via a nodes option

2- If you are using a createViewModel function for your component, it will now receive the child nodes and you can determine how to expose them on your component’s view model for binding against the template binding

1
2
3
4
5
6
7
8
9
10
11
12
13
14

ko.components.register("accordion-item", {
    template: "<h2 data-bind=\"template: { nodes: headerNodes }\"></h2><div data-bind=\"template: { nodes: bodyNodes }\"></div>",
    viewModel: {
        createViewModel: function(params, componentInfo) {
            return {
                data: params.data,
                // grab the first node (as an array) for the header
                headerNodes: componentInfo.templateNodes.slice(0, 1),
                // grab any additional nodes for the body
                bodyNodes: componentInfo.templateNodes.slice(1)
            };
        }
    }
});

3- There is a new $componentTemplateNodes context variable that contains the nodes directly. In normal cases, this will allow you to avoid exposing DOM nodes in your view model and bind in the template directly.

For example, a component template might simply want to add some wrapping markup like:

1

<div class="my-component" data-bind="template: { nodes: $componentTemplateNodes, data: data }"></div>

You could then add the component to your page:

1
2
3
4
5

<my-component params="{ data: item }">
    <h1>My Data</h1>
    <p>Body one</p>
    <p>Body two</p>
</my-component>

If would still be possible to manipulate (slice) $componentTemplateNodes directly in the binding, depending on the complexity of the markup/scenario.

$component context variable

Sometimes inside of a component’s template, when looping through nested structures, you may want to bind up to the root of the component. Rather than trying to manage $parents[x], you can now use $component to get the nearest components root. This is a similar concept to $root for the entire application, but is specific to a component.

Other Enhancements

A few other enhancements that I think are interesting:

awake/sleep notifications from pure and deferred computeds

You can now subscribe to notifications from a pureComputed for when it wakes up and for when it goes to sleep (when nothing depends on it). Additionally, a deferred computed now notifies when it wakes up as well. The subscriptions would look like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

this.fullName = ko.pureComputed(function() {
    return this.firstName() + " " + this.lastName();
}, this);

this.fullName.subscribe(function(value) {
    console.log("fullName is awake with a value: " + value);
}, this, "awake");

this.fullName.subscribe(function() {
    console.log("fullName is sleeping" + value);
}, this, "sleep");

this.fullPhoneNumber = ko.computed(function() {
    return this.areaCode() + " " this.phoneNumber();
}, this, { deferEvaluate: true });

this.fullPhoneNumber.subscribe(function(value) {
    console.log("fullPhoneNumber is awake with a value: " + value);
}, this, "sleep");

Exposing a few additional functions to the release build

• ko.ignoreDependencies(callback, callbackTarget, callbackArgs) - executes a function and ignores any dependencies that may be encountered. This can be useful sometimes in a computed observable or in a custom binding when you want to execute code, but not trigger updates when any dependencies from that code change. You would use it like:

1

ko.ignoreDependencies(this.myAfterUpdateHandler, this, [true]);

• ko.utils.setTextContent(element, textContent) handles cross-browser setting the text of a node and handles virtual elements

Fixes

3.3 also includes a number of nice fixes and performance improvements listed here. This includes making the css binding work properly with SVG elements, which has been a long-standing issue.

Please check out Knockout 3.3.0 today! It is available from GitHub, the main site, Bower (bower install knockout), and NPM (knockout).

With the rise of single-page applications and increased complexity (and amount) of JavaScript on the client-side, memory leaks are a common occurrence. Knockout.js applications are not immune to these problems. In this post, I will review some scenarios that often contribute to memory leaks and discuss the APIs in Knockout that can be used to prevent and resolve these issues.

The main source of leaks in KO

Memory leaks in KO are typically caused by long-living objects that hold references to things that you expect to be cleaned up. Here are some examples of where this can occur and how to clean up the offending references:

1. Subscriptions to observables that live longer than the subscriber

Suppose that you have an object representing your overall application stored in a variable called myApp and the current view as myViewModel. If the view needs to react to the app’s language observable changing, then you might make a call like:

1

myApp.currentLanguage.subscribe(myCurrentView.languageHandler, myCurrentView);

What this technically does is goes to myApp.currentLanguage and adds to its list of callbacks with a bound function (languageHandler) that references myCurrentView. Whenever myApp.currentLanguage changes, it notifies everyone by executing each registered callback.

This means that if myApp lives for the lifetime of your application, it will keep myCurrentView around as well, even if you are no longer using it. The solution, in this case, is that we need to keep a reference to the subscription and call dispose on it. This will remove the reference from the observable to the subscriber.

1
2
3
4

myCurrentView.languageSubscription = myApp.currentLanguage.subscribe(myCurrentView.languageHandler, myCurrentView);

// somewhere later in the code, when you are disposing of myCurrentView
myCurrentView.languageSubscription.dispose();

2. Computeds that reference long-living observables

1
2
3

myCurrentView.userStatusText = ko.computed(function() {
    return myApp.currentUser() + " (" + myCurrentView.userStatus + ")";
}, myCurrentView)

In this case, the userStatusText computed references myApp.currentUser(). As in the subscription example, this will add to the list of callbacks that myApp.currentUser needs to call when it changes, as the userStatusText computed will need to be updated.

There are a couple of ways to solve this scenario:

• we can use the dispose method of a computed, like we did with a manual subscription.

1
2

// in disposal code
myCurrentView.userStatusText.dispose();

• in KO 3.2, a specialized computed called a ko.pureComputed was added (docs here). A pure computed can be created by using ko.pureComputed rather than ko.computed or by pasing the pure: true option when creating a normal computed. A pure computed will automatically go to sleep (release all of its subscriptions) when nobody cares about its value (nobody is subscribed to it). Calling dispose on a pure computed would likely not be necessary for normal cases, where only the UI bindings are interested in the value. This would work well for our scenario where a temporary view needs to reference a long-living observable.

3. Event handlers attached to long-living objects

In custom bindings, you may run into scenarios where you need to attach event handlers to something like the document or window. Perhaps the custom binding needs to react when the browser is resized. The target needs to keep track of its subscribers (like an observable), so this will create a reference from something long-living (document/window in this case) back to your object or element that is bound.

To solve this issue, inside of a custom binding, Knockout provides an API that lets you execute code when the element is removed by Knockout. Typically, this removal happens as part of templating or control-flow bindings (if, ifnot, with, foreach). The API is ko.utils.domNodeDisposal.addDisposeCallback and would be used like:

1
2
3
4
5
6
7
8
9
10
11
12
13

ko.bindingHandlers.myBinding = {
    init: function(element, valueAccessor, allBindings, data, context) {
        var handler = function () {
            // do something with element, valueAccessor, etc.
        };

        $(window).on("resize", handler);

        ko.utils.domNodeDisposal.addDisposeCallback(element, function() {
            $(window).off("resize", handler);
        });
    })
};

If you did not have easy access to the actual handler attached, then you might consider using namespaced events like $(window).on("resize.myPlugin", handler) and then remove the handler with $(window).off("resize.myPlugin").

4. Custom bindings that wrap third-party code

The above issue is also commonly encountered when using custom bindings to wrap third-party plugins/widgets. The widget may not have been designed to work in an environment where it would need to be cleaned up (like a single-page app) or may require something like a destroy API to be called. When choosing to reference third-party code, it is worthwhile to ensure that the code provides an appropriate method to clean itself up.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

ko.bindingHandlers.myWidget = {
    init: function (element, valueAccessor) {
        var myWidget = $(element).someWidget({
            value: valueAccessor()
        });

        ko.utils.domNodeDisposal.addDisposeCallback(element, function () {
            // or whatever code is necessary to clean-up the widget
            if (myWidget && typeof myWidget.destroy === "function") {
                myWidget.destroy();
            }
        })
    }
};

Reviewing the tools/API for clean-up in Knockout

1. dispose function. Can be called on a manual subscription or computed to remove any subscriptions to it.

2. ko.utils.domNodeDisposal.addDisposeCallback - adds code to run when Knockout removes an element and is normally used in a custom binding.

3. ko.pureComputed - this new type of computed added in KO 3.2, handles removing subscriptions itself when nobody is interested in its value.

4. disposeWhenNodeIsRemoved option to a computed - in some cases, you may find it useful to create one or more computeds in the init function of a custom binding to have better control over how you handle changes to the various observables the binding references (vs. the update function firing for changes to all observables referenced. This technique can also allow you to more easily share data between the init function and code that runs when there are changes (which normally would be in the updatefunction.

For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

ko.bindingHandlers.myBinding = {
    init: function (element, valueAccessor) {
        var options = valueAccessor();

        ko.computed(function () {
            var value = ko.unwrap(options.value);

            // do something with value
        }, null, { disposeWhenNodeIsRemoved: element });


        ko.computed(function () {
            var height = ko.unwrap(options.height);

            // do something with height
        }, null, { disposeWhenNodeIsRemoved: element });
    }
};

Note that the example is passing in the disposeWhenNodeIsRemoved option to indicate that these computeds should automatically be disposed when the element is removed. This is a convenient alternative to saving a reference to these computeds and setting up a handler to call dispose by using ko.utils.domNodeDisposal.addDisposeCallback.

Keeping track of things to dispose

One pattern that I have used in applications when I know that a particular module will often be created and torn down is to do these two things:

1- When my module is being disposed, loop through all top-level properties and call dispose on anything that can be disposed. Truly it would only be necessary to dispose items that have subscribed to long-living observables (that live outside of the object itself), but easy enough to dispose of anything at the top-level when some have created “external” subscriptions.

2- Create a disposables array of subscriptions to loop over when my module is being disposed, rather than assigning every subscription to a top-level property of the module.

A snippet of a module like this might look like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

var MyModule = function () {
    this.disposables = [];

    this.userStatus = ko.observable();

    this.userStatusText = ko.computed(this.getUserStatusText, this);

    this.disposables.push(myApp.currentLanguage.subscribe(this.handleLanguageChange, this));
};

ko.utils.extend(MyModule.prototype, {
    getUserStatusText: function() {
        return myApp.currentUser() + " (" + this.userStatus + ")";
    },

    handleLanguageChange: function(newLanguage) {
        // do something with newLanguage
    },

    dispose: function() {
        ko.utils.arrayForEach(this.disposables, this.disposeOne);
        ko.utils.objectForEach(this, this.disposeOne);
    },

    // little helper that handles being given a value or prop + value
    disposeOne: function(propOrValue, value) {
        var disposable = value || propOrValue;

        if (disposable && typeof disposable.dispose === "function") {
            disposable.dispose();
        }
    }
});

Conclusion

Memory leaks are not uncommon to find in long-running Knockout.js applications. Being mindful of how and when you subscribe to long-living observables from objects that are potentially short-lived can help alleviate these leaks. The APIs listed in this post will help ensure that references from subscriptions are properly removed and your applications are free of memory leaks.

Components allow you to combine independent modules together to create an application. For example, a view could look like:

1
2
3
4
5

<myapp-nav></myapp-nav>

<myapp-grid params="data: items, paging: true, sorting: true"></myapp-grid>

<myapp-footer></myapp-footer>

The idea of doing modular development with Knockout is certainly not a new one. Libraries like Durandal with its compose binding and the module binding from my knockout-amd-helpers have been doing this same type of thing for a while and have helped prove that it is a successful way to build and organize Knockout functionality. Both of these libraries have focused on AMD (Asynchronous Module Definition) to provide the loading and organization of modules.

Knockout’s goal is to make this type of development possible as part of the core without being tied to any third-party library or framework. Developers will be able to componentize their code, by default, rather than only after pulling in various plugins. However, the functionality is flexible enough to support different or more advanced ideas/opinions through extensibility points. When KO 3.2 is released, developers should seriously consider factoring components heavily into their application architecture (unless already successfully using one of the other plugins mentioned).

How does it work?

By default, in version 3.2, Knockout will include:

1. a system for registering/defining components
2. custom elements as an easy and clean way to render/consume a component
3. a component binding as an alternative to custom elements that supports dynamically binding against components
4. extensibility points for modifying or augmenting this functionality to suit individual needs/opinions

Let’s take a look at how this functionality is used:

Registering a component

The default component loader for Knockout looks for components that were registered via a ko.components.register API. This registration expects a component name along with configuration that describes how to determine the viewModel and the template. Here is a simple example of registering a component:

1
2
3
4
5
6

ko.components.register("simple-name", {
    viewModel: function(data) {
        this.name = (data && data.name) || "none";
    },
    template: "<div data-bind=\"text: name\"></div>"
});

The viewModel key

• can be a function. If so, then it is used as a constructor (called with new).
• can pass an instance property to use an object directly.
• can pass a createViewModel property to call a function that can act as a factory and return an object to use as the view model (has access to the DOM element as well for special cases).
• can pass a require key to call the require function with the supplied value. This will work with whatever provides a global require function (like require.js). The result will again go through this resolution process.

Additionally, if the resulting object supplies a dispose function, then KO will call it whenever tearing down the component. Disposal could happen if that part of the DOM is being removed/re-rendered (by a parent template or control-flow binding) or if the component binding has its name changed dynamically.

The template key

• can be a string of markup
• can be an array of DOM nodes
• can be an element property that supplies the id of an element to use as the template
• can be an element property that supplies an element directly
• can be a require property that like for viewModel will call require directly with the supplied value.

A component could choose to only specify a template, in cases where a view model is not necessary. The supplied params will be used as the data context in that case.

The component binding

With this functionality, Knockout will provide a component binding as an option for rendering a component on the page (with the other option being a custom element). The component binding syntax is fairly simple.

1
2
3
4
5

<div data-bind="component: 'my-component'"></div>

<div data-bind="component: { name: 'my-component', params: { name: 'ryan' } }"></div>

<!-- ko component: 'my-component' --><!-- /ko -->

The component binding supports binding against an observable and/or observables for the name and params options. This allows for handling dynamic scenarios like rendering different components to the main content area depending on the state of the application.

Custom Elements

While the component binding is an easy way to display a component and will be necessary when dynamically binding to components (dynamically changing the component name), custom elements will likely be the “normal” way for consuming a component.

1

<my-component params="name: userName, type: userType"></my-component>

Matching a custom element to a component

Knockout automatically does all of the necessary setup to make custom elements work (even in older browsers), when ko.registerComponent is called. By default, the element name will exactly match the component name. For more flexibility though, Knockout provides an extensibility point (ko.components.getComponentNameForNode) that is given a node and expected to return the name of the component to use for it.

How params are passed to the component

The params are provided to initialize the component, like in the component binding, but with a couple of differences:

• If a parameter creates dependencies itself (accesses the value of an observable or computed), then the component will receive a computed that returns the value. This helps to ensure that the entire component does not need to be rebuilt on parameter changes. The component itself can control how it accesses and handles any dependencies. For example, in this case:

1

<my-component params="name: first() + ' ' + last()"></my-component>

The component will receive a params object that contains a name property that is supplied as a computed in this case. The component can then determine how to best react to the name changing rather than simply receiving the result of the expression and forcing the entire component to re-load on changes to either of the observables.

• The params object supplied when using the custom element syntax will also include a $raw property (unless the params happens to supply a property with that same name) which gives access to computeds that return the original value (rather than the unwrapped value). For example:

1

<my-component params="value: selectedItem().value"></my-component>

In this case, since selectedItem is accessed, the param is supplied as a computed. When the computed is accessed, the unwrapped value is returned to avoid having to double-unwrap a param to get its value. However, you may want access to the value observable in this case, rather than its unwrapped value. In the component, this could be achieved by accessing params.$raw.value(). The default functionality is slanted towards ease of use (not having to unwrap a param twice) while providing $raw for advanced cases.

Custom loaders

Knockout let’s you add multiple “component loaders” that can choose how to understand what a component is and how to load/generate the DOM elements and data.

A loader provides two functions: getConfig and loadComponent. Both receive a callback argument that is called when the function is ready to proceed (to support asynchronous operations).

• getConfig can asynchronously return a configuration object to describe the component given a component name.
• loadComponent will take the configuration and resolve it to an array of DOM nodes to use as the template and a createViewModel function that will directly return the view model instance.

The default loader

To understand creating a custom component loader, it is useful to first understand the functionality provided by the default loader:

The default getConfig function does the following:

• this function simply looks up the component name from the registered components and calls the callback with the defined config (or null, if it is not defined).

The default loadComponent function does the following:

• tries to resolve both the viewModel and template portions of the config based on the various ways that it can be configured.
• if using require will call require with the configured module name and will take the result and go through the resolution process again.
• when it has resolved the viewModel and template it will return an array of DOM nodes to use as the template and a createViewModel function that will return a view model based on however the viewModel property was configured.

A sample custom loader

Let’s say that we want to create a widget directory where we place templates and view model definitions that we want to require via AMD. Ideally, we want to just be able to do:

1

<div data-bind="component: 'widget-one'"></div>

In this case, we could create a pretty simple loader to handle this functionality:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

//add a loader to the end of the list of loaders (one by default)
ko.components.loaders.push({
    getConfig: function(name, callback) {
        var widgetName;

        //see if this is a widget
        if (name.indexOf("widget-") > -1) {
            widgetName = name.substr(7).toLowerCase();

            //provide configuration for how to load the template/widget
            callback({
                viewModel: {
                    //require the widget from the widget directory with just the name
                    require: "widgets/" + widgetName
                },
                template: {
                    //use the text plugin to load the template from the same directory
                    require: "text!widgets/" + widgetName + ".tmpl.html"
                }
            });
        } else {
            //tell KO that we don't know and it can move on to additional loaders
            callback(null);
        }
    },
    //use the default loaders functionality for loading
    loadComponent: ko.components.defaultLoader.loadComponent
});

In this custom loader, we just dynamically build the configuration that we want, so we don’t necessarily have to register every “widget” as its own component, although registering will properly setup custom elements to work with the component. Loading the widget-one component would load a one.js view model and one.tmpl.html template from a widgets directory in this sample loader. If the component is not a “widget”, then the callback is called with null, so other loaders can try to fulfill the request.

Summary

Components are a major addition to Knockout’s functionality. Many developers have found ways to do this type of development in their applications using plugins, but it will be great to have standard support in the core and the possibility for extensibility on top of it. Steve Sanderson recently did a great presentation at NDC Oslo 2014 that highlighted the use of components in Knockout. Check it out here.

Knockout 3.2 is well underway and should be ready for release this summer.

I received a question over email asking about how Knockout’s dependency detection actually works and thought that I would share an answer in this post. I know that I feel a bit uncomfortable whenever a library that I am using does something that I don’t fully understand, so I hope that I can help ensure that this part of Knockout is not misunderstood or considered “magic”.

A few questions to answer:

1. For a computed observable, how does KO know which dependencies should trigger a re-evaluation of the computed on changes?
2. How is it possible for the dependencies to change each time that a computed is evaluated?
3. For bindings, how are dependencies tracked?

Determining dependencies for a computed

TLDR: Knockout has a middle-man object that is signalled on all reads to computed/observables and tells the current computed being evaluated that it might want to hook up a subscription to this dependency.

• Internally Knockout maintains a single object (ko.dependencyDetection) that acts as the mediator between parties interested in subscribing to dependencies and dependencies that are being accessed. Let’s call this object the dependency tracker.

• In a block of code that wants to track dependencies (like in a computed’s evaluation), a call is made to the dependency tracker to signal that someone is currently interested in dependencies. As an example, let’s simulate what a computed would call:

1
2
3
4
5
6
7
8
9
10
11

//a few observables to work with
var test = ko.observable("one"),
    test2 = ko.observable("two"),
    test3 = ko.observable("three");

//a computed internally ask to start tracking dependencies and receive a notification when anything observable is accessed
ko.dependencyDetection.begin({
    callback: function(subscribable, internalId) {
        console.log("original context: " + internalId + " was accessed");
    }
});

• Any read to an observable or computed triggers a call to the dependency tracker. A unique id is then assigned to the observable/computed (if it doesn’t have one) and the callback from the currently interested party is passed the dependency and its id.

1
2
3
4
5

//access an observable
test();

//output:
//original context: 1 was accessed

• The dependency tracker maintains a stack of interested parties. Whenever a call is made to start tracking, a new context is pushed onto the stack, which allows for computeds to be created inside of computeds. Any reads to dependencies will go to the current computed being evaluated.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

//start another dependency detection inside of the current one
ko.dependencyDetection.begin({
    callback: function(subscribable, internalId) {
        console.log("    child context: " + internalId + " was accessed");
    }
});

//inside of child context again access test and also test2
test();
test2();

//output
//child context: 1 was accessed
//child context: 2 was accessed

• When a computed is done evaluating, it signals the dependency tracker that is is complete and the tracker pops the context off of its stack and restores the previous context.

1
2
3
4
5
6
7
8
9
10
11

//end child context
ko.dependencyDetection.end();

//dependencies are back to the original (outer) context
test3();

//output
//original context: 3 was accessed

//end original context
ko.dependencyDetection.end();

• When an observable/computed dependency is updated, then the subscription is triggered and the computed is re-evaluated.

Here is a jsFiddle version of this code: http://jsfiddle.net/rniemeyer/F9CrA/. Note that ko.dependencyDetection is only exposed in the debug build. In the release build it is renamed as part of the minification process.

So, Knockout doesn’t need to parse the function as a string to determine dependencies or do any “tricks” to make this happen. The key is that all reads to observable/computeds go through logic that is able to signal the dependency tracker who can let the computed know to subscribe to the observable/computed.

How can dependencies change when a computed is re-evaluated?

Each time that a computed is evaluated, Knockout determines the dependencies again. For any new dependencies, a subscription is added. For any dependencies that are no longer necessary, the subscriptions are disposed. Generally, this is efficient and beneficial as long as you are only branching in computed code based either data that is observable or doesn’t change. For example:

1
2
3
4
5
6
7
8
9
10
11

 this.errors = ko.computed(function() {
     var result = [];

     if (this.showErrors()) {
         result = ko.utils.arrayFilter(this.history(), function(item) {
            return item.type() === "error";
         });
     }

     return result;
 }, this);

In this example, when showErrors is false, this computed will only have a single dependency, showErrors. There is no need to depend on the history or trigger re-evaluation when the items change, as it will not influence the result of the function. If showErrors does become truthy, then the computed will depend on showErrors, the history observableArray, and the type of each item.

What about bindings? How do they track dependencies?

Bindings in Knockout actually use computeds as a tool to facilitate their own dependency tracking. Each binding is evaluated within a computed observable for this purpose. Observables/computeds accessed in the update function of a binding become dependencies. Observables that are accessed within a binding string (like items in data-bind="if: items().length") are read when the valueAccessor() function is called (or via allBindingsAccessor - allBindingsAccessor.get("if") in this case). I think that it is useful to think of a binding’s update function just like a normal computed observable where access to any dependencies will trigger the binding to run again.

Note: Prior to KO 3.0, all bindings on a single element were wrapped inside of a single computed. The parsing and evaluation of the binding string was also included in this computed. So, calling valueAccessor() would give the result of the expression rather than actually run the code. Dependency detection worked the same way, all bindings on an element were triggered together and it was not possible to isolate dependencies made in the binding string. See this post for more details.

Something new in KO 3.2 - ko.pureComputed

There is an interesting feature coming in KO 3.2 related to computed dependency tracking. Michael Best implemented an option that allows a computed to not maintain any dependencies when it has no subscribers to it. This is not appropriate for all cases, but in situations where the computed returns a calculated value with no side-effects, if there is nothing depending on that calculated value, then the computed can go to “sleep” and not maintain subscriptions or be re-evaluated when any of the dependencies change. This will be useful for efficiency as well as potentially preventing memory leaks for a computed that was not disposed, but could be garbage collected if it was not subscribed to something observable that still exists. The option is called pure and a ko.pureComputed is provided as a shortcut.

Here are some of my favorite changes:

rateLimit extender

There is a new rateLimit extender that handles throttle and debounce scenarios (docs here). Some notes about this functionality:

• The throttle extender is deprecated. There are some slight differences between rateLimit and throttle described here.
• The rateLimit extender returns the original value rather than a new computed like the throttle extender. This saves the overhead of an additional computed and better handles scenarios where the original value has already been extended in other ways (perhaps the original had an isValid sub-observable, which became inaccessible when the throttle extender created a new computed to stand in front of it.
• The rateLimit extender works properly with observables, computeds, and observableArrays.
• It supports a method option that by default is set to notifyAtFixedRate which corresponds to a throttling strategy. For a debounce scenario, the method can be set to notifyWhenChangesStop.

For example, suppose that we define three observableArrays.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

//when updated will notify subscribers immediately
this.normal = ko.observableArray();

//when updated will notify subscribers no more than every 500ms
this.throttled = ko.observableArray().extend({
    rateLimit: 500
});

//when updated will notify subscribers when changes have stopped for 500 ms
this.debounced = ko.observableArray().extend({
    rateLimit: {
        timeout: 500,
        method: "notifyWhenChangesStop"
    }
});

In the jsFiddle below, when you click the “Start” button, a new item will be pushed to each observableArray every 100ms for 100 iterations to demonstrate the behavior under each option.

The rateLimit extender will be a key tool going forward. I feel that after upgrading to 3.1 it would be worthwhile to review existing uses of the throttle extender in an app and update to rateLimit.

Link to full sample on jsFiddle.net

valueAllowUnset option

There is now a valueAllowUnset option for scenarios where the value does not match what is contained in the options:

• With this option set to true, Knockout does not force the value to match an existing option.
• The selection will be set to an empty option in the case of a mismatch, but the value is not overwritten.
• This is very useful in scenarios where options are lazily loaded and there is an existing value.

1

`<select data-bind="value: selectedCategory, options: categories, valueAllowUnset: true"></select>`

In this example, `selectedCategory` may be loaded with a value from the database and then when an editor is shown `categories` are loaded via an AJAX request. Without the `valueAllowUnset` option, Knockout would have recognized that the value of `selectedCategory` did not match an available option and tried to set it to the first option or undefined if there are no options. Without taking care to cache the original value, `selectedCategory` would have lost its value.

ko.computedContext

• You can now access the dependency count and whether it is the first evaluation within a computed. This could be useful in scenarios where you know that the function will never be called again (no dependencies) or to run special logic (or avoid logic) when it is the first evaluation. By using ko.computedContext while evaluating a computed, you have access to the isInitial and getDependenciesCount functions:

1
2
3
4
5
6
7
8
9
10
11
12
13

this.saveFlag = ko.computed(function() {
    var cleanData = ko.toJS(this);

    //don't save the data on the initial evaluation
    if (!ko.computedContext.isInitial()) {
      //actually save the data
    }

    //recognize that we have no dependencies
    if (!ko.computedContext.getDependenciesCount()) {
       //we might want to do some cleanup, as this computed will never be re-evaluated again
    }
}, this);

array methods pass index

The array utility methods now pass the array index as the second argument to the callbacks (in addition to the array item as the first argument).

1
2
3
4

ko.utils.arrayFilter(this.pages(), function(page, index) {
    //include any summary pages, besides the very first page
    return index > 0 && page.type === "summary";
});

Use __proto__ for base types

In browsers that support it, the base types (ko.subscribable, ko.observable, ko.computed, ko.observableArray) now use the fn objects as their prototype rather than copying functions from the fn objects to the result (since the result itself is a function, in older browsers it is not possible to set the prototype for it).

Dependency tracking performance enhancement

Dependencies are tracked in objects with unique ids, rather than in an array on each subscribable. This eliminates the need to loop internally to find an existing dependency, which has caused long-running script errors in older browsers when there were a large number of dependencies for a single observable/computed.

Look for jQuery later

Knockout looks for jQuery when applyBindings is called rather than when KO is loaded. This helps eliminate an issue with the order that KO and jQuery are loaded and in an AMD scenario you would not have to add jQuery as a dependency to KO in the shim configuration to have KO take advantage of jQuery.

There are many additional fixes listed in the release notes here. Please log any issues related to 3.1 to GitHub. Michael Best again did a tremendous job with the bulk of the changes along with Steve Sanderson as well as a number of community contributors.

• Release on Github - look at the 3.0 Beta and 3.0 RC releases to see a list of changes.
• Upgrade notes - a list of potential breaking changes.
• Blog post on 3.0 beta - Steve Sanderson’s post describing the features in 3.0 beta (bottom of post).
• Blog post on 3.0 RC - another post by Steve on some additional features added in 3.0 RC.
• knockout.punches - a great plugin by Michael Best that utilizes many of the new extensibility points added in KO 3.0. Michael was the driving force behind the major changes in 3.0 and continues to do amazing work on Knockout core.

I put together a short screencast this morning with some highlights of the features and changes in 3.0:

The new extensibility points in KO 3.0 really open up a ton of interesting options for customizing the way that Knockout can be used. This is definitely an exciting and solid release!

Last week, I was fortunate enough to attend devLink in Chattanooga, Tennessee for the first time. I had the chance to see many of my appendTo co-workers in person and meet a number of other folks that I had only corresponded with on-line. I attended many great sessions and overall felt that it was a great experience.

I presented a session on Knockout tips and tricks. These were some things that I felt would be useful to a developer after they have the basics of Knockout done. The session included these ten rounds of tips:

1. Dynamic Templating
2. Controlling “this”
3. Throttling
4. Subscriptions
5. Custom Bindings
6. Extensions
7. Computed options
8. Binding Providers
9. Debugging Tips
10. Code Smells

For this type of talk with lots of live coding, it is challenging to share the slides. So, I recorded a screencast of the presentation. Click here to watch in HD or to download it.

devLink 2013 - KnockoutJS Tips and Tricks - Ryan Niemeyer

I am definitely hoping to return to devLink next year and would be happy to hear any feedback or questions about this presentation. Photo by @jcreamer898.

2.3.0 contains a ton of fixes and improvements. Here is a copy of the 2.3.0 release notes:

Features:

• hasfocus renamed to hasFocus (hasfocus will still continue to work as well)
• name parameter of template can accept an observable
• ko.unwrap added as substitute for ko.utils.unwrapObservable
• options binding uses same technique as foreach to avoid unnecessary re-rendering
• optionsAfterRender callback added to allow for custom processing of the added options
• optionsCaption will display a blank caption if the value is an empty string

Bugs fixed:

• hasfocus: requires two Tab presses to blur (and related issues) in Chrome; throws error in IE9 on initial binding
• Error when you try to inline knockout because of </script> string
• If first node in string template has a binding, the bindings in the template won’t get updated
• selectedOptions doesn’t update non-observable properties
• css won’t accept class names with special characters
• Applying binding twice to the same nodes fails in strange ways (now it fails with an obvious error message)
• Two-way bindings overwrite a read-only computed property with a plain value
• Empty template throws an error with jQuery 1.8+
• observableArray can be initialized with non-array values
• Event binding init fails if Object.prototype is extended (fixed all for...in loops)
• Calling ko.isSubscribable with null or undefined causes an error
• Binding to null or undefined causes an error
• Memory leak in IE 7, 8 and 9 from event handlers
• options binding causes error in IE8+ in compatibility mode
• value binding on select doesn’t match null with caption option
• Invalid element in string template can cause a binding error
• Conditionally included select gets close to zero width in IE7-8
• ko.toJS treats Number, String and Boolean instances as objects
• value binding misses some updates (1 -> "+1")
• Exception in ko.computed read function kills the computed
• Error if spaces around = in data-bind attribute in string template

Maintenance:

• Port tests to Jasmine
• Support Node.js
• Remove build output files and Windows build scripts
• Build script runs tests using build output (using PhantomJS and Node.js)
• Use faster string trim function
• Add automated multi-browser testing using Testling-CI

Binding issues

The most common errors encountered in Knockout typically center around incorrect or invalid bindings. Here are several different ways that you can diagnose and understand the context of your issue.

The classic “pre” tag

One of the main debugging tasks is to determine what data is being used to bind against a certain element. The quick-and-dirty way that I have traditionally accompished this is by creating a “pre” tag that outputs the particular data context that is in question.

Knockout includes a helper function called ko.toJSON, which first creates a clean JavaScript object that has all observables/computeds turned into plain values and then uses JSON.stringify to turn it into a JSON string. You would apply this to a “pre” tag like:

1

    <pre data-bind="text: ko.toJSON($data, null, 2)"></pre>

As of KO 2.1, the second and third arguments are passed through to JSON.stringify with the third argument controlling the indentation to produce nicely formatted output. Prior to KO 2.1, you could still do this by using JSON.stringify(ko.toJS($data), null, 2). You can use this technique to look at specific properties or use the special context variables like $data, $parent, or $root. This will give you output like:

{
  "title": "Some items",
  "items": [
    {
      "description": "one",
      "price": 0
    },
    {
      "description": "two",
      "price": 0
    },
    {
      "description": "three",
      "price": 0
    }
  ],
  "titleUpper": "SOME ITEMS"
}

Lazy? Then just console.log it

Does that “pre” tag look like too much work? An even easier and more direct solution is to simply put a console.log in your binding string. The binding string is parsed into a JavaScript object, so code that you place in it will be executed. In addition, you can also put bindings that don’t exist into your binding string. This is because bindings can be used as options in other bindings (think optionsText or optionsValue), so KO does not throw an exception when it finds an undefined binding handler. This means that you can simply do:

1

    <input data-bind="blah: console.log($data), value: description" />

The block above will output your data to the console just before encountering a typo in the description property. You may even want to wrap your data in a call to ko.toJS or ko.toJSON depending on how you want the output to appear in the console.

Update: in KO 3.0, a binding with no actual handler, will no longer get executed. You would need to use an actual binding like the custom one described below or even something harmless like the built-in uniqueName binding.

Extensions / bookmarklets

There are several great community-created solutions for doing this type of investigation as well:

• Knockout Context Debugger Chrome extension - adds a pane to the Chrome dev tools that allows you to see the context associated with a specific element. Update: the latest version adds some nice tracing functionality as well. Created by Tim Stuyckens.
• Knockout Glimpse plugin - Glimpse is a powerful debugging tool for ASP.NET. Aaron Powell created an excellent Knockout plugin for it.
• Bowtie - a bookmarklet by Max Pollack that lets you inspect the context associated with bindings and add watch values. Note - it does assume that the page includes jQuery.
• Knockout-debug - a bookmarklet by James Smith that gives a nice display of your view model.

Performance testing - how often is a binding firing?

Sometimes an interesting thing to explore/investigate is how often a certain binding is being triggered and with what values. I like to use a custom binding for this purpose.

1
2
3
4
5
6
7
8
9
10
11
12
13

    ko.bindingHandlers.logger = {
        update: function(element, valueAccessor, allBindings) {
            //store a counter with this element
            var count = ko.utils.domData.get(element, "_ko_logger") || 0,
                data = ko.toJS(valueAccessor() || allBindings());

            ko.utils.domData.set(element, "_ko_logger", ++count);

            if (window.console && console.log) {
                console.log(count, element, data);
            }
        }
    };

This will show you a count of how many times the bindings on this element have been fired. You can either pass in a value to log or it will log the values provided to all bindings on that element. You may want to include a timestamp as well, depending on your needs. There are many times where this will open your eyes to a lot of unnecessary work happening in your UI. It may be from pushing again and again to an observableArray or maybe a case where throttling would be appropriate. For example, you might place this on an element like:

1

    <input data-bind="logger: description, value: description, enable: isEditable" />

and expect output like:

 1 <input…/> “Robert”
 2 <input…/> “Bob”
 3 <input…/> “Bobby”
 4 <input…/> “Rob”
 

Just a note that in the KO 3.0 (almost in beta), each binding on an element will be fired independently, as opposed to now where all bindings fire together. When KO 3.0 is released, you would want to use a binding like this with that in mind and likely only pass the specific dependencies that you are interested in logging.

Undefined properties

Another common source of binding issues is undefined properties. Here is a quick tip for handling scenarios where a property is missing and it will not be added later. This is not specifically a debugging tip, but it can help you avoid potential binding issues without much fuss.

For example, this would cause an error (if myMissingProperty is missing):

1

    <span data-bind="text: myMissingProperty"></span>

However, this will bind properly against undefined:

1

    <span data-bind="text: $data.myMissingProperty"></span>

In JavaScript it is an error to attempt to retrieve the value of a variable that is not defined, but it is fine to access an undefined property off of another object. So, while myMissingProperty and $data.myMissingProperty are equivalent, you can avoid the “variable is not defined” errors by referencing the property off of its parent object ($data).

Catching exceptions using a custom binding provider

Errors in bindings are inevitable in a Knockout application. Many of the techniques described in the first section can help you understand the context around your binding. There is another option that can also help you track and log problems in your bindings. A custom binding provider provides a nice extensibility point for trapping these exceptions.

For example, a simple “wrapper” binding provider might look like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

    (function() {
      var existing = ko.bindingProvider.instance;

        ko.bindingProvider.instance = {
            nodeHasBindings: existing.nodeHasBindings,
            getBindings: function(node, bindingContext) {
                var bindings;
                try {
                   bindings = existing.getBindings(node, bindingContext);
                }
                catch (ex) {
                   if (window.console && console.log) {
                       console.log("binding error", ex.message, node, bindingContext);
                   }
                }

                return bindings;
            }
        };

    })();

Now, binding exceptions will be caught and logged with the error message, the element, and the binding context (contains $data, $parent, etc.). A binding provider can also be a useful tool to log and diagnose the amount of times that bindings are being hit.

View Model issues

Binding issues seem to be the most common source of errors in Knockout, but there are still errors/bugs on the view model side as well. Here are a few ways to instrument and control your view model code.

Manul subscriptions for logging

A basic technique to help understand how things are being triggered in your view model is to create manual subscriptions to your observables or computeds to log the values. These subscriptions do not create dependencies of their own, so you can freely log individual values or the entire object. You can do this for observables, computeds, and observableArrays.

1
2
3
4
5
6
7

    this.firstName = ko.observable();
    this.firstName.triggeredCount = 0;
    this.firstName.subscribe(function(newValue) {
        if (window.console && console.log) {
            console.log(++this.triggeredCount, "firstName triggered with new value", newValue);
        }
    });

You could format the message to include whatever information is relevant to you. It would also be easy enough to create an extension to add this type of tracking to any observable/computed:

1
2
3
4
5
6
7
8
9
10

    ko.subscribable.fn.logIt = function(name) {
        this.triggeredCount = 0;
        this.subscribe(function(newValue) {
            if (window.console && console.log) {
                console.log(++this.triggeredCount, name + " triggered with new value", newValue);
            }
        }, this);

        return this;
    };

Since the extension returns this, you can chain it onto an observable/computed during creation like:

1

   this.firstName = ko.observable(first).logIt(this.username + " firstName");

In this case, I chose to include the username to ensure that it is outputting a unique value in the case that I have a collection of objects that each have a firstName observable. The output would look something like:

1 "bob1234 firstName triggered with new value" "Robert"
2 "bob1234 firstName triggered with new value" "Bob"
3 "bob1234 firstName triggered with new value" "Bobby"
4 "bob1234 firstName triggered with new value" "Rob"

The value of “this”

Issues with the value of this is one of the most common challenges encountered when starting out with Knockout. Whenever you are binding to an event (click / event binding) and are using a function off of another context (like $parent or $root), you will generally need to worry about the context, as Knockout executes these handlers using the current data as the value of this.

There are several ways to ensure that you have the appropriate context:

1- you can use .bind to create a new function that is always bound to a specific context from within your view model. If the browser does not support bind natively, then Knockout adds a shim for it.

1
2
3

  this.removeItem = function(item) {
      this.items.remove(item);
  }.bind(this);

or if your function lives on the prototype, you would have to create a bound version on each instance (not ideal) like:

1

  this.removeItem = this.removeItem.bind(this);

2- you can create a variable in your view model that corresponds to the current instance (var self = this;) and always use self rather than this in your handlers. This technique is convenient, but does not lend itself to placing functions on a prototype object or adding functions through mix-ins, as these functions need to access the instance through the value of this (unless bound like in #1).

1
2
3
4
5

 var self = this;

  this.removeItem = function(item) {
     self.items.remove(item);
  };

3- you can even use .bind in the binding string, depending on how comfortable you are with seeing it in your markup. This would look like:

1

    <button data-bind="click: $parent.removeItem.bind($parent)">Remove Item</button>

Similarly, you could create a simple custom binding that wraps the event binding and takes in a handler and a context like data-bind="clickWithContext: { action: $parent.removeItem, context: $parent }".

4- the way that I personally handle this now is to use my delegated events plugin, which will do event delegation and as a by-product is able to automatically call the method off of the object that owns it. This also makes it convenient/practical to place your functions on the prototype of your object. With this plugin, the above sample would simply look like:

1

    <button data-click="removeItem">Remove Item</button>

I have found that this removes the vast majority of the context binding concerns that I have in my viewmodel code.

Using the console

One of my favorite ways to debug/investigate a Knockout app is to use the browser’s debugging console. If your view model is well written, you can generally control your entire application from the console. Recently, I ran a data conversion involving hundreds of records from the debugging console by loading the appropriate data, looping through each record to manipulate any observables that needed updating, and saving each record back to the database. This may not always be the best idea, but it was the most practical and efficient way for me to accomplish the conversion for my scenario.

Accessing your data

The first step is getting a reference to your data from the console. If your app is exposed globally, perhaps under a specific namespace, then you are already good to go. However, even if you call ko.applyBindings without your view model being available globally, you can still easily get at your data. Knockout includes ko.dataFor and ko.contextFor helper methods that given an element tell you the data/context that was available to the element during binding. For example, to get your overall view model, you may start with something like this in the console:

1

    var data = ko.dataFor(document.body);

Now you have access to your overall view model (if you simply called ko.applyBindings without specifying a specific root element). With access to that view model, you can call methods, set observable values, and log/inspect specific objects.

Making logging a bit smarter

Anyone that has done debugging in Knockout has likely done a console.log on an observable or computed directly at some point and found some less than useful output like:

1

function d(){if(0<arguments.length){if(!d.equalityComparer||!d.equalityComparer(c,arguments[0]))d.H(),c=arguments[0],d.G();return this}b.r.Wa(d);return c}

One way to improve this output is to add a toString function to the various types. I like to show the name of the type (like observable or computed) and the current value. This helps you quickly understand that it is indeed a KO object, which type it is, and the latest value. This might look like:

1
2
3
4
5
6
7

    ko.observable.fn.toString = function() {
        return "observable: " + ko.toJSON(this(), null, 2);
    };

    ko.computed.fn.toString = function() {
        return "computed: " + ko.toJSON(this(), null, 2);
    };

The output in the Chrome console would now look like:

observable: "Bob"
computed: "Bob Smith"
observable: "Jones"
computed: "Bob Jones"

Note that not all browsers respect the toString function, but it certainly helps with Chrome. Also, observableArrays are a bit harder to handle. Chrome sees that the observableArray (function) has both a length and a splice method and assumes that it is an array. Adding a toString function is not effective in this case, unless you delete the splice function from observableArrays.

Final notes

• Debugging Knockout core - When you encounter exceptions in your Knockout application, I would not recommend trying to debug the Knockout core library code as your first choice. It is almost always more effective and efficient to isolate the origin of the issue in your application code first and try to simplify the reproduction of that issue. In my experience, the main situation where stepping into Knockout core is potentially a good choice is if you are truly seeing inconsistent behavior between browsers. Knockout core can be challenging to step through and follow, so if you do find yourself debugging into the core library, a good place to start is within the binding handlers themselves.

• Be careful with logging - if you add logging or instrumentation to your code, be mindful of how this logging may contribute to the dependencies of your computeds/bindings. For example, if you logged ko.toJSON($root) in a computed you would gain a dependency on all observables in the structure. Additionally, if you have a large view model, be aware of the potential performance impact of frequently converting large object graphs to JSON and logging or displaying the result. Throttling may help in that scenario.

• console.log format - the console.log calls in the snippets are just samples. I understand that some browers don’t support passing multiple arguments to console.log and some do not let you navigate object hierarchies. If you need to do this logging in a variety of browers, then make sure that you build suitable output. The normal case where I am doing logging is temporarily in Chrome during development.

The result is this library: knockout-amd-helpers

Why require.js and AMD modules

Breaking an application down into small, decoupled modules is a pattern that works well when done right. Creating modules in JavaScript is often accomplished by using various namespacing patterns. As an application grows though, it is easy to lose sight of the individual dependencies of each module and eventually maintaining the order that all of your scripts need to be loaded in becomes a burden as well. AMD module loaders can help with these issues.

There are plenty of good resources that help explain require.js, dependency management, and AMD modules. Here are a few good ones:

• The require.js documentation on AMD modules.
• Our documentation on using Knockout with require.js.
• My co-worker Jonathan Creamer’s tutorial on using Knockout.js in large-scale applications. He also recently did a presentation for dotnetConf that can be found here on using require.js and using it with ASP.NET MVC.
• While require.js is the most mentioned option in this category, there are others including the excellent curl.js.

A few pain points

When developing Knockout applications using require.js, there are a couple of situations that out-of-the-box still seemed less than perfect to me.

1- After breaking down your application into specific modules, it is unfortunate to have to include all of your markup on a single page. There are server-side solutions to pull in partials for your templates, but that still results in a page that contains all of your markup from the start. There is also the external template engine, which works well, but is not designed to leverage the capabilities of the AMD loader libraries (like optimization/bundling).

2- Dynamically requesting and binding against modules is not trivial. Normally, you would build a main “App” view model that contains all of the sub-modules that you want to bind against. It would be nice though to be able to dynamically pull in modules or use modules as reusable components in an app under any context.

Looking at potential solutions

Based on some of the different approaches that I have used in the past, I created the knockout-amd-helpers plugin to hopefully help ease these issues.

An AMD compatible template engine

The first feature of the plugin is to use one of Knockout’s extensibility points to replace the default template engine with one that is able to load named templates using the AMD loader’s text plugin.

I used the template sources extensibility point that I discussed here. When a named template is requested, it first checks to see if there is a script tag with the specified id (the default engine actually will grab any element with that id) and if not uses the text plugin to require the template. This will asynchronously load the template (unless it has already been loaded or is bundled and already available on the client). The template source uses an observable that triggers the template binding to update when the template is available.

For example, when using a binding like:

1

    <ul data-bind="template: { name: 'itemView', foreach: items }"></ul>

If there is no script tag with an id of itemView, it will attempt to load the template. The engine uses a default path of templates and a default suffix of .tmpl.html. So, it would look for the template at templates/itemView.tmpl.html. The default path and suffix can be configured and you can also pass a more specific path in for the name (sub/path/itemView).

A module binding

This updated template engine now helps keep your templates as modular as your view models, but it still would be nice to easily pull modules into an application without using a top-level view model that needs to contain everything that you might want to bind against.

To help with this situation, the plugin includes a module binding, which offers a flexible way to dynamically pull a module into your markup. Here is a basic example:

1

    <nav data-bind="module: 'navigation'"></div>

This will require a navigation module (the base directory can be configured as well). If the main element had children, then it would use them as an inline/anonymous template. However, in this case, since the element does not have children, it will use navigation as the template name and follow the template engine’s rules for pulling in the template.

After the loading the module it will follow a few rules for deciding what data to bind against:

1. If the module returns a function, then it will create a new instance
2. If the module returns an object, then it will, by default, call an initialize function on the object (if it exists) and either use the result of the function or the original object if there is not a return value.

This gives you the flexibility of either constructing a new object, using an existing object, or calling a function that returns some object to bind against.

The module binding has a number of options that you can pass in as well. Here is an example passing all of the options:

1
2

    <div data-bind="module: { name: 'one', data: initialData, template: 'oneTmpl',
                              initializer: 'createItem', afterRender: myCallback }"></div>

These options let you do things like customize the template to use, specify data to pass into the constructor or initializer, define the name of the function to call, and pass an afterRender function through to the template binding.

With this binding, it is possible to call ko.applyBindings({}) and build your application strictly using the module binding. A module binding can be nested inside other module bindings and you can also use observables to dynamically specify your module.

Communicating between modules

When building an app using this structure, it would be less than ideal to rely on $root or $parent calls within the markup to communicate between modules. This can potentially couple your module to only working within a certain context. While this can certanily work, a better solution may be to use some type of messaging to communicate between the modules.

I have a library called knockout-postbox that adds a ko.postbox object and some observable extensions that make it easy to publish values on a topic and update an observable based on a subscription to a topic.

For example, in a module that defines the main content, you could have an observable like:

1

   this.sectionName = ko.observable().subscribeTo("navigation.current");

Then, in the navigation module, publish on that topic like:

1

   this.selectedNavItem = ko.observable().publishOn("navigation.current");

The postbox library supports a number of options that control how the publish/subscribe process works, but if you are looking for a stand-alone library that supports a number of additional features (channels, wildcards, envelopes), then I would recommend postal.js

Summary

If you are using AMD modules in your Knockout application and are looking for a lightweight and simple, but flexible way to bind against templates and modules, then check out this new library. It has been tested with both require.js and curl.js. I would be happy to help support any other AMD loaders, if there is interest. Please check out the README on the repository for additional documentation. I also plan to work on a better example, as time permits.

If you are looking for help with a significant Knockout project (or any other front-end technology), then I would encourage you to contact appendTo and maybe we could have the chance to work together. For general KO questions or if you are looking for help on a project that only requires a small time investment, feel free to contact me directly.

He recently asked me to take a look at a Knockout-based shopping cart that he had written for another video. The code was working just fine, but as I dug into it, I started jotting down a LOT of notes. I ended up formatting them in markdown and sent them Rob’s way. He thought that it would be a good idea to record a screencast to really dig into those notes.

Here is a trailer for the screencast:

I personally have had a Tekpub subscription for around two years and definitely recommend the service. They are really putting out some great content lately and have a well-done Knockout series.

Update: here is a link to the notes that I sent Rob.

I described this pattern in the Twin Cities Code Camp presentation here. This technique allows you to easily copy, commit, and revert changes to an entire model. There are two rules that make this pattern work:

1. The creation of observables and computeds needs to be separate from actually populating them with values.

2. The format of the data that you put in should be the same as the format that you are able to get out. Typically this means that calling ko.toJS on your model should result in an object that you could send back through the function described in step 1 to re-populate the values.

Separate creation and initialization

The idea is that we can apply fresh data to our object at anytime, so our constructor function should just create our structure, while a separate method handles setting the values.

1
2
3
4
5
6
7
8
9
10
11

    var Item = function(data) {
        this.name = ko.observable();
        this.price = ko.observable();

        this.update(data);
    };

    Item.prototype.update = function(data) {
        this.name(data.name || "new item");
        this.price(data.price || 0);
    };

Our update function (call it whatever you like init, initialize, hydrate, etc.), needs to handle populating the values of all of the observables given a plain JavaScript object. It can also handle supplying default values.

Data in matches data out

To make this pattern work, we need to be able to put a plain JavaScript object in and get the equivalent object out. Ideally, simply calling ko.toJS on our model, will give us the plain object that we need. It is okay, if there are some additional computeds/properties on the object, but it needs to be appropriate for sending through the update function again.

A technique that I use frequently to “hide” data that I won’t want when I turn the model into a plain JavaScript object or to JSON is to use a “sub-observable”. So, if we had a computed observable to show a formatted version of the price that we don’t want in our output, we could specify it like:

1
2
3
4
5
6
7

    var Item = function(data) {
        this.name = ko.observable();
        this.price = ko.observable();
        this.price.formatted = ko.computed(this.getFormattedPrice, this);

        this.update(data);
    };

Since observables are functions and functions are objects that can have their own properties, it is perfectly valid to create a formatted computed off of the price observable. In the markup, we can bind against price.formatted. However, when calling ko.toJS or ko.toJSON, the formatted sub-observable will disappear, as we will simply be left with a price property and value.

Reverting changes

Now that we have these pieces in place, it is easy to create an editor that allows reverting changes. In the event that a user chooses to cancel their editing, all we need to do is send the original data back through our update function and we will be back to where we started.

We will need to track the original data, so that it is available to repopulate the model. A good place to cache this data is in the update function itself. It is useful to make sure that the data is “hidden” as well, so multiple edits don’t result in recursive versions of the old data being kept around. If we were not using the prototype, then we could just use a local variable to store the data, but since we are placing our shared functions on the prototype in these samples, we need to find another way to hide this data. A simple solution is to create an empty cache function and store our data as property off of it. This will prevent calls to ko.toJS or ko.toJSON from capturing this data.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

    var Item = function(data) {
        this.name = ko.observable();
        this.price = ko.observable();
        this.cache = function() {};

        this.update(data);
    };

    ko.utils.extend(Item.prototype, {
      update: function(data) {
        this.name(data.name || "new item");
        this.price(data.price || 0);

        //save off the latest data for later use
        this.cache.latestData = data;
      },
      revert: function() {
        this.update(this.cache.latestData);
      }
    });

In this scenario, we will let edits persist to our observables and in the event that a user chooses to cancel, we will refresh our model with the original data.

Committing changes

When a user accepts the data, we need to make sure that we update the cached data with the current state of the model. For example, we could simply add a commit or accept function to our prototype that does:

1
2
3

    commit: function() {
        this.cache.latestData = ko.toJS(this);
    }

We now have the latest data cached, so the next time that a user cancels it will be reverted back to this updated state.

Copying/cloning

Sometimes in an editor, we would not want the currently edited observables to affect the rest of the UI until the user chooses to accept the changes. In this case, we can use these same methods to create a copy of the item for editing and then apply it back to the original. Here is how our overall view model might look:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

    var ViewModel = function(items) {
        //turn the raw items into Item objects
        this.items = ko.observableArray(ko.utils.arrayMap(items, function(data) {
            return new Item(data);
        });

        //hold the real currently selected item
        this.selectedItem = ko.observable();

        //make edits to a copy
        this.itemForEditing = ko.observable();
    };

    ko.utils.extend(ViewModel.prototype, {
        //select and item and make a copy of it for editing
        selectItem: function(item) {
            this.selectedItem(item);
            this.itemForEditing(new Item(ko.toJS(item)));
        },

        acceptItem: function(item) {
            var selected = this.selectedItem(),
                edited = ko.toJS(this.itemForEditing()); //clean copy of edited

            //apply updates from the edited item to the selected item
            selected.update(edited);

            //clear selected item
            this.selectedItem(null);
            this.itemForEditing(null);
        },

        //just throw away the edited item and clear the selected observables
        revertItem: function() {
            this.selectedItem(null);
            this.itemForEditing(null);
        }
    });

So, we make edits to a copy of the original and on an accept we apply those edits back to the original. We can use ko.toJS to get a plain JavaScript object and feed it into our update function to apply the changes. In this scenario, the revertItem function can simply throw away the copied item and clear our the selected value.

Link to sample on jsFiddle.net

If you were going to reuse this technique often, then you could even create an extension to an observableArray that adds the appropriate observables and functions off of the observableArray itself like in this sample.

Updating from server

Our update function is also a handy way to apply updates from the server to our existing view model. In our case, we would likely need to add an id to the Item objects, so that we can identify which object needs updating. This works very well with something like SignalR or socket.io to keep various clients in sync with each other. This is an easier pattern than trying to swap items in an array or update specific properties one by one.

Summary

Editors with accept/cancel options are a common scenario in a Knockout.js application. By separating the creation of observables/computeds from poplating their values, we can commit, reset, and update models by feeding a version of the data through our update function. When you think in terms of the plain JS object that you can get out of or put into a model, it makes many of these scenarios easy to handle.

Note: based on the techniques in this post, I created a plugin called knockout-delegatedEvents located here: https://github.com/rniemeyer/knockout-delegatedEvents.

Why event delegation in Knockout.js?

Currently when you use the click or event binding in Knockout, an event handler is attached directly to that element. Generally this is fine and causes no real problems. However, if you face a scenario where you have a large number of elements that require these bindings, then there can be a performance impact to creating and attaching these handlers to each element, especially in older browsers. For example, you may be creating a grid where each cell needs various event handlers or a hierarchical editor where you are potentially attaching handlers to interact with the parent items as well as each child (and each child may have children).

In this case, there are advantages to using event delegation:

• you only have to attach one (or a few) event handlers rather than one on each element. Events bubble up to the higher-level handler and can understand the original element that triggered it.
• dynamically added content does not need new event handlers added to them (largely not an issue with KO bindings and templating)

Normal event delegation with KO 2.0+

With Knockout 2.0+, the common way to use event delegation is to avoid attaching event handlers in the bindings themselves and add another layer of code to attach a single handler to a parent element using something like jQuery’s on (previously live/delegate). So, rather than doing:

1
2
3
4
5

<ul data-bind="foreach: items">
    <li>
        <a href="#" data-bind="click: $root.selectItem, text: name"></a>
    </li>
</ul>

You would instead do:

1
2
3
4
5

<ul id="items" data-bind="foreach: items">
    <li>
        <a href="#" data-bind="text: name"></a>
    </li>
</ul>

and attach an event handler elsewhere like:

1
2
3
4
5
6

$("#items").on("click", "a", function() {
    var context = ko.contextFor(this); //this is the element that was clicked
    if (context) {
        context.$root.selectItem(context.$data);
    }
});

Attaching a single handler like this works quite well. However, there are a few issues that I still have with this technique:

• you have another layer of code to manage besides your view model. This is the type of code that Knockout generally helps you get away from.
• this code is tightly coupled (fairly) with this view’s markup
• in our example, if the entire ul is part of a template that gets swapped, then we would need to hook up our handler again or choose to add our handler at a higher level (possibly up to the body)
• this particular code also adds a dependency on jQuery that is not really necessary

In my perfect Knockout application, you have your view and your view model with the only code outside of that being a call to ko.applyBindings. To accomplish this, we would need to be able to wire it up declaratively in the view. I have been exploring a few ways to make this happen.

Declaratively adding a handler

The first step is attaching a handler on the parent or root element that will respond when events bubble up to it. This is pretty easy to accomplish with a custom binding. When the event is handled, we can determine the original element and use ko.dataFor or ko.contextFor to get the original data context and then execute some method.

1
2
3
4
5
6
7
8
9
10

//add a handler on a parent element that reponds to events from the children
ko.bindingHandlers.delegatedHandler = {
    init: function(element, valueAccessor) {
        //array of events
        var events = ko.utils.unwrapObservable(valueAccessor()) || [];
        ko.utils.arrayForEach(events, function(event) {
            ko.utils.registerEventHandler(element, event, createDelegatedHandler(event, element));
        });
    }
};

To create the handler, we take the target element and get its context:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

//create a handler for a specific event like "click"
var createDelegatedHandler = function(eventName, root) {
    //return a handler
    return function(event) {
        var el = event.target,
            data = ko.dataFor(el),
            action = findAnAction(el, context); //??? how do we know what method to call


        //execute the action
        if (action) {
            //call it like KO normally would with the data being both the value of `this` and the first arg
            result = action.call(data, data, event);

            //prevent the default action, unless the function returns true
            if (result !== true) {
                if (event.preventDefault) {
                    event.preventDefault();
                }
                else {
                    event.returnValue = false;
                }
            }
        }
    };
};

When used on an element, the binding would take in an array of events like:

1
2
3

<ul data-bind="delegatedHandler: ['click', 'mouseover', 'mousedown']">
...
</ul>

With this binding in place, we can handle the event, find the element that triggered the event, and determine the data context of the element. However, we still need to know what method to call. I looked at a few alternatives for this piece.

Option #1 - using a binding

On the child elements, we could use a binding that stores a reference to the function to call. The binding can use Knockout’s ko.utils.domData functions to store and retrieve data on the element, as Knockout automatically cleans up this data whenever it removes elements from the document. For example, we could create a delegatedClick binding to make this association.

1
2
3
4
5
6
7

//associate a handler with an element that will be executed by the delegatedHandler
ko.bindingHandlers.delegatedClick = {
    init: function(element, valueAccessor) {
        var action = valueAccessor();
        ko.utils.domData.set(element, "ko_delegated_click", action);
    }
};

Now, on a child element, you would associate a function like:

1
2
3

<li>
    <a href="#" data-bind="text: name, delegatedClick: $parent.selectItem"></a>
</li>

We could create additional bindings for other events that we are interested in and could even create a helper function to generate these bindings given an array of events that we need to handle.

Pros

• Can simply replace click bindings with delegatedClick (and other events) without any other changes
• Can bind against specific functions and can execute code for cases where you need to call a function with a parameter to create a handler (delegatedClick: $parent.createHandler('some_modifier'))

Cons

• The binding on the child elements is lightweight, but we still have to pay the overhead of parsing and executing a binding.

Option #2 - use a data- attribute with method name

The first solution works well, but I still do not like having to pay the price of executing bindings on the child elements. For an alternative solution, I looked at a different approach where the child elements are tagged with a data-eventName attribute that contains the method name.

1
2
3

<li>
    <a href="#" data-click="selectItem" data-bind="text: name"></a>
</li>

With this technique we would no longer need the child bindings. In the event handling code, we would now need to locate a method that matches our data-eventName attribute value. This time we can use ko.contextFor to get back the entire binding context. It is very common to call functions off of $parent or $root as well as off of the current data itself, so the $parents array allows us to walk up the scope chain to locate an appropriate method.

Pros

• No overhead of executing a binding on the child elements
• Can execute the function with the correct owner, so we do not need to use .bind or var self = this; to ensure that the context is correct. This is a really nice benefit, we have to search for the method in each scope, so we know the appropriate owner of the method to use as the context.

Cons

• could run into issues with clashing names (child has an add method, but you wanted to call parent’s add)
• cannot execute code to create a handler, as the attribute value would be a string that needs to match a method name

Option #3 - associate method and name in root/global object

Another alternative might be to use the data- attribute, but use the string to key into an object that holds the associations between names and actions. Perhaps something like ko.actions or ko.commands. This object could hold just function references or maybe a function and owner. For arrays of objects, we would not be able to indicate an appropriate owner, so we would have to fall back to making sure that the function is properly bound on each instance. For example, we could even give the function an alias of select like:

1
2
3
4

ko.actions.select = {
    action: this.selectItem,
    owner: this
};

Pros

• No overhead of executing a binding on the child elements
• No issues with ambiguity in names, as names can be aliased
• Functions outside of a view model could be included
• Could dynamically change the definition of the action

Cons

• have to manage adding (and maybe removing) functions to this object
• different types of objects with the same method names would have to be aliased with unique names in this object

Summary

In cases where you need to attach a large number of event handlers, using event delegation can be a nice win. Attaching these handlers declaratively provides an alternative to wiring this up outside of your view/viewmodel. While considering each of the techniques to determine the function to execute, I was leaning towards #2, as it does not require the child bindings and as a bonus gets the context right when it calls the handler. Instead though, I decided to create a plugin that can use all of these techniques interchangeably. The plugin lives at: http://github.com/rniemeyer/knockout-delegatedEvents. Please let me know if you have feedback or suggestions for the plugin.

Here are a few of my favorite changes:

• The css binding can either toggle specific classes on and off like (css: { error: hasError, required: isRequired }) or now add one or more classes dynamically like css: someClassOrClasses. This is handy when the class names are dynamic. Previously, you could do something similar with the attr binding against the class attribute, but it would overwrite the class attribute completely. When using the css binding in this way, it will now preserve existing classes and will properly remove any class or classes that were previously added by the binding when the value changes.
• The if and ifnot bindings now only re-render their contents when the bound value changes between truthy and falsy. This helps to alleviate the performance issue described in the first half of this post.
• There is a new peek function available on observables and computed observables. This allows you to retrieve its value without creating a dependency. This definitely can be useful when you want tight control over when bindings and other subscriptions are triggered, but I would use caution as it does circumvent the normal dependency tracking mechanism. If you find that you need this functionality, then you probably have a good reason why you don’t want a dependency and would understand what does and doesn’t trigger updates.
• The foreach binding and the foreach option of the template binding now try to understand if items have been moved and will relocate the content rather than tearing it down and re-rendering it at its new position. This comes with some new callbacks (beforeMove and afterMove).
• The ko variable is now available from within bindings, even if ko is not a global variable (common in AMD scenarios).

You can download the 2.2 files from here. There were no intentional breaking changes made in 2.2 (unless someone was relying on an existing bug), so if you have any issues with your application not behaving as it did in 2.1, please log an issue here.

Last weekend, I was invited to talk about Knockout.js at Twin Cities Code Camp. It was a very enjoyable day, as I saw several great presentations and had a chance to talk to many Knockout users.

I was told that there had been several sessions in the past that touched on Knockout, so for this talk I decided to focus on some tips, tricks, and techniques that can be used to get the most out of Knockout. The topics covered included:

• Brief introduction to Knockout
• Getting data in and out
• Extending Knockout’s structures
• Custom Bindings
• Performance tips

There was a small amount of overlap with the session that I did at ThatConference in August, but all of the samples were new for this talk. The project that I used to give the presentation is also described in the ThatConference post and a reference project lives here.

Here is a screencast of the presentation:

Getting the Most Out of Knockout.js - 10/06/2012 - Twin Cities Code Camp

A few clarifications from the presentation:

• At the end of the “getting data out” part, I had typed var meta instead of this.meta.
• In the maxLength extender, I used a writeable computed observable. In the write function, I should have written the new value to our observable (original(newValue);), in addition to checking its length.
• In the enterKey custom binding, you probably would want to return the result of the actual function call, as when you return true from a handler called by the event binding, it will allow the default action to proceed, which can be useful at times.
• In the modal binding where we add a handler for the hidden event, you may want to check if what you are dealing with can be written to as an observable (is an observable or writeable computed observable) by calling ko.isWriteableObservable. So, we might want to call ko.isWriteableObservable(data) before doing data(null).
• In the modal binding, the wrappers to the with binding, should really be written with with quoted like return ko.bindingHandlers['with'].init.apply(this, arguments); and return ko.bindingHandlers['with'].update.apply(this, arguments);. In IE < 9 the use of with as a property name will cause an error, as it is a JavaScript keyword.

Participating in the code camp was definitely worth the effort of traveling up to the Twin Cities. I would be happy to hear any type of feedback on the presentation. Photo by @JudahGabriel.

I had a wonderful time at ThatConference this week. It was really special to be in a place with so many people that are passionate about the same types of things that I am. I also had the pleasure of giving a talk about Knockout. The session mainly focused on the various extensibility points in Knockout. After reviewing some Knockout basics, I discussed extending observables, creating custom bindings, and the idea of binding providers.

For the presentation, I knew that I wanted to show a lot of code, but I was not too excited about continually flipping between a slide show, an IDE, and a browser. So, I decided to create a slideshow from scratch with Knockout that let me combine all three pieces into a single page app. It was quite a bit of work, but it was a fun experience overall.

Here is a screencast of the presentation:

Extending Knockout.js - 08/14/2012 - ThatConference

For creating the presentation app, I used these libraries:

• Knockout
• require.js & the text plugin - for managing dependencies and dynamically loading view models, templates, and code samples.
• CodeMirror - for the code editor
• jQuery - just for some animations
• jqPlumb - for drawing lines between two elements

Here is a repository with a heavily stripped down version of the app that I created for this presentation https://github.com/rniemeyer/SamplePresentation.

The binding provider sample implementation is also available here https://github.com/rniemeyer/knockout-classBindingProvider.

I would love to hear any feedback on the presentation. Also, I was thinking about the possibility of recording some short (< 10 minutes) screencasts on various Knockout topics. Would there be any interest in something like that?

Update: In Knockout 3.0, bindings are now fired independently on a single element, so this is no longer an issue for KO 3.0+.

When using multiple bindings on a single element, it is important to understand how Knockout triggers updates to bindings to avoid potential performance issues. For example, a common binding might look like:

1

<select data-bind="options: choices, value: selectedValue, visible: showChoices"></select>

How are the bindings on this element processed? When Knockout determines that an element has bindings, a computed observable is created to aid in tracking dependencies. Inside the context of this computed observable, Knockout parses the data-bind attribute’s value to determine which bindings to run and the arguments to pass. As the init and update functions for each binding are executed, the computed observable takes care of accumulating dependencies on any observables that have their value accessed.

Here is a simplified flow chart of the binding execution:

There are a couple of important points to understand here:

• The init function for each binding is only executed once. However, currently this does happen inside the computed observable that was created to track this element’s bindings. This means that you can trigger the binding to run again (only it’s update function) based on a dependency created during initialization. Since, the init function won’t run again, this dependency will likely be dropped on the second execution (unless it was also accessed in the update function).

• There is currently only one computed observable used to track all of an element’s bindings. This means that the update function for all of an element’s bindings will run again when any of the dependencies are updated.

This is definitely something to consider when writing custom bindings where your update function does a significant amount of work. Whenever bindings are triggered for the element, your update function will run, even if none of its observables were triggered. If possible, it is a good idea to check if you need to do work, before actually executing your update logic.

Common problems with the default bindings

1- A common scenario where this can cause an issue is when using the template binding in conjunction with other bindings. For example, you may attach a visible binding along with a template binding like:

1

<div data-bind="visible: showPlaylist, template: { name: 'playlistTmpl', data: playlist }"></div>

In this case, if showPlaylist is frequently updated, it will cause the template binding to re-render the template again. In some cases, this may not cause a concern (it would just behave like the if binding). However, in a scenario where the template has significant markup and the visible binding’s condition is frequently triggered this can cause an unnecessary performance hit. Note that when using the foreach option or binding, logic is executed to determine if any items were added or removed, so it will cause less of a performance hit in that case.

2- Another place where this can come into play with the default bindings is when using the options and value bindings together. The update function of the options binding rebuilds the list of option tags for the select element. Whenever the value is updated, it will trigger all of the bindings on the element to execute. So, instead of just setting the appropriate value, it will rebuild all of the options and then set the value. If you have a situation where you have a large number of options, then this can cause a performance issue.

Ways to address this concern

1- In some cases, it makes sense to put bindings on separate elements or on a container element. For example, you may be able to move a frequently triggered visible binding to a parent element rather have it coupled with other bindings like the template binding.

1
2
3

<div data-bind="visible: showPlaylist">
    <div data-bind="template: { name: 'playlistTmpl', data: playlist }"></div>
</div>

Here is a sample showing a visible and template binding on the same and different elements:

2- In the case of the options and value bindings, you can choose to build your option elements separately. It would be nice to just use a containerless foreach statement inside of a select element, but Internet Explorer will remove comments that it finds between select and option elements. An alternative would be to use Michael Best’s repeat binding on the option element like:

1
2
3

<select data-bind="value: selectedOption">
    <option data-bind="repeat: {foreach: items, bind: 'attr: { value: $item().id }, text: $item().name'}">
</select>

3- A more advanced way to handle these issues, is to create your own computed observable in the init function to handle updates yourself. Any observables accessed in your computed observable, will not be a dependency of the overall computed observable used to track all of the element’s bindings.

This is a technique that I tend to use by default in any bindings that I write. It is also useful when you want a single binding to accept multiple observable options and you want to respond separately to each one changing (as opposed to using the update function to repond when any observable changes). You can even wrap the existing bindings in this way to create an isolatedOptions binding.

1
2
3
4
5
6
7
8
9
10
11
12
13

ko.bindingHandlers.isolatedOptions = {
    init: function(element, valueAccessor) {
        var args = arguments;
        ko.computed({
            read:  function() {
               ko.utils.unwrapObservable(valueAccessor());
               ko.bindingHandlers.options.update.apply(this, args);
            },
            owner: this,
            disposeWhenNodeIsRemoved: element
        });
    }
};

A few notes on this technique:

• The idea is that we want to trap our dependencies in our own isolated computed observable.
• We call the update function of the options binding using .apply with the original arguments that were passed ot the binding.
• The disposeWhenNodeIsRemoved option ensures that this computed observable will be destroyed if Knockout removes our element, like in a templating scenario.
• There is one minor issue with using this technique currently: observables that are accessed in the actual binding string are included in the overall computed observable during parsing rather than when you create you call valueAccessor. This means that if your binding contains an expression where you access the observable’s value (text: 'Hello ' + name()) , then it will be tracked in the overall computed observable. This is likely to change in the near future.

Here is a sample that shows using #2 and #3 with options and value bindings: http://jsfiddle.net/rniemeyer/QjVNX/

Future

There has been some thought and work put into running each binding in the context of its own computed observable. Michael Best has this working properly in his Knockout fork. As these changes can be considered breaking, they will likely be carefully implemented over time using an opt-in approach, perhaps until a major version allows us to make some potentially breaking changes. For now, it is wise to keep in mind how your bindings are triggered and how that affects other bindings on the same element.

To handle this situation, we can keep our components loosely coupled by using a messaging system where each view model or component does not need to have direct references to its counterparts. There are several benefits to using this technique:

• Components remain independent. They can be developed, tested, and used in isolation.
• Knockout view models and non-KO components can communicate using a common interface without direct knowledge of each other.
• Components can be safely refactored. Properties can be renamed, moved, and adjusted without worrying about breaking compatibility.

Knockout’s native pub/sub

There are already many libraries and options for providing this type of message bus. One option might be triggering custom events or using great pub/sub libraries like amplify.js or postal.js. While these libraries provide robust capabilities, Knockout itself already has all of the tools to do basic pub/sub communication built-in. This is part of the ko.subscribable type, which has its capabilities added to observables, computed observables, and observableArrays.

Normally, you would not construct a ko.subscribable directly, but it is easy enough to do so:

1

var postbox = new ko.subscribable();

In Knockout 2.0, support was added for topic-based subscriptions to aid in sending out beforeChange notifications. To create a topic-based subscription against our ko.subscribable, we would simply do:

1
2
3
4
5
6

postbox.subscribe(callback, target, topic);

//with some actual code
postbox.subscribe(function(newValue) {
    this.latestTopic(newValue);
}, vm, "mytopic");

To send out a notification on this topic we would do:

1

postbox.notifySubscribers(value, "mytopic");

Now, we can do basic pub/sub messaging using subscribe and notifySubscribers against our mediator, the postbox object. However, whenever I explore integrating a new technique with Knockout, I try to consider how to make it feel as easy and natural as possible.

Extending Observables

A typical scenario for this type of functionality would be that we want to synchronize an observable between view models. This might be a one-way or even a two-way conversation. To make this easy, we can look at extending the ko.subscribable type, which would affect observables, observableArrays, and computed observables.

Suppose that we want to setup an observable to automatically publish on a topic whenever it changes. We would want to set up a manual subscription against that observable and then use notifySubscribers on our postbox.

1
2
3
4
5
6
7
8
9
10

ko.subscribable.fn.publishOn = function(topic) {
    this.subscribe(function(newValue) {
        postbox.notifySubscribers(newValue, topic);
    });

    return this; //support chaining
};

//usage of publishOn
this.myObservable = ko.observable("myValue").publishOn("myTopic");

Now, whenever the observable’s value changes, it will publish a message on the topic.

On the other side, we might want to make it easy for an observable to update itself from messages on a topic. We can use this same concept:

1
2
3
4
5
6
7
8

ko.subscribable.fn.subscribeTo = function(topic) {
    postbox.subscribe(this, null, topic);

    return this;  //support chaining
};

//usage
this.observableFromAnotherVM = ko.observable().subscribeTo("myTopic");

Notice that we can just pass this (the observable) in as the callback to the subscribe function. We know that an observable is a function and that it will have its value set when you pass an argument into the function. So, there is no need to write something like:

1
2
3
4

//no need to add an extra anonymous function like:
postbox.subscribe(function(newValue) {
    this(newValue);
}, this, topic);

Now, our observables can exchange information without direct references to each other. They do need to agree on a topic, but do not have any knowledge about the internals of the other view model or component. We can even mock or simulate the other components in testing scenarios by firing messages.

Potential gotcha: publishing objects

If the new value being published is an object, then we need to be careful, as both sides will have a reference to the same object. If code from multiple view models makes changes to that object, then we are likely no longer as decoupled as we would like. If the object is simply configuration/options passed as an object literal that are not modified, then this seems okay. Otherwise, it is preferable to stick to primitives in the values being published. Another alternative is to use something like ko.toJS to create a deep-copy of the object that is being published, so neither side has the same reference.

A new library: knockout-postbox

I created a small library called knockout-postbox to handle this type of communication. It uses the techniques described above and adds a bit of additional functionality:

• creates a ko.postbox object with clean subscribe and publish methods that take a topic as the first argument.
• adds a subscribeTo function to all subscribables (observables, observableArrays, and computed observables). The subscribeTo function also allows you to initialize your observable from the latest published value and allows you to pass a transform function that runs on the incoming values.
• adds an unsubcribeFrom function to all subscribables that removes subscriptions created by subscribeTo.
• adds a publishOn function to all subscribables that automatically publishes out new values. The publishOn function also allows you to control whether you want to immediately publish the initial value, and lets you supply an override function (equalityComparer) that allows you to compare the old and new values to determine if the new value should really be published.
• adds a stopPublishingOn function to all subscribables that removes the subscription that handles the publishOn messages.
• adds a syncWith function that does both a subscribeTo and a publishOn on the same topic for two-way synchronization.

Project link: https://github.com/rniemeyer/knockout-postbox

Basic sample:

Link to sample on jsFiddle.net

Next post: using this concept to integrate with client-side routing in a way that is natural to Knockout