Telerik blogs

Kendo UI is dipping its toe into the murky pool of web components and specifically Custom Elements. Since the Kendo UI 2015 Q3 release on September 30th, it's been possible to instantiate a widget using a custom element. Now you might be thinking, "Murky? Why would you say that?" I am saying this for many reasons, but I will limit my rationalization here to two reasons:

  1. Browser vendors are not in perfect harmony over the details of the specifications as of yet. ​This means native browser support is currently weak. Unless, of course, one uses a polyfill, but even then browser support is lacking (IE 11+ only). Consider that the least debated specification of four, Custom Elements, is only supported natively in Chrome & Opera today. 

    Kendo UI and the Web Component Pool 

  2. A consensus is rising that the value of each individual specification under the banner of "Web Components" is not yet realized in terms of real world development value. That is, the value of the specifications could, and more than likely will, come later when we (i.e. the community) find a use not conceived upon creation. This, of course, requires a reasonable amount of native adoption among browsers, so developers can have their way with it. Which is currently not the case.

Now, you might be thinking, "Why, after that rather optimistic perspective, are you guys offering a new instantiation pattern using custom elements?" Good question! The answer is simple. We are dipping our toe into a potential future, but pragmatically we know it is not yet a known future.

Given the quality of Kendo UI, we believe we owe it to our users to intelligently travel a few steps down any road that might help them be better developers. Can web components help you? Are they the future? Well, only time will tell. We all know that simply saying web components are the future does not make them the future. To assert with even a hint of dogma that they are the future clearly risks that the future is at worst nothing but a self-fulfilling prophecy.

Truth is, we don't know where this crazy web platform ride will take us. Anyone who says otherwise isn't being honest about where we have been and where we are going. Heck, today from a software perspective, a whole lot of the applications run on a platform that was only ever intended to share linked text documents. The web is still very much a wild frontier with frontier justice.

Now, if these new web component specifications do happen to become relevant and helpful to developers, regardless of the hype, we naturally want to be ready to give that to our users. After all, who wouldn't want to believe in the following sentiment?

By combining these four capabilities web developers can create declarative components (Custom Elements) which are fully encapsulated (Shadow DOM). These components can describe their own views (Template Element) and can be easily packaged for distribution to other developers (HTML Imports). When these specifications become available in all major browsers, we are likely to see developer creativity explode as many endeavor to create reusable components to solve common problems or address deficiencies in the standard HTML toolkit (from Databinding With Web Components). - Rob Eisenberg

I want to believe in a jQuery plugin utopia where plugins are native and all my problems melt away. It's just that nothing about the past would leave me to believe that this is the assured future. Instead, I think it will likely be the case that some aspect of the web component specifications might find itself embedded into the unknowable flow of the development stream. It is on that notion that we move forward, not because we know something you don't, but because we simply don't know which way the stream will flow. However, we know enough that we want to be prepared to move quickly if web components do find a path forward.

With that said, I will now explain our initial step into the web components space.

Instantiate Kendo UI Widgets Declaratively Using a Custom Kendo Element

As of the Q3 release, it​'s possible to declaratively instantiate a widget using custom HTML. Below I demonstrate how to create a Kendo UI DropDownList using a custom Kendo HTML element.



Once Kendo has determined that your browser supports the custom elements API the <kendo-dropdownlist> markup shown above will be turned into a custom HTML element and a widget instance (with the proper element) will become a child of the custom element. 

Kendo UI Custom Dropdown List

Any of the configuration options that are available to a widget can be passed as HTML attributes (e.g.
value="Orange").

To bind an event handler during instantiation, simply give the custom Kendo HTML an on-event="" attribute that names a function that can be accessed from the global scope.

<script>
var callbackFunction = function(){console.log('change fired!')};
</script>

<kendo-dropdownlist value="Orange" on-change="callbackFunction">
    <option>Black</option>
    <option>Orange</option>
    <option>Grey</option>
</kendo-dropdownlist>

As I've described, the use of custom elements will, of course, only work natively in recent versions of Chrome and Opera without a polyfill.

Since the Kendo UI implementation relies only on the Custom Element API, only the Custom Element API needs to be polyfilled for custom Kendo HTML to work properly in more browsers (e.g. IE10, Safari, and Firefox).

To do this you'll need to load one of the polyfills listed below before loading Kendo UI:

  1. <script src="document-register-element.js"></script>
    (Note: Only Polyfills Custom Elements for modern browsers and IE9+, android 2+, ios5+, and WP 7+)
  2. <script src="CustomElements.js"></script>
    (Note: Only Polyfills Custom Elements for current version of modern browsers and IE11+)

If you intend to use more than just the Custom Elements API from the Web Components specifications, then you can consider using one of the broader polyfills available:

  1. <script src="webcomponents-lite.js"></script>
    (Note: Polyfills Web Components API except Shadow DOM for current version of modern browsers and IE11+)
  2. <script src="webcomponents.js"></script>
    (Note: Polyfills Web Components DOM API for current version of modern browsers and IE11+ only)

At this time, using one of the comprehensive browser polyfills above is not a requirement for using custom Kendo UI elements because, like I've already stated, Kendo only uses the Custom Element API. Therefore, at this time, this is all that minimally needs to be polyfilled.

Invoking Kendo UI Methods on Custom Kendo DOM Elements

When a Kendo UI widget is instantiated using a custom Kendo HTML element, the instance is not created behind the scenes using the jQuery plugin pattern. Instead, the widget is created using the init() method and the instance becomes a child of the custom HTML element (i.e. <kendo-dropdownlist>), which literally inherits from the HTMLElement DOM Interface.

Invoking Kendo UI Methods on Custom Kendo DOM Elements

The methods associated with widgets (including inherited methods like bind()) are mixed into the prototypical inheritance chain of the custom Kendo HTML element. This means, to invoke a widget method you will have to call methods on the custom DOM element itself.

For example, to get the value of the DropDownList widget example we have been using in this article you could use one of the following lines of JavaScript:

//using jQuery
$('kendo-dropdownlist').get(0).value(); //logs "Orange"
$('kendo-dropdownlist')[0].value(); //logs "Orange"
 
//or not using jQuery
document.querySelector('kendo-dropdownlist').value();  //logs "Orange"

Why Use Custom Kendo Elements?

I​'ll close this article with three reasons why custom Kendo elements might be an appealing development option today.

  1. While jQuery remains a hard dependency, it is possible to avoid the jQuery instantiation pattern to create widgets by using custom Kendo elements instead. Additionally, after widget creation properties and methods are accessed off the custom DOM element itself instead of using jQuery methods.
  2. Using a custom Kendo element moves the markup itself closer to being semantically sound and this, potentially, has benefits for search engines and developers debugging and developing HTML markup.
  3. Having a simple interface (HTML & attributes) for creating Kendo UI widgets opens their usage up to developers who are not comfortable with JavaScript.

BlogBanner_KendoUI

cody-lindley
About the Author

Cody Lindley

Cody Lindley is a front-end developer working as a developer advocate for Telerik focused on the Kendo UI tools. He lives in Boise, ID with his wife and three children. You can read more about Cody on his site or follow him on Twitter at @codylindley.

Comments

Comments are disabled in preview mode.