Kendo UI, MVVM and KnockoutJS

One of the major features we’re working on for the next release of Kendo UI is a fresh JavaScript implementation of the Model View ViewModel (MVVM) pattern. For those not familiar, MVVM is a popular model of development that relies heavily on declarative bindings and observable elements and collections, buffeted by a ViewModel, or an object representation of view-specific data. The goal is to reduce the amount of "View code" developers must write. MVVM was originally conceived for Microsoft's WPF and Silverlight platforms, but it has found fans among JavaScript developers, too.

In keeping with Kendo UI’s mission to deliver everything you need for HTML and JavaScript development, we've decided to provide an MVVM implementation out-of-the-box.

In the process of developing our MVVM implementation, we have conducted extensive research and testing on how to build a JavaScript MVVM implementation that is fast and easy to use. In the process, we made some interesting observations that we'll share over the coming weeks. Ultimately we think our implementation is going to raise the bar for JavaScript MVVM performance, especially on lower-powered mobile devices.

Still, we know we're not the first to tackle MVVM for JavaScript, so we want to spend this post addressing the one of the other major JavaScript binding libraries, KnockoutJS.

Kendo UI & KnockoutJS 101

We like KnockoutJS. We think the work that Steve Sanderson (and countless contributors) have done with this popular open source library is nothing short of impressive, and we know a TON of people love Knockout. In fact, Kendo UI MVVM will feel similar in some ways to Knockout because our research verified that certain KO choices are the best for performance (such as single attribute binding statements). In short, Steve and company have done a good job.

That’s why we’ve done more than any other JavaScript UI library to support Knockout integration out-of-the-box. And we’re not done. We want to do more.

What Works?

Through conscious effort, we’ve built Kendo UI widgets to automatically work with much of KnockoutJS’s functionality. Specifically, here’s how you can use Knockout with Kendo UI today. You can:

• Initialize the “value” of a Kendo UI widget from a KO view model
• Perform initial binding to an observable array
• Track changes (changing a value in a Kendo UI widget updates the KO view model)

We provide this automatic integration by triggering the DOM “change” event of the underlying Kendo UI HTML element. This makes Knockout aware that something has changed in the UI.

Here's a simple example that binds a Kendo UI DatePicker to a Knockout observable:

(If you have any trouble running the embedded jsFiddle, try clicking the "+" button to run it outside of the embed frame.)

What doesn't work?

Kendo UI's support for Knockout is not 100%. To fully support Knockout’s observable model requires some extra code in Kendo UI that doesn’t exist today. As a result, here’s what doesn’t work today:

• Adding/Removing items from KO observable arrays is not reflected in a Kendo UI widget after initialization
• Updating the ViewModel from code won’t update the value in the UI out of the box (one line of code is required that I’ll show you in a moment)

In some ways, these problems are solvable with workarounds.

Observable Arrays

We’ll address the first problem listed here by providing a “Knockout aware” data source. When you bind Kendo UI widgets to this data source, it will provide the “observable hooks” necessary to make KO changes update the Kendo UI widgets.

In fact you can already do this with the Kendo UI AutoComplete (and only the AutoComplete) today to get a sense of what this approach looks like.

Check out this jsFiddle to see the Kendo UI AutoComplete automatically update its UI when a KO observable array is programmatically changed.

Observing Programmatic KO Updates

The second problem listed above can be solved now with a simple line of code:

$("#myElement").bind("change", function() { 
    $(this).data("kendoDropDownList").select(this.selectedIndex); 
}); 

This will bind the "change" event of the underlying DOM element (which gets triggered by Knockout) to code that will “force” a Kendo UI widget to update and refresh the UI. With this code added, Kendo UI will "listen" for changes Knockout triggers in the HTML and the update the rich Kendo UI widget.

There are a few other places where support is missing today, too, such as the Slider, where we have not yet "taught" the widgets to trigger the "change" event for KO. This support will be shored-up in our next release.

Getting to 100%: Custom Bindings or Improved DOM Support?

Even though we have our own MVVM implementation arriving in March, we remain committed to making Kendo UI easy to use with any library you love. Kendo UI is everything you need with "escape hatches" to use your own libraries when you want them.

So we want to ask you, how do you want us to improve our Knockout support?

We have two choices to continue improving our support:

1. Extend the “automatic” DOM-driven approach OR
2. Work on KO-specific custom binding “extensions” for Kendo UI

There are pros and cons to each approach.

Extended DOM Support

PROS

• Requires little change to existing Knockout and binding code. Start with normal KO HTML, enrich with Kendo UI widgets
• Transparent- KO and Kendo UI "just work" (for supported features)

CONS

• Implementation has limits- cannot fully support all KO features
• Requires KO-aware code in the Kendo UI codebase, which would be extra weight for customers not using KO

Knockout Custom Binding Extensions

PROS

• No KO-specific code in the Kendo UI code base (keep it small, keep it clean)
• Plug-ins can be used only by customers that want them
• Theoretically, more ability to add support for more Knockout features (we're not yet KO masters, so some research is still required)

CONS

• KO's custom binding API is a bit complex, and we'll have to spend some time becoming KO experts to create good custom bindings. As an example, check-out this custom binding for the relatively simple Kendo UI DropDownList.
• With custom bindings, KO binding markup may have to be changed to include Kendo UI specific options (and we’re not sure this is what KO developers want/expect)

So here’s your chance to help. If you’re a Knockout fan and you want to use KO with Kendo UI, what approach would you prefer? We want to make Kendo UI the best rich UI library for use with KO, but there are some hurdles to clear to make that integration seamless.

We’re ultimately very excited to deliver a great MVVM implementation while simultaneously trying to provide premiere support for popular libraries like KnockoutJS. Let us know how you’d like to see Kendo UI evolve and take an active role in shaping Kendo UI in to the ultimate toolset you want.