Telerik blogs

As I was putting together the screencast last week for debugging with Kendo UI, I was thinking about all of the common mistakes that I routinely make. Some of them are simple silly errors that come from not reading the documentation, or simply writing bad code. The tricky thing about HTML5 development is that so much of it occurs in the browser, which is terribly forgiving and incredibly damning all at the same time.

The browser will do some degree of auto-correction for you. Notice that you have never been to a page that displayed the message "Unable To Build This Page". The browser is going to display the page as best it can no matter what happens. Even if you do something completely illegal like trying to nest an anchor inside of an anchor, the browser will try and display this for you. What you have probably seen even more often is that if you forget to close a tag, the browser decides where to close it for you. This can give you some pretty unexpected results.

In terms of JavaScript, there is never anything to tell you that you are about to call a method that doesn't exist, or you are trying to use a property that is not on an object. In fact, if you simply set a property that doesn't exist on an object, it will be added to that object.

Setting A Property That Doesn't Exist

// user object has a first and last name
var user = {
  firstName: "Walter",
  lastName : "White"
};

// set the name property which does NOT exist
user.name = "Walter White";

// it exists now!
console.log(user.name);

 

Another thing that "some" browsers will do is hoist your variable into the global namespace if you try to use it, but it isn't defined.

Using A Variable That Doesn't Exist

// user variable doesn't exist
user = "Jessie";
console.log(window.user);

 

Not that not all browsers will handle this. IE 8 will just tell you that the object "doesn't support this property or method", which is not at all what is happening.

So given the massive amount of freedom that you have, you need to be very attentive to details. Get used to checking your syntax visually as your IDE probably isn't going to be much help there when it comes to JavaScript.

You have some tools that you can use as well to help you check your code to make sure it's well formed. Your primary tool is of course your browser's developer tools. That should be the first place that you look when you are not getting the results that you coded for. Another tool that you can use to check your syntax is JSHint.

JSHint

JSHint is a fork of the JSLint utility released by Douglas Crockford. The reason why so many people prefer JSHint over JSLint, is that JSLint will complain loudly about improper spacing and other things that are not errors, but really just style. However, there is firm support from the community that we should all format our JavaScript the same way. For instance, see Rick Walron's Idiomatic JavaScript.

JSHint will tell you if your JavaScript is malformed. If you forget a semicolon, a comma or try to use a variable that doesn't exist. All of the things that might cause your code to straight up break in the browser. You should always "lint" your code before you run it as a double check that you didn't make any errors. If you don't, you will be popping back and forth between your browser and your IDE a lot as you discover all of the small syntax errors you made when the browser complains about it.

To use JSHint, you have several options. Of course, you really want to use it in your IDE. You can add it as a package in Sublime Text 2. There are several, but the "SublimeLinter" appears to be the most feature rich. If you are using Visual Studio, you can add the Web Essentials, which includes JSHint. In both of these, each time you save a JavaScript file it will be linted with JSHint and any errors displayed. The errors should be fixed. Warnings are more of a "heads up" as they may or may not represent a real issue.

Common Kendo UI Mistakes

Now that we have some ground work for doing "idiot checks" on our code, lets look at some of the common mistakes that can be made in Kendo UI so that you can know what to look out for. Some of this material comes from the Troubleshooting Guide in the documentation.

jQuery Is Not Defined

You will see this error if you include your Kendo UI Scripts before you include jQuery. Make sure that jQuery is included before Kendo UI as the browser loads these scripts synchronously and Kendo UI depends on jQuery being first.

[object Object] Has No Method kendoGrid

You may also see it as...

  • $("#grid").kendoGrid is not a function (FireFox)
  • Object doesn't support the property of method "kendoGrid" (IE 9+)
  • Object doesn't support this property or method (IE 8-)

This can occur for a variety of reasons:

  1. You have not included Kendo UI at all
  2. You are referencing the wrong path to Kendo in your page
  3. You include jQuery both before and after Kendo UI which wipes out Kendo

Things Don't Look Quite Right

If you don't include the proper CSS files and assets, your widgets may not look right. What you need depends on what type of application you are building:

Web And DataViz

  1. kendo.common.css
  2. a kendo css theme file (default.css or other theme)
  3. The textures and images folders which contain assets for the stylesheets

Mobile

  1. Either kendo.mobile.all.css or the css file of the platform you are targeting (i.e. kendo.android.css)
  2. The textures and images folders which contain assets for the stylesheets

If you have specified the path incorrectly for these stylesheets, they won't be loaded and your application won't look correct. Always make sure to use your browser developer tools to specify that all of your stylesheets and scripts have been loaded. You can do this by inspecting the Network tab in your developer tools and making sure that you are not getting a 404 error for any of the required stylesheets or JavaScripts.

Casing Errors

JavaScript is a case sensitive language. This means that "dataSource" is not the same as "datasource". That's such a innocuous error that it often slips by unnoticed. It's one that you are going to see the effects of right away though because you won't have any data in your widget.

Casing Errors

// this code doesn't work because the grid doesn't contain a datasource property
$("#dropdown").kendoDropDownList({
    datasource: {
        data: ["Gus", "Hector", "Tuco"]
    }
});

// this is the correct version. 
// notice how hard it is to catch the difference unless you know to look for it
$("#dropdown").kendoDropDownList({
    dataSource: {
        data: ["Gus", "Hector", "Tuco"]
    }
});

 

That's one that I made in the screencast yesterday. Also, data-role="listview" is not the same as data-role=”listView”. The second one will give you nothing, while the first creates a Kendo UI Mobile ListView. In the case of roles, all of the Kendo UI role attributes are lower case.

Declarative Initialization Errors

This is one I see with some frequency. Once you get used to it, it doesn't really show up anymore. When you are using Kendo UI with declarative initialization, you will find yourself needing to translate JavaScript properties into HTM5 Data Attributes. For instance, you may have a DropDown List and you want to set the dataTextField. Your first inclination on how to do this might be to code data-textField="name", but this is wrong. The correct way to do it is to separate the words with a dash delimiter. The correct form is data-text-field.

<div data-role="dropdownlist" data-source="MYAPP.cities" data-text-field="name" data-value-field="value"></div>

<script>

    $(function () {

        window.MYAPP = {};

        window.MYAPP.cities = new kendo.data.DataSource({
            data: [{ id:1, name:"Jaurez" }, { id:2, name: "Albuquerque" }] 
        });

        kendo.bind(document.body);

    });

</script>

 

Data Attributes by definition are not cased. This is true even in jQuery. For instance, if you add a mixed case HTML5 data attribute to your tag and you try to read it with jQuery as mixed case, you will get nothing. You have to read it as lower case.

//this returns nothing because data attributes are lowercase
var result = $("#skyler").data("carWash");
$("#log").html(result);

// this returns the value of data-myField
var result = $("#skyler").data("carwash");
$("#log").html(result);

 

Beware The Cross Domain Barrier

If you weren't already aware, you cannot use AJAX to call for data that resides on another domain or port. This means that if your application is running at app.mycompany.com, you can call a service located at service.mycompany.com, but you CANNOT call a service that resides at service.myservices.com. MyCompany and MyServices are different domains. You can see blocked requests in the browser developer tools.

The browser will block your request for JSON or XML. If you have to call services on different a different domain, you have a few options.

  1. JSONP

JSONP is not the same as JSON. It's a JSON string wrapped in a random JavaScript callback that fools the browser into thinking that you made a request for some JavaScript, not a JSON file. The server that is returning the JSON must support JSONP in order to use it as its up to the server to wrap it up for you. Kendo UI handles JSONP just fine and it's a great alternative if you have control over returning the data as JSONP.

  1. CORS

Short for Cross-Origin Resource Sharing, this new standard is not supported in all browsers and even has quirks in some modern browsers. This is the concept of specifying a cross domain policy which allows communication with a specific external server when that server is marked as safe.

Use The Correct HTML Tags When Initializing Widgets

For the most part, this isn't a problem. However, when you have input widgets - like the Numeric TextBox and AutoComplete, you need to use an input tag to initialize the widget. If you use some other tag, you will see the widget but you won't be able to type in it because it's not an input element.

Malformed HTML

You need to know that the HTML that you are writing is indeed valid. Many IDE's will do this for you. For instance, you cannot nest anchor in an anchor as I mentioned earlier. You cannot nest an input inside of an input and so on.

When in doubt, run your HTML through the W3C markup validation service. You can either upload your file, paste the html in directly, or just point the validator at a page if the page is publicly available.

Having malformed HTML will cause you a world of problems, not the least of which is going to be sporadic functionality across browsers.  Kendo UI requires that your HTML be valid.

Markup And Mobile

When it comes to Kendo UI Mobile, having your HTML structured correctly is of the utmost importance. Even if it's valid, it has to be formed right as per the documentation. Kendo UI Mobile requires a valid mobile application to be correctly defined with HTML. For instance, you cannot use a NavBar widget without putting it in a header. You cannot use a TabStrip without putting it in a footer. If you try to do either of those two things, nothing will happen. If your mobile application is not rendering like you think it should, it's highly likely that your HTML is simply not correct. Double check the documentation for Kendo UI Mobile to make sure that your code matches what is specified in the docs and examples.

Use Your Developer Tools

The biggest favor you can do yourself when building HTML5 applications is to get up close and personal with your browser's developer tools. I'm even going to go so far as to suggest that you use either Chrome or FireFox if you can as the browser tools there are really a cut above everything else. These tools will be the difference between blind guessing and intelligent problem solving.

When you do become comfortable debugging inside a browser, you will see with a tremendous amount of clarity that only a runtime environment like the web can provide. You will iterate faster, code cleaner and learn quickly from your mistakes.


Burke Holland is the Director of Developer Relations at Telerik
About the Author

Burke Holland

Burke Holland is a web developer living in Nashville, TN and was the Director of Developer Relations at Progress. He enjoys working with and meeting developers who are building mobile apps with jQuery / HTML5 and loves to hack on social API's. Burke worked for Progress as a Developer Advocate focusing on Kendo UI.

Comments

Comments are disabled in preview mode.