Javascript - Usefull Tips & Tricks

[coaststar]

helped alot- everything on the page

[Maian]

My object-oriented version of parsing the query string:

/* usage example:
//assuming location.search = '?n1=v1&n2=v2&n3=v3'
var qs = new QueryString(location.search);
alert(qs);    //outputs ?n1=v1&n2=v2&n3=v3
alert(qs.string);    //outputs ?n1=v1&n2=v2&n3=v3 (quicker than toString() since it's direct property access)
alert(qs.length);
alert(qs.n1);    //outputs v1
alert(qs.n2);    //outputs v2
alert(qs.n3);    //outputs v3
for (var i = 0; i < qs.length; i++) {
    alert(qs[i]);    //outputs <name>=<value>
    alert(qs[i].name);    //outputs <name>
    alert(qs[i].value);    //outputs <value>
}
*/
window.QueryString = function(str) {
    this.string = str;    //this.string is faster than this.toString()
    this.length = 0;
    var re = /[?&]([^\s=]+)=([^\s&]*)/g;
    var match = re.exec(str);
    while (match) {
        var name = match[1];
        var value = decodeURI(match[2]);
        this[name] = value;
        this[this.length] = new QueryString.Pair(name, value);
        this.length++;
        match = re.exec(str);
    }
}

QueryString.prototype.toString = function() {
    return this.string;
}

QueryString.Pair = function(name, value) {
    this.name = name;
    this.value = value;
}

QueryString.Pair.prototype.toString = function() {
    return this.name + '=' + this.value;
} 

[Maian]

Some random esoteric notes on Javascript and DOM perks, performance, bugs, and compatibility. Some info might be somewhat outdated, so use the info at your own risk.

EDIT: moved this to my own semi-temporary website: maian.50webs.com

[Ultimater]

Ha! My school teaching grounds

Instead of writing:

<script type="text/javascript">
var text = "The meeting this week will be at ";
  var nowDate = new Date();
  var currDate = nowDate.getDate();

switch(currDate) {
  case 1:
  case 2:
  case 3:
  case 4:
    document.write(text + "Steve's house");
    break;
  case 5:
  case 6:
  case 7:
  case 8:
  case 9:
  case 10:
  case 11:
    document.write(text + "Nancy's house");
    break;
  case 12:
  case 13:
  case 14:
  case 15:
  case 16:
  case 17:
  case 18:
    document.write(text + "Mike's house");
    break;
  default:
    document.write(text + "Sally's house");
    break;
  }
</script>

You can write it like this:

<script type="text/javascript">
var text = "The meeting this week will be at ";
  var nowDate = new Date();
  var currDate = nowDate.getDate();
  switch(true) {
  case (currDate < 5) && (currDate > 0):
    document.write(text + "Steve's house");
    break;
  case (currDate < 12) && (currDate > 4):
    document.write(text + "Nancy's house");
    break;
  case (currDate < 19) && (currDate > 11):
    document.write(text + "Mike's house");
    break;
  default:
    document.write(text + "Sally's house");
    break;
  }
</script>

[Ultimater]

eval() can be replaced by window[] in alot of cases.

<script type="text/javascript">
var a="alert"
var b="hi"
eval(a+"(\""+b+"\")")
window[a]([b])

</script>

[beetle]

eval() can be replaced by window[] in alot of cases.

Only when making object references that descend from the window object.

What you're really trying to point out is that bracket-notation is the better choice for member access.

[Ultimater]

Yeah that too, eval() is known to lock up system resources.
Instead of making a function like this, which I see people making all the time:

function getEl(id){
if(document.getElementById)
return document.getElementById(id)
else if(document.all)
return eval("document.all."+id)
else if(document.layers)
return eval("document."+id)
else return null
}

Avoid eval() by doing this:

function getEl(id){
if(document.getElementById)
return document.getElementById(id)
else if(document.all)
return document.all[id]
else if(document.layers)
return document[id]
else return null
}

But If you were going to make such a function in the first place, do it right:

if(!document.getElementById){

if(document.all)document.getElementById=function(){
if(typeof document.all[arguments[0]]!="undefined")return document.all[arguments[0]];else return null
}
else if(document.layers)document.getElementById=function(){
if(typeof document[arguments[0]]!="undefined")return document[arguments[0]];else return null
}

}

//This code was programmed by me, Ultimater

[Ultimater]

window[] can replace eval() when refering to global variables too:

<script type="text/javascript">
var my_message="hello world"
var a_var="my_message"
alert(eval(a_var))
alert(window[a_var])
</script>

[Kravvitz]

Why is arguments[0] better than the name of the first argument?

[Ultimater]

Why is arguments[0] better than the name of the first argument?

It's a more generic way of referring to the first argument.
A lot of times you later change the name of your argument as you enhance your function and forget to change crucial code inside the function that uses the old name.

Believe it or not I even needed to edit my last post because I first called the argument el then decided later to call it id because it is a string and not an element. Thus, I left one instance of the old name floating in my code and had to edit my post.

Just for the record,
arguments[0] can always be used to refer to the first argument whether or not you named the argument.
When you assign a name for an argument, I'd assume the function runs a minute(a bit) slower because there are now two variables able to access the same thing.
Which before there was only one -- arguments[0].
Thus, it's an extra statement assigns your name to the argument.

Both ways are correct, and the choice is up to you.

But that is not the main idea I'm trying to get across.

[Ultimater]

The reason why my last code is better (than my other two example functions) is because it only defines the document.getElementById function if it's undefined -- which occurs when the user is using an old browser.

If the user is indeed using an old browser, my last code still runs faster (than my other two example functions) because it performs all of it's document.all and document.layer if-checks only once -- to define the document.getElementById function rather than each time the function is run.

Also, notice how my function is able to return null if no such object is found -- just like the real document.getElementById function.

[Ultimater]

Some Uncommon Information about Math.random:
Math.random returns a random number greater than or equal to zero but smaller than and excluding one. Therefore it is possible for it to return an actual zero but not a one
(which is very unlikely, the odds are about one in ten quadrillion[10^16]).
Source: http://www.ecma-international.org/pu...T/Ecma-262.pdf
(15.8.2.14 PDF page 128)

Furthermore, when mixing Math.round and Math.random, be cautious. The following may seem like it produces random numbers but the odds of getting certain numbers are amazingly sliced in half!:

alert(Math.round(Math.random()*3))

In the above statement, the chances of getting a zero or three are cut in half!
(because it's range is from 0 through 3)

Math.random()*3
0.0 - 0.49 rounds to a 0
0.5 - 1.49 rounds to a 1
1.5 - 2.49 rounds to a 2
2.5 - 3.00 rounds to a 3

Here is a safe way to mix the two:

alert(Math.round(  (Math.random()*3)-0.5  ))

(Note: if Math.random returns a zero, the above will alert a zero)

I'd strongly suggest using Math.floor in place of Math.round.

Math.floor is basicly a function that always brings the number to the floor or rounds down.
Math.ceil is basicly a function that always addes a ceiling to the number or rounds up.

Safe Math.floor alternitive:

alert(Math.floor( Math.random()*4) )

Unsafe Math.ceil alternitive:

alert(Math.ceil( Math.random()*4)-1 )

Can't use the above because it can return a -1 if Math.random returns an exact 0.

Here's my mighty new Math.random function:

function safeRand(){
var r=Math.random();
if(r==0){return safeRand()}
return r;
}

Now let's put the two together:

Safe Math.ceil alternitive:

function safeRand(){
var r=Math.random();
if(r==0){return safeRand()}
return r;
}
alert(Math.ceil( safeRand()*4)-1 )

[Maian]

Labelled statements, break, and continue

These are actually features of any C-style language. Any statement can be labelled, and continue and break statements can target them:

outer: for (var i = 0; i < 5; i++)
  for (var j = 0; j < 10; j++) {
    document.write('[' + i + ','+ j + ']');
    if (j == 1)
      break outer;
  }

As that example shows, the |break outer;| ends execution of the whole loop. This example outputs: [0,0][0,1]

outer: for (var i = 0; i < 5; i++)
  for (var j = 0; j < 10; j++) {
    document.write('[' + i + ','+ j + ']');
    if (j == 1)
      continue outer;
  }

In this example, the |continue outer;| skips the rest of the current iteration and goes to the next iteration of the loop. This example outputs: [0,0][0,1][1,0][1,1][2,0][2,1][3,0][3,1][4,0][4,1]

Break and continue statements can only target labels they are nested in. That means they can't be used as a generic goto statement. For example,

label: some_statement;
//...
break label;

wouldn't work.

Labelled statements and break, revisited

The above are pretty well-known features. Now comes the interesting part.

label: if (cond) {
  for (var i = 0; i < 10; i++)
    if (obj == null)
      break label;
  alert('obj has no null elements');
}

That would work exactly how'd you expect it to work. That's right - any statement can be a label, and breaks can target them in the same way. The only differences are:

1. The continue statement can't be used here - continue statements can only be used on loops.
2. The breaks must have label targets - it must be |break label;| instead of just |break;|. |break;| would only work in loops.

That's not all. There's another statement that can be used to abstract this break to label functionality to anything: the block statement, i.e. |{ ... }|.

label: {
  for (var i = 0; i < 10; i++)
    if (obj == null)
      break label;
  alert('obj has no null elements');
}

That's the same as the above, except without the |if|. This means there's no need for weird hacks like this:

label: do {
  if (cond1)
    break label;
  statement1;
  statement2;
  statement3;
  statement4;
  if (cond2)
    break label;
  statement5;
  statement6;
} while (0);

or equivalently:

if (cond2) {
  statement1;
  statement2;
  statement3;
  statement4;
} else if (!cond1) {
  statement1;
  statement2;
  statement3;
  statement4;
  statement5;
  statement6;
}

They can be replaced with:

label: {
  if (cond1)
    break label;
  statement1;
  statement2;
  statement3;
  statement4;
  if (cond2)
    break label;
  statement5;
  statement6;
}

A note on block statements

Unlike C/C++, the block statement in JS does not introduce a new scope. For example, in C++:

int a = 1;
{
  int a = 2;
  cout << a;
}
cout << a;

would output: 12.

The equivalent in JS (in the HTML environment):

var a = 1;
{
  var a = 2;
  document.write(a);
}
document.write(a);

would output: 22. That means, that the inner a and the outer a are actually the same thing. To illustrate the point further:

{
  int a = 1;
  cout << a;
}
cout << a;

would be a syntax error in C++, while the equivalent in JS:

{
  var a = 1;
  document.write(a);
}
document.write(a);

would output: 11.

[Ultimater]

All about the OR and AND operators

A simple OR example that would alert "true" is:

<script type="text/javascript">
alert(true||false)
//alerts "true"
</script>

Now what most people don't know is that the following actually alerts "first stuff" rather than "true":

<script type="text/javascript">
alert("first stuff"||"second stuff")
//alerts "first stuff"
</script>

The reason for that is because anything that isn't 0, false, or null is treated as though it were "true" and the OR operator isn't limited to returning either true or false like most operators are (it can return "first stuff" in my example). Also the OR operator first "looks at" the first argument and checks if the first argument is true or false then only if the first argument is false does the OR operator ever look at the second argument. In otherwords meaning if the first argument is true then it doesn't matter if the second argument is true or false because either way the OR operator only needs one true in order to return true (really the first argument). Only if two falses are found does the OR operator return false (really the second argument)

<script type="text/javascript">
function a1s(){alert("function a1s() has been called");return true}
function a2s(){alert("function a2s() has been called");return true}
if(a1s()||a2s())alert(true)

//alerts "function a1s() has been called"
//alerts "true"
</script>

<script type="text/javascript">
if("first stuff")alert("true")
//alerts "true"
</script>

The following will alert "second stuff":

<script type="text/javascript">
alert(false||"second stuff")
//alerts "second stuff"
</script>

Let's go a bit further:

<script type="text/javascript">
var v1="first stuff"
var v2="second stuff"
if(v1){
var v3=v1
}
else{
v3=v2
}
alert(v3)
//alerts "first stuff"
</script>

Some fancy foot-work:

<script type="text/javascript">
var v1="first stuff"
var v2="second stuff"
var v3=(v1)?v1:v2
alert(v3)
//alerts "first stuff"
</script>

And the grand finale:

<script type="text/javascript">
var v1="first stuff"
var v2="second stuff"
var v3=v1||v2
alert(v3)
//alerts "first stuff"
</script>

Also don't confuse the OR operator(||) with the Bitwise OR-operator(|):

<script type="text/javascript">
alert(3516|1354)
//alerts "3582"
</script>

You are probably thinking, "How in the world does that alert 3582!?"
Here's an explaination:
3516 in Binary is 110110111100
1354 in Binary is 010101001010

110110111100
010101001010
______________
110111111110

110111111110 in Decimal is 3582

Might as well teach you the bitwise AND operator now lol. Don't confuse the AND operator(&&) with the Bitwise-AND operator(&).

<script type="text/javascript">
alert(3516&1354)
//alerts "1288"
</script>

Here's an explaination:
3516 in Binary is 110110111100
1354 in Binary is 010101001010

110110111100
010101001010
______________
010100001000

010100001000 in decimal is 1288



Finally, similar to the OR operator, the AND operator doesn't need to "look at" both arguments either:

<script type="text/javascript">
function a1s(){alert("function a1s() has been called");return false}
function a2s(){alert("function a2s() has been called");return false}
if(a1s()&&a2s())alert(true)
else alert(false)
//alerts "function a1s() has been called"
//alerts "false"
</script>

In order for the AND operator to return true (really the second argument), it needs both arguments to be true otherwise it returns false (really the second argument).

And the Grand Finale Finale lol:

<script type="text/javascript">
alert("first stuff"&&"second stuff")//alerts "second stuff"
alert("first stuff"||"second stuff")//alerts "first stuff"
</script>

Sorry for miss-calling my grand finales.

[Sjoerd]

Here are some tips concerning the syntax of javascript code. It is not a "must do", but it will make your code easier to read for others.

First of all, always put a semicolon ( ; ) at the end of a line where it is needed, so on every line which does not contain an if-else-end, for, while or switch-case structure. Also, put every new command on a new line, so don't heap up a lot of code on the same line.

Now for the brackets. A lot of people use C-style brackets, meaning that the opening bracket is on the same line as the if() command. Although this might seem professional, it does not help to make your code easy to understand. Propose that you want to remove an if() command, you should then also remove the matching bracket. But when you put the opening bracket on the same line as the if(), it is not easy to spot which closing bracket to remove. You should also always use brackets after an if() command, also if only one command will follow after it:

Wrong example:

if (argument1 != argument2) {
	dosomething(); andsomethingelse()
	if (a1 == b2) {
		return blaat();
	} else {
		if (sdf == fsd)
			return test();
	}
}

Good example

if (argument1 != argument2)
{
	dosomething();
	andsomethingelse();

	if (a1 == b2)
	{
		return blaat();
	}
	else
	{
		if (sdf == fsd)
		{
			return test();
		}
	}
}

Please note that I also put the brackets in front of and after "else" on a new line. When you want to remove an if statement now, you can easily spot all other code which needs to be adjusted.

Another thing which a lot of people do clumsy, is commenting their code. If you place comments, always place them above the line you actually want to tell something about. Do not put your comments at the end of a line, even if they are tiny ones. Also, when you have a big block of code (like a user defined function), you do not need to comment every line, just make sure the code itself works like it should, and only tell what the function returns and how you should use it.

// Function which does difficult things, returns a
// string with details about the user (or something :P)
// Needs no parameters
function example_function()
{
	//big block of code here
	//big block of code here
	//big block of code here
	//big block of code here
	//big block of code here
	//big block of code here
	//big block of code here
	return "You are running a browser!";
}

// This example code will call a function and return it to the user
var strVariable;

strVariable = example_function();
window.alert(strVariable);

As long as you make sure no bugs are in the functions, that's all the user needs to know...

I hope someone can take advantages with these tips. For the comments, most of the times you will still remember why and how you did something, but if other people need to use the same code, it is nice if they can use it right away, without them having to read it four times...

[Maian]

That bracket thing is a matter of style. I like my code as condense as possible - it allows me to see a "bigger picture" in a way. The point about finding closing brackets is a rather moot as well, since the if statement and the closing bracket will have the same number of indents.

I also will use whatever I deem looks concise and elegant enough. For example:

var x = cond1? a
  : cond2? b
  : cond3? c
  : d;

looks clean enough to me, so I'll use such a construct. Another example:

function empty() {}

I always use semicolons except with function expressions, since I consider it inconsistent with function declarations. It also never produces any ambiguities. Ex:

var x = function() {
  alert('hi');
}
//notice the lack of a semicolon after this statement

Concerning commenting, commenting isn't always good. One of the worst practices I've seen is useless commenting. For example:

// Set x to y.
var x = y;

Well...hello Mr. Obvious.

[arun9810128800]

thanks 4 trip

[Maian]

1)
Include js version in the language attribute, e.g.
<script type="text/javascript" language="JavaScript1.4">

Useful if you want to "hide" code from older browsers
E.g. if you use try...catch statements (v 1.4)

That doesn't work in any browser except ones derived from Mozilla, and Firefox 1.5+ versions won't support this feature anymore.

[SpaceFrog]

I don't know if any of yo have already encountered difficulties in retrieving count of childNodes.
It appears that IE ans Moz do not return same count as Moz FFX finds empty text nodes where you normaly should not find them ...

here is the script a friend gave me that I use to clean undesired nodes and retrieve correct node count ...

function go(c){
if(c){ 
        if(c.nodeType!=1 && !c.data.replace(/\s/g,'')){
            c.parentNode.removeChild(c)
            }
        }
}

function cleanNodes(d){
    var bal=d.getElementsByTagName('*');
    for(i=0;i<bal.length;i++){
        var a=bal[i].previousSibling;go(a);
        var b=bal[i].nextSibling;go(b);
    }
    
} 

launch with

cleanNodes(document.body) 

on the body onload to clean all empty nodes found by ffx...

[dek]

I've been getting a lot out of this thread, so thought it's time to contribute a couple of useful things:

For those who've been looking at the new Javascript 1.5 reference being touted by Mozilla, and feeling frustrated by the fact that we won't be able to use many of the lovely new features on the majority of browsers for a while...

Example: the Array object is getting a few nice new functions. Let's take two of them: indexOf and forEach. Don't they look handy? But we can't take them for granted for a long time to come...

Actually, we can quite happily use them now. This is another of those 'What many people don't know about Javascript' things.
We can extend existing global object types.

Try this:

 <script type="text/javascript">
 if (!Array.prototype.indexOf) {
 	Array.prototype.indexOf = function(val) {
 		for (var item,index = 0; ( item = this[index] ); index++) {
 			if (val == item) {
 				return index;
 			}
 		}
 		return -1;
 	}
 }
 
 if (!Array.prototype.forEach) {
 	Array.prototype.forEach = function(fn, o) {
 		for (var item,index = 0; ( item = this[index] ); index++) {
 			if (o)
 				fn.call(o, item);
 			else
 				fn(item);
 		}
 	}
 }
 
 var testArray = [ 'One','Two','Three','Four'];
 
 // indexOf test
 alert('Index of "Two" is: ' + testArray.indexOf('Two'));
 
 // forEach test
 testArray.forEach(alert);
 
 </script>

Many of the others are equally simple to do.

[dek]

Second Useful Thing

I was reading the onLoad debate above, and thought I'd contribute my own approach. This is based around the fact that with many complex JS-using sites, there's sometimes no predicting how and when you many need to add a new onLoad function. So I do something like the following:

(and yes, I'm using the Array extensions seen above)

 <script type="text/javascript">
 
 var gOnload = [ ];
 function addOnload(fn)
 
 {
    gOnload.push(fn);
 }
 
 window.onload = function() {
    gOnload.forEach(function(fn) { fn(); });
 }
 
 function test1() {	alert('one'); }
 function test2() {	alert('two'); }
 
 addOnload(test1);
 addOnload(test2);
 </script>

I can just keep adding functions to my onLoad list to my heart's content, never worrying about name clashes and the like. It's certainly not the only way, and may or may not be the best, but it's simple and easy, both of which appeal to me.

[Kravvitz]

I don't know if any of yo have already encountered difficulties in retrieving count of childNodes.
It appears that IE ans Moz do not return same count as Moz FFX finds empty text nodes where you normaly should not find them ...

here is the script a friend gave me that I use to clean undesired nodes and retrieve correct node count ...

function go(c){
if(c){ 
        if(c.nodeType!=1 && !c.data.replace(/\s/g,'')){
            c.parentNode.removeChild(c)
            }
        }
}
... 

For some reason the forum system was removing the backslash from the regexp. There should be a backslash before the 's'. It doesn't seem to be a problem if you use [ code ] instead of [ php ].

I would like to point out that if you had something like the following, then that function would remove it even though it shouldn't.

...<p>go<span>...

In most cases you would put a space after 'go', so it wouldn't be a problem.

To avoid the potential problem, you could use this regexp

/^\s+$/g

instead of

/\s/g

[loic_sephiroth]

I'm not in such a position as to give out advices (being so new to serious Javascript [that is, beyond the simple rollover effect]), but i think this one hasn't been posted, so here it comes:

When creating classes, it's better to define the methods as prototypes methods instead of defining inner functions inside the constructor function:
Usual way:

function ClassName()
{
    this.variable1 = 0;
    this.variable2 = 0;

    this.method1 = function(param1,param2)
    {
         alert("You passed the following parameters: " + param1 + " " + param2);
    }
} 

Better way:

function ClassName()
{
    this.attribute1 = 0;
    this.attribute2 = 0;
}

ClassName.prototype.method1 = function(param1,param2)
{
    alert("You passed the following parameters: " + param1 + " " + param2);
} 

You might think: ¿What's the difference and why should it matters?
The difference lies in that when you start instanciating ClassName objects, the methods of the class will be created each time (remember you're creating a function object

function ClassName()
{
    this.variable1 = 0;
    this.variable2 = 0;

    this.method1 = function(param1,param2)
    {
         alert("You passed the following parameters: " + param1 + " " + param2);
    }
} 

each time you call the constructor with the ¨usual way" of defining classes, whereas with the "better way" of defining classes, you're creating the method of the class only one time (when loading your script into the page, as a global statement), thus saving precious memory (most notably if you create hundreds of objects from the same class).

[7stud]

Don't put onload events in the <body> tag.

Doing that prevents you from using javascript to add another function to the onload event. If there's an onload event in the <body> tag, and you try to add a new function to the onload event, e.g.:

window.onload = newFunc;
</script>
</head>

then when the body tag is subsequently "encountered by the browser", or parsed, its onload function will overwrite the window.onload function. Here is an example:

<html>
<head><title></title>
<script type="text/javascript" language="javascript">
<!-- Hide from browsers without javascript

window.onload = newFunc;

function newFunc()
{
	alert("New function.");
}

function existingFunc()
{
	alert("Existing function.");
}

// End hiding -->
</script>
</head>
<body onload="existingFunc()">

<div id="d" class="">hello world</div>

</body>
</html>

In addition, putting an onload event in the body tag serves to intermingle javascript and html instead of keeping the two separate.

Do this instead:

//Existing function--possibly in an external js file:
//////////////////////////////////////
window.onload = existingFunc;

function existingFunc()
{
	alert("Existing function.");
}
///////////////////////////////////////


//Adding a new function to onload, which
//is only possible because of the superior way the existing 
//function was added to onload(i.e. not in the <body> tag):
function newFunc()
{
	alert("New Function");
}

var existingFuncs = window.onload;
window.onload = function()
{
	if(existingFuncs) existingFuncs();
	newFunc();
};

credit: Simon Willison, ppk, et al. See here:
http://simon.incutio.com/archive/200...6/addLoadEvent

[vegeta01]

Is there a way to make a pointer to a variable?

With the advice of ultimater to use window[] over eval() I was able to make pointers to global variables or window properties.

// custom pointer can be made by using window[] to set global variables or window properties
 
window.status = "initializing";
 
var variable = "original";
var variablePointer = "variable";
var windowStatusPointer = "status";
 
alert("After declaring, 'variable' is '" + variable + "' and the statusbar reads '" + window.status + "'.");
 
window[variablePointer] = "new";
window[windowStatusPointer] = "changed values";
 
alert("After changing values through custom made pointers, 'variable' is now '" + variable + "' and the statusbar sais '" + window.status + "'.");

but when trying to set child element properties, this way doesn't work

var windowDocumentBgColorPointer = "document.bgColor";
window[windowDocumentBgColorPointer] = "green";

Is this possible in any other way?

I want this for setting a global variable of a system fromout a plugin. Only problem is that the plugin doesn't know the variable's name so I made it configurable in the config.js file. I though to let the user specify the name of the variable and as such be able to assign a new value to this variable...