-
Notifications
You must be signed in to change notification settings - Fork 0
KendoUI control componentization
Note: use of the word component in this context means Aurelia component - not the KendoUI custom elements referred to as Web Components.
In order to ensure that KendoUI controls are compatible with Aurelia API we discussed the two different approaches to the process of extending HTML:
Using a specific KendoUI control - AutoComplete the team has analyzed which approach will result with a more natural behavior of this control in Aurelia application:
Case 1. - define AutoComplete as a custom element:
<auto-complete class="form-control" data.bind="autolist" options.bind="autooptions" value.bind="company"></auto-complete>Case 2. - define AutoComplete via custom attributes:
<input type="text" auto-complete="true" class="form-control" data.bind="autolist" options.bind="autooptions" value.bind="company" placeholder="myPlaceholder" />I certainly like both approaches, kind of heading towards thinking that approach 1 is nice because it's cleaner in the dom but it leaves open the fact that you'd have to forward all data to an input element in order to preserve the input based nature of the control...
Simply put, kendo requires an input, and people expect an input to be there somewhere, if our wrapper implicitly created that to host the kendo control it would be surprising behavior in my opinion
So 2. is the one for me
You put an input on the page and tell aurelia you want it to be a kendo powered one with a custom attribute. Then you bind to the expected property (value) and it just works.
That would be the ideal situation
Note this conclusion holds true for all KendoUI controls that are defined as variants of HTML 5 input control.
To componentize the KendoUI "input powered" controls we use a custom attribute available on an input tag.
To componentize the KendoUI "NOT input powered" controls we use custom elements.