After downloading KendoUI v 2016.3.914, I noticed that the way the AMD dependencies are defined has changed since previous versions (I'm working off of v2015.3.1111 for reference). In the newer versions of KendoUI, each component appears to define all of the common functionality it will need in separate AMD definition blocks. For instance, dataviz.barcode.js now has sections for "util/main", "util/text-metrics", "util/base64", "mixins/observers", and the actual "kendo.dataviz.barcode" component. In v2015.3.1111 and before, there was only the block for "kendo.dataviz.barcode". This is the case for a number of components, many of which contain the exact same definitions for those common AMD definitions (for instance, util/main is defined in multiple files) which means that we are loading unnecessarily large files if we load multiple files with the same common dependencies.
I realize that the reason for the change was to allow components to work more autonomously, but I was wondering if there is any distribution of the Kendo assets which behaves more like the older versions of Kendo and strip out the common AMD dependencies to core files, or to individual files per dependency? I know that the current versions contain files like kendo.all.js and kendo.web.js for common functionality, but I was hoping to avoid these larger files. Essentially, we want a similar setup to how v2015.3.1111 where all modules appear only once (i.e. we don't want to repeatedly see util/main in different files) with their dependencies. For our case, we dynamically combo-load kendo assets based on what a particular page of ours needs, so we need to understand the dependency tree prior to loading the page and don’t want to load duplicates.
5 Answers, 1 is accepted
Your observation is correct that we changed the way that the files are bundled. There are a couple of different ways to achieve custom scripts in your scenario as I understand it:
- Use Gulp:
http://docs.telerik.com/kendo-ui/intro/installation/what-you-need#use-gulp
- Employ the Custom Download Builder tool:
www.telerik.com/download/custom-download
The dependencies for different widgets are listed separately in our documentation within the Additional Resources folder. For your convenience, the script files(dependencies) for Kendo UI DataViz Barcode is available at:
http://docs.telerik.com/kendo-ui/intro/supporting/scripts-barcodes
The complete information for combining scripts and some important notes that I believe you should read through are listed in the documentation at:
http://docs.telerik.com/kendo-ui/intro/installation/what-you-need#only-what-you-need
Kind Regards,
Alex Hajigeorgieva
Telerik by Progress
Rank 1
Hi Alex, thank you for your response.
I looked at most of those references and actually used the custom download builder when creating my build, but my issue still exists. I have each individual kendo module, but many of them include code for the same AMD components. For instance, "barcode" includes "util/main", and so does "grid." If I have both of those components on the page at the same time, that means I have to load the exact same code for "util/main" twice, even though it's only needed once. My question was more focused on separating out those internal dependencies (the "util/main", "mixins/observers", etc), and including a dependency to the appropriate internal dependency in each kendo module.
To illustrate this example, for the barcode file, there are 4 AMD defined code blocks. "util/main", "util/text-metrics" (which requires "util/main"), "util/base64" (which requires "util/main"), "mixin/observers", and the actual module "kendo.dataviz.barcode" (which only requires "kendo.dataviz.core" and "kendo.drawing"). Instead of this approach, could there be separate files for the different internal dependencies, then have "kendo.dataviz.barcode" depend on "kendo.dataviz.core", "kendo.drawing", util/main", "util/text-metrics", "util/base64", and "mixin/observers" (or have util and mixin modules which contain all of the specific modules like main, text-metrics, and base64 for util).
I haven't tried the gulp distribution because it looks like it will yield the same results as the custom download, but if there is a way to reconfigure the gulp approach to achieve those results that could work.
I am afraid that you are correct to conclude that Gulp will produce the same results as the custom download builder tool. To discard internal dependencies if they have been loaded in another script is not a readily available option. Changing the modules in that way may pose a breaking change for other clients, therefore, there are no such plans at present.
I am sorry I was not the bearer of better news.
Sincerely,
Alex Hajigeorgieva
Telerik by Progress
Rank 1
Hi Alex,
I don't see how this would need to be a breaking change. We aren't asking for the current option to be removed, just to have another download available that isn't pre-processed to add this redundant code.
I have to assume that when your developers write this code they don't copy around the util/main definitions from file to file and that these instead get duplicated around by some pre-processing step before you publish. If that's the case, all we're asking for is to have the option of downloading a distribution without this pre-processing step.
-Mike
The script files which you receive in the Kendo UI releases and download from our internal builds are exactly the same ones which reside in our open source and private repositories (I cannot share the barcode with you because it is part of our Professional Suite):
https://github.com/telerik/kendo-ui-core/tree/master/src
The source files do not get preprocessed, their definitions are added when a new widget is created or updated when we need another module to implement an enhancement (this is required by RequireJS).
Additionally, most module loading systems nowadays are clever enough not to require a file which has already been loaded:
http://stackoverflow.com/questions/7866971/how-does-amd-specifically-requirejs-handle-dependancies-across-multiple-module
I hope my explanations now make it clearer why we do not see the need to designate an engineer to prepare a custom distribution which will bring no measurable benefits to our clients.
Kind Regards,
Alex Hajigeorgieva
Telerik by Progress