Recently, I spent much of my late hour programming time working on a project to create a set of Knockout.js bindings for the Kendo UI web widgets. After being involved in several discussions about how Kendo UI could integrate with Knockout, I decided to jump in and try to provide a place where this integration could officially exist and grow. As a result, there is now a project on Github for these bindings.
Kendo UI – a great framework
If you are not familiar with Kendo UI, then take a look at the demos and documentation. Also, take note of the licensing requirements. I am not affiliated with Telerik in any way, but am quite impressed with the framework. In my experience, it is an excellent product with good people working on it.
When developing these bindings, the first challenge that I found was how to simultaneously write, test, and document 19 custom bindings. After writing a couple of the bindings “by hand”, I decided to take a different route and create a factory that could generate the bindings. The idea is that you pass in some configuration and it can produce a proper binding for you. This would allow for the sharing of common code, easier maintenance/enhancements, and the ability to generate some standard tests for each widget from the configuration.
A pattern for 3rd party widget bindings
To create the bindings, I followed a pattern that I like to use for custom bindings against 3rd party widget that involves these steps:
- Prepare the options needed to initialize the widget
- Subscribe to any events triggered by the widget that require an update to the model
- Initialize the widget
- Register to destroy the widget when KO removes this element *Use either the update function or individual computed observables created in the init function to update the widget based on changes to the model.
This covers creating the widget and syncing changes between the model and the widget. However, for these bindings I wanted to support a couple of additional features:
- The ability to define global default options for a widget. The binding will merge any options passed in the data-bind attribute with these global options. This helps to keep the mark up clean by not forcing you to include all of the configuration in the binding string.
- The ability to access the actual widget from the view model. If you pass a “widget” option to the binding, then it will fill that observable with a reference to the actual widget. This allows you to call methods of the widget from within view model methods, if necessary.
With these particular bindings, I hope to look at bringing tighter integration with templating and data sources. Many of the widgets (Grid, ListView) need this type of support to fit naturally in a Knockout application. I also hope to see what kind of feedback comes from real-world usage to decide the next steps.
Additionally, if there is enough demand, it would be interesting to apply this factory concept to other widgets like jQuery UI, YUI , and/or the Bootstrap plugins.
One final note: Kendo UI recently released their own native MVVM implementation. It has a Knockout flavor to some of the syntax and integrates well with the widgets. It is definitely an option to consider, if you are “all in” on Kendo UI.