JavaScript is an important part of building any interactive website, and SharePoint is certainly no exception. With SharePoint, JavaScript is often used to execute code on the client and it is usually designed to affect only one specific Web Part, as opposed to affecting an entire page. So, in a typical SharePoint page where there are many Web Parts in a zone, it's very easy to mistakenly write Java code that affects another Web Part.  The potential for such conflicts is unavoidable, so this article details some best practices for working on JavaScript and SharePoint Web Parts in SharePoint 2010.

1) Check for "Null" value

SharePoint is predominantly in use on IE browsers, but the issue of null values should be seriously considered for non-IE browsers. As you probably know, when an error occurs, the subsequent code is not executed within IE.  However, on other browsers such as Firefox, only the function or block of code that produced the error is skipped, while the remaining code still gets executed. Therefore, to make sure that the error code is contained, check whether the variable is null or not.

Ex 1:
 

The code line at 2 should be checked for Null reference object. It looks like:

 

The Null value is also related to a number of predefined objects such as window.event. When we are working on SharePoint 2007, we usually do not think about the Event object on Firefox. But if we reflect the client object model in SharePoint 2010, we would see that it seems to provide support for Firefox, and so we must change our mind and think about how our code should be designed to work on both IE and Firefox, especially for the window.event call.

Here is an example of an HTML object:

Ex 2: I have an object, and I want to get an object when I do mouseover on it.

 

For IE:

  

But on Firefox:

So, for the code to work on both IE and Firefox, it should be revised like so:

 

Now back to the example 1, at line 4:

var parent = panel.parentElement

That code will not work in Firefox; we should use parentNode instead. The code is now:

var parent = panel.parentElement || panel.parentNode

or

var parent = panel.parentNode

2) Define the duplicate function name or overwrite function

Here is a mistake that is easily made, because sometimes we don't know if a similarly named function has been defined before in the same instance.  So when we call this function, it might not run properly and we frequently do not know whether it called our function or another function that had already been defined by another Web Part.

To solve this problem, we should add a unique string of characters to the function name, and we often employ the Web Part ID to ensure that the defined function does not conflict with another Web Part.

function M_Over_[Your_Web_Part_ID]() {
   // TODO: do something
}

In another case, if the function belongs to a system or JavaScript event, then what should we do? For example, there are two Web Parts in the Web Part zone and the first Web Part already defined a handler for window.onload, and the second Web Part also wishes to define something in window.onload. How do we solve this problem? Most developers would declare something impartially in the window.onload. Now let's take a look at an example:

 

Ex 3:

So, when the user accesses this site, what will happen? Our first Web Part will execute window.onload after the code is loaded, but the last defined code of window.onload will still be executed because it was defined at the end of the block, and thus the first Web Part might not work as designed. The overwrite function or redefining of the function should follow these instructions:

a) Check if the function/event already exists
b) Backup if it was found to exist already
c) Redefine the function/event
d) Restore the backup code

Now, to be clear about this process, let's look at the example below:

 Ex 4:

 

With the window and document event, we must use the above process to avoid the error, because features such as the SharePoint 2010 Ribbon Menu need to initialize at window.onload event. You will get an error such as the one shown in the image below when you try to click on any command of Ribbon:

  

3)  Position is always zero in SharePoint 2010

I have built a Web Part that works nicely in SharePoint 2007 and the position of the drop down menu renders correctly, but in SharePoint 2010 it always renders (incorrectly) at the top of the page:

In debugging the JavaScript code, I found that the document.body.scrollTop always returns "0" (which is not equal to zero if this code runs on SharePoint 2007).  In fact, it always takes the value zero from the DTD formatter of the site's master page.  If you take a look of the site source,  you will see at the top of the page something like:

And not just with this format, but others such as transitional.dtd, strict.dtd…etc. also set the value of scrollTop to zero. In SharePoint 2007, the DTD only appears in some master pages, but in SharePoint 2010, most sites implement the DTD, so we must change the code to something like this:

 

I hope that this article will help you develop some good habits writing JavaScript in SharePoint 2010.