From 0be142097570219d9d169efd336836f23a6e8636 Mon Sep 17 00:00:00 2001 From: gtrifidis Date: Tue, 5 Aug 2014 17:15:49 +0100 Subject: [PATCH] Improving performance setting widget data. options.dataIsSimpleJS is a simple property extending the binding options. The reason for adding this property is to avoid unnecessary iteration/subscriptions through a possibly large dataset. If we have a large dataset say > 35000 items the performance hit is quite big. Some browsers are not very forgiving (FF) and display non responsive script error. If the consumer knows that his data are consisted by simple js objects , he can just set the new flag to true to avoid the iteration. We could use the useKOTemplates to achieve the same , but it is not clear to me how that would affect now or in a future version consumer implementations. Having an option decicated for this usage is the cleanest way to address this issue. Here is a fiddle to demonstrate the performance difference using the useKOTemplates http://jsfiddle.net/gtrifidis/mC4Vw/14/ Just remove the useKOTemplates from the binding to see it. --- src/knockout-kendo-core.js | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/knockout-kendo-core.js b/src/knockout-kendo-core.js index dc5bba6..f72bc7e 100644 --- a/src/knockout-kendo-core.js +++ b/src/knockout-kendo-core.js @@ -256,8 +256,20 @@ ko.kendo.setDataSource = function(widget, data, options) { widget.setDataSource(data); return; } - - if (!options || !options.useKOTemplates) { + /* + options.dataIsSimpleJS is a simple property extending the binding options. + The reason for adding this property is to avoid unnecessary iteration/subscriptions through a possibly large dataset. + If we have a large dataset say > 35000 items the performance hit is quite big. Some browsers are not very forgiving (FF) and display non responsive script error. + If the consumer knows that his data are consisted by simple js objects , he can just set the new flag to true to avoid the iteration. + + We could use the useKOTemplates to achieve the same , but it is not clear to me how that would affect now or in a future version consumer implementations. + Having an option decicated for this usage is the cleanest way to address this issue. + Here is a fiddle to demonstrate the performance difference using the useKOTemplates + http://jsfiddle.net/gtrifidis/mC4Vw/14/ + Just remove the useKOTemplates from the binding to see it. + */ + + if (!options && (!options.dataIsSimpleJS || !options.useKOTemplates)) { isMapped = ko.mapping && data && data.__ko_mapping__; cleanData = data && isMapped ? ko.mapping.toJS(data) : ko.toJS(data); }