JavaScript | Kevin Chisholm - Blog

May202013 by dcmNo Comments

Validating JavaScript Function Arguments

Gracefully handling corner cases is the key to writing more robust, error-free JavaScript.

If you work with JavaScript for a living, you write functions. There is just no way around this. So, if you write functions, then arguments are a part of your life. Now, if you are the only one who uses the JavaScript code you write, then life is pretty grand. But if you are writing code that will be consumed by others, then gracefully handling corner cases and errors becomes important; very important.

So, every time I write a function, I assume that someone else will call it. Even if I know no one will, I assume that someday, someway, someone will. Even if it never happens, I feel its a good habit to get into: write code that fails gracefully.

There are a zillion paths down which this conversation can go, but let’s focus on function arguments. When your function absolutely depends on an argument, and that this argument be of a certain type, and that it not be empty, or otherwise useless, you might have a recipe for disaster, if your hungry little function does not get what it needs.

Example # 1A

function someFunc(arg){
	if (arg){
		//proceed with whatever we need to do
	};
};

function someFunc(arg){

if (arg){

//proceed with whatever we need to do

};

Example # 1B

function someFunc(arg){
	if (arg){
		//let’s pretend there is
		//a whole lot of code here
		//20 or 30 lines of code
		//that’s a lot of code to have wrapped
		//inside of an if() block
	};
};

function someFunc(arg){

if (arg){

//let’s pretend there is

//a whole lot of code here

//20 or 30 lines of code

//that’s a lot of code to have wrapped

//inside of an if() block

};

In Example # 1A, we use an IF () block to make sure that the “arg” argument was passed-in before we attempt to do anything with it.

Good enough, right?

Not so fast…

Even though we have taken care to make sure we got the “arg” argument, what if our implementation code is a bit lengthy? Well, in Example # 1B we see how silly it is for all that implementation code to be wrapped in an IF () block. This kind of pattern breeds code that is annoying to maintain.

Example # 2

function someFunc(arg){
	if ( !arg ){ return };

	//now we can have lots and lots and lots
	//of code here
	//and it’s not wrapped up inside of that
	//silly if() block
};

function someFunc(arg){

if ( !arg ){ return };

//now we can have lots and lots and lots

//of code here

//and it’s not wrapped up inside of that

//silly if() block

};

Ahhhhh, now that’s better!

So, as you can see in Example # 2, we simply say: “hey, if arg does not exist, then return.” This was accomplished using the JavaScript logical NOT operator. So, this means that if the argument “arg” does not exist, the function ends right there and none of the implementation code that follows is ever executed.

But…..

What if we need to be 100% sure that the argument “arg” is what we need it to be? What if it’s not enough to simply know that “arg” exists? What if we need to know that “arg” is an array and it has at least one element?

So many questions, so many darned questions.

Example # 3

function someFunc(someArray){
	if ( !someArray || !someArray instanceof Array || !someArray.length ){ return };

	//now we can safely assume that
	//we did get an array as an argument
	//and it’s really an array with at least one element
	//and we can do awesome stuff with that array
};

function someFunc(someArray){

if ( !someArray || !someArray instanceof Array || !someArray.length ){ return };

//now we can safely assume that

//we did get an array as an argument

//and it’s really an array with at least one element

//and we can do awesome stuff with that array

};

Ahhhhh… that’s even better! In Example # 3 we’ve once again used the JavaScript logical NOT operator to say the following: “hey, if the argument someArray was not passed, OR if it is NOT an array, OR if it does NOT have at least one element, return.” This way, we can check for all the details we need in one neat little line and avoid a series of messy nested IF () blocks. We do our test, we feel good if none of the expressions evaluated to false, and then we proceed with confidence.

Summary

In this article we discussed function argument validation. We learned how to avoid wrapping our code inside of a large IF() block and validate the presence of the argument we need in one line. We also discussed how to test for the type of our argument, and the fact that it contains the minimum amount of data.

Helpful Links for the JavaScript Logical NOT Operator

https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Operators/Logical_Operators

http://msdn.microsoft.com/en-us/library/ie/zz722703(v=vs.94).aspx

May82013 by dcmNo Comments

Replicating a “mailto:” href When You Need to Return false From an Anchor Tag Click

JavaScript

You have an anchor tag, the href is a “mailto”, but what if you can’t have the hyper link follow?

Problem:

You need to have a “mailto:” click event, but you have to (for whatever reason) return false or otherwise prevent the actual click event’s default behavior.

Short Answer: On that element’s click event: window.location = “mailto:?subject=XXX…”;

Long Answer (with long story prepended) :

I recently added some social networking buttons to a client’s mobile site, one of which was an old-school “mailto:” anchor tag. No big deal, right?

Well… sort of.

I was testing the deployment in their DEV environment and everything was peachy. And then all of a sudden, nothing worked. Needless to say, I was banging my head against my cubicle for about 20 minutes. I hadn’t made any changes, but suddenly nothing worked. When I calmed down and inspected the live DOM, I could see that my nice long “mailto:?subject=BLAH BLAH BLAH…” href value was very much in-tact on page load, but when I clicked the anchor tag, everything after the “mailto:” disappeared. The result was a new window with simply “mailto:” in the address bar. I tried this over and over (and over). Same thing. HREF valule is fine on page load, but on click, the query string is stripped out.

WTF?

Another 20 minutes of cubicle head-banging, and then I realized that someone had “upgraded” the Omniture library that the page was pulling in. I won’t bore you with the details, but in short, any anchor tag in the page was checked on a click event, and if it had a query string, the query string was removed.

Ugggghhhhh….

I wasted a good half hour trying to get around this, but no matter what I did, that query string got stripped off. Then I wasted another 20 minutes with a plan to create a new anchor element on every click, give it the same “mailto:?subject=BLAH BLAH BLAH…” href value, never append it to the DOM, and just trigger its click event when the original element was clicked.

Dumb Idea.

After a little poking around, I found this little gem:

For that problem elements click event, just do the following:

window.location = "mailto:?subject=BLAH BLAH BLAH...";

1	window.location = "mailto:?subject=BLAH BLAH BLAH...";

Nice.

May12013 by dcmNo Comments

Omniture Calls Firing Twice When Returning False from Click Event

JavaScript

Sometimes “return false” is not enough; you need to prevent the event from bubbling up the DOM

Problem:

While implementing new Omniture calls on a client’s mobile site today, I noticed that two Omniture calls were being fired each time the new social media buttons I had added where clicked. These buttons only fired the Omniture call once, but each time one was clicked, two Ominiture calls were firing. I know this could not be the right behavior. The previous developer had implemented zepto.js, so I wanted to be sure it was not an anomaly of zepto that was causing the problem.

Short Answer:

Instead of ending each click handler with “return false”, I had to do end it with:

event.preventDefault();
event.stopPropagation();

1 2	event.preventDefault(); event.stopPropagation();

Long Answer:

I noticed that when two Omniture calls were fired, they were not the same. One was the one I intended to call, and it was working perfectly. The other was more generic, and did not seem to understand what exatly was clicked. This led me to believe that there was a more generic event handler up the DOM somewhere, that was binding to any click, and firing off some general parameterss.

Yuck!

It turns out that someone had updated the Omniture library that was used, and they had bound a generic Omniture call to the anchor tag click event. Even though my click event returned false, the event bubbled up to wherever that generic event binding was. I found this StackOverflow post, and the answer provided was dead-on:

http://stackoverflow.com/questions/6207956/zepto-js-doesnt-return-false

So my click handler went from this:

$('#someElement').click(function(event){
	//fire off Omniture Call
	omnitureFunction("some-value");

	return false;
});

$('#someElement').click(function(event){

//fire off Omniture Call

omnitureFunction("some-value");

return false;

});

…to this:

$('#someElement').click(function(event){
	event.preventDefault();
	event.stopPropagation();

	//fire off Omniture Call
	omnitureFunction("some-value");
});

$('#someElement').click(function(event){

event.preventDefault();

event.stopPropagation();

//fire off Omniture Call

omnitureFunction("some-value");

});

Summary:

I just needed to kill the event bubbling, and prevent the default behaviour, and everything worked just fine.

Apr222013 by dcmNo Comments

Getting Started with JavaScript Unit Testing and jQuery QUnit

JavaScript

Decent programmers tests their code before deploying it. In JavaScript development, this usually means viewing the web page that your code interacts with, and clicking one or more elements in the page to ensure that the desired result is achieved

When your code base starts to grow and become more complex, testing can become tedious. Even worse, manual testing can become unreliable, because you not only have to test your new code, you have to regression test as well, so that you can be sure your new code did not break any old code.

Yuck!

If we’ve learned nothing else at this point in technology, we have at least discovered, first hand, that humans are really bad at tedious, repetitive tasks. Fortunately, computers love this kind of work.

Enter Unit Testing

The key to writing testable code is to produce small modules of functionality that always return a predictable result.

Unit testing provides a methodical way to ensure that your code always performs as expected, and provides red flags for the nanosecond that this condition changes. The key to writing testable code is to produce small modules of functionality that always return a predictable result.

jQuery QUnit

jQuery QUnit is a test framework created by the same impressive folks who bring you jQuery. It is lightweight, easy to understand, and easy to use. It has a number of simple methods that allow you to test your code. What is really impressive about jQuery QUnit is that it is designed to run in a (very) simple web page so that your test results are not only visual, but easy to understand.

Before we dive into the code, it might help to take a look at the full working example:

http://examples.kevinchisholm.com/javascript/unit-testing/qunit/part-i/

Let’s review the files involved in the full working example.

qunit.js

This is the QUnit JavaScript library.

qunit.css

This is the CSS that our test page will need.

tests.js

This is the JavaScript file that contains our unit tests.

index.html

This is the web page that you see in the full working example. It allows us to view the test results.

Here is the full source code for index.html:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Getting Started with JavaScript Unit Testing and jQuery QUnit Part I || blog.kevinchisholm.com</title>
  <link rel="stylesheet" href="qunit.css">
</head>
<body>
  <div id="qunit"></div>
  <div id="qunit-fixture"></div>
  <script src="qunit.js"></script>
  <script src="tests.js"></script>
</body>
</html>

<!DOCTYPE html>

<html>

<head>

<title>Getting Started with JavaScript Unit Testing and jQuery QUnit Part I || blog.kevinchisholm.com</title>

</head>

<body>

</body>

</html>

Example # 1 A

function badFunction(){
	return false;
};

test( "badFunction", function() {
	ok( badFunction(), "badFunction failed." );
});

function badFunction(){

return false;

};

test( "badFunction", function() {

ok( badFunction(), "badFunction failed." );

});

In Example # 1A, we test a function named “badFunction”. I gave it that name because when we test for a positive result, it fails. The syntax is simple:

We execute the test() method
The first argument to the test() method is simply a label for the test that makes it easier to identify in the test results page (index.html).
The second argument to the test() method is an anonymous function. We craft our test(s) inside of this function.
Inside of the anonymous function, we execute the ok() method, a boolean assertion. This test passes if the first argument is “truthy”.
The first argument to the ok() method is the execution of badFunction(). Since badFunction returns false, the test fails.
The second argument to the ok() method is the test result message.

Example # 1 B

function goodFunction(){
	return true;
};

test( "goodFunction", function() {
	ok( goodFunction(), "goodFunction succeeded." );
});

function goodFunction(){

return true;

};

test( "goodFunction", function() {

ok( goodFunction(), "goodFunction succeeded." );

});

In Example # 1B, The approach taken is identical to Example # 1A, with one exception: we test goodFunction(), which passes the ok() test because its goodFunction() returns true.

Example # 2 A

function makeArray1(){
	return [];
};

test( "makeArray1", function() {
	ok( (makeArray1() instanceof Array), "makeArray1 is an array." );
	ok( (makeArray1().length), "makeArray1 is empty." );
});

function makeArray1(){

return [];

};

test( "makeArray1", function() {

ok( (makeArray1() instanceof Array), "makeArray1 is an array." );

ok( (makeArray1().length), "makeArray1 is empty." );

});

In example # 2A, we test the function makeArray1(). That function returns an empty array literal. Our unit test consists of two calls to the ok() method. The first call simply checks to see that makeArray() returns a true array. It does, so that test passes. The second call to ok() checks to make sure there is at least one element in the array. The array is empty, so that test fails.

Example # 2 B

function makeArray2(){
	return ['monday','tuesday','wednesday'];
};

test( "makeArray2", function() {
	ok( (makeArray2() instanceof Array), "makeArray2 is an array." );
	ok( (makeArray2().length), "makeArray2 has at least one element" );
});

function makeArray2(){

return ['monday','tuesday','wednesday'];

};

test( "makeArray2", function() {

ok( (makeArray2() instanceof Array), "makeArray2 is an array." );

ok( (makeArray2().length), "makeArray2 has at least one element" );

});

In Example # 2B, we test makeArray2(). Since that function returns an array with three elements, both calls to the ok() method pass.

Example # 3 A

//this closure allows lessThanFive to keep track
//of how many times it has been executed
var lessThanFive = (function(){
	var i = 0;

	//this function will return false
	//if it has been executed more than four times
	return function(reset){
		//allows us to run multiple unit tests on lessThanFive
		if(reset === "reset"){i = 0;return};

		i++;
		return (i &lt; 5) ? true : false;
	};
})();

test( "lessThanFive", function() {
	//this teset will execute lessThanFive 6 times
	//so the last two tests should fail
	ok( lessThanFive(),"This is the first test, it should succeed" );
	ok( lessThanFive(),"This is the second test, it should succeed" );
	ok( lessThanFive(),"This is the third test, it should succeed" );
	ok( lessThanFive(),"This is the fourth test, it should succeed" );
	ok( lessThanFive(),"This is the fifth test, it should fail" );
	ok( lessThanFive(),"This is the sixth test, it should fail" );
});

//this closure allows lessThanFive to keep track

//of how many times it has been executed

var lessThanFive = (function(){

var i = 0;

//this function will return false

//if it has been executed more than four times

return function(reset){

//allows us to run multiple unit tests on lessThanFive

if(reset === "reset"){i = 0;return};

i++;

return (i < 5) ? true : false;

};

})();

test( "lessThanFive", function() {

//this teset will execute lessThanFive 6 times

//so the last two tests should fail

ok( lessThanFive(),"This is the first test, it should succeed" );

ok( lessThanFive(),"This is the second test, it should succeed" );

ok( lessThanFive(),"This is the third test, it should succeed" );

ok( lessThanFive(),"This is the fourth test, it should succeed" );

ok( lessThanFive(),"This is the fifth test, it should fail" );

ok( lessThanFive(),"This is the sixth test, it should fail" );

});

In Example # 3A, we test a function named lessThanFive(). It is actually a closure that returns a function. The closure allows us to have a private scope which will keep track of how many times the function has been executed. Since this function was designed only to be executed less than five times, on the fifth execution, and for every execution that follows, the function returns false. The first four times, it will return true. You’ll see in the full working example that our unit test passes four times and then fails twice. This is because the first four times that lessThanFive() runs, it returns true. The fifth and sixth times that it is run, it returns false.

Example # 3 B

test( "lessThanFive", function() {
	//reset lessThanFive so that we can test it again cleanly
	lessThanFive("reset")

	//this teset will execute lessThanFive 6 times
	//so the last two tests should fail
	for (var i = 1 ;i &lt; 7; i++){
		ok( lessThanFive() );
	};
});

test( "lessThanFive", function() {

//reset lessThanFive so that we can test it again cleanly

lessThanFive("reset")

//this teset will execute lessThanFive 6 times

//so the last two tests should fail

for (var i = 1 ;i < 7; i++){

ok( lessThanFive() );

};

});

In Example # 3B, we have a slightly more elegant approach. Instead of writing out six calls to the ok() method, we have a FOR/LOOP, which executes six times. On each iteration, it calls the ok() method, which, in turn, executes the lessThanFive() function. The only drawback to this approach is that we do not have a nice customized test message for each iteration of the test.

Once again, here is the full working example:

http://examples.kevinchisholm.com/javascript/unit-testing/qunit/part-i/

Summary

In this article, we took a brief look at how to write JavaScript unit tests using jQuery QUnit. We learned about the files needed, the test() method, and the ok() method. We learned how to check for more than one possible outcome of a test, and that there is more than one way to write the same test.

In the next article, we’ll take a closer look at the other features of QUnit.

Helpful Links for jQuery QUnit

http://qunitjs.com/

https://github.com/jquery/qunit

http://en.wikipedia.org/wiki/QUnit

http://net.tutsplus.com/tutorials/javascript-ajax/how-to-test-your-javascript-code-with-qunit/

http://msdn.microsoft.com/en-us/magazine/gg749824.aspx

Apr152013 by dcmNo Comments

Getting Started with Require.js – Part III

Asynchronous Module Definition

Learn How to Build a Social Media Plugin, Using Require.js and the Asynchronous Module Definition (AMD) Pattern

In Getting Started with Require.js – Part II, we took a closer look at the way the Require.js JavaScript library works. We created modules that depended on other modules, and learned how the return value of a module can be used to expose functionality to the outside world.

In Part III of this series, we will use Require.JS to build a social media plugin. We’ll leverage the concepts and techniques used in Part II to create reusable front-end code that has real-world usefulness. You’ll be able to take the code from the completed working example, copy it, tweak it, and use it for your own web page.

Since we have discussed a great deal of Require.js implementation details, I’ll keep the discussion on a high level here. You can drill down into the code for a completed working example and review all of the nitty-gritty details if you like. The focus of this article is to provide an example that demonstrates how Require.js can be put to use in a real-world context.

Before we dive into the code, it might help to see the full working example for this article:

http://examples.kevinchisholm.com/javascript/requirejs/part-iii/

NOTE: For most of the examples, I will provide a link to the actual module file. I don’t think there is much point in repeating that same code here in the article. You can simply view it in your browser.

Example # 1

<!DOCTYPE html> 
<html> 
    <head> 
        <meta charset="utf-8"> 
    	<title>Getting Started with Require.js Part III | blog.kevinchisholm.com</title>
		<style>
			/* CSS removed for brevity */
		</style>
    </head> 
    <body> 
		<div class="container">
			<h1>Ski Like a Pro!</h1>
			<img id="pinterestImage" src="skier.jpg" class="floatLeft"/>
			<p>
			Lorem ipsum dolor sit amet...<!-- content shortened for brevity -->
			</p>
		</div>
		<script src="require.js"></script>
		<script>
			require(["social-menu"], function(menu) {
				menu.init(['facebook','twitter','pinterest','googleplus','email']);
			});
		</script>
    </body> 
</html>

<!DOCTYPE html>

<html>

<head>

<title>Getting Started with Require.js Part III | blog.kevinchisholm.com</title>

<style>

/* CSS removed for brevity */

</style>

</head>

<body>

<p>

Lorem ipsum dolor sit amet...

</p>

</div>

require(["social-menu"], function(menu) {

menu.init(['facebook','twitter','pinterest','googleplus','email']);

});

</script>

</body>

</html>

In Example # 1, we have the markup for our web page. You’ll notice that I have removed the CSS in the head and most of the content in the body. This is only to keep the code example short. Otherwise, it is identical to the working example.

In this example, after including require.js, we use the require() function. The first argument is social-menu.js. This is the only dependency for the JavaScript code in the page. In the anonymous function that is the second argument to the require() function, we reference social-menu.js as “menu”. We then call the init() method of the variable “menu”, which is an object. We know this because as we will see shortly, the return value of the module social-menu.js is an object with a method named init(). We pass an array to meunu.init(). This array contains strings that identify the social media icons we want to include in our plugin. Next, we will take a closer look at the module: social-menu.js.

social-menu.js

http://examples.kevinchisholm.com/javascript/requirejs/part-iii/social-menu.js

This module has one dependency: social-markup.js. Inside of our module, social-markup.js is referred to as “socialMarkup”. Inside of the init() method, we instantiate the socialMarkup() constructor. We then use the getLinks() method of the socialMarkup() object. When past the appropriate array, the getLinks() method will return a DOM object that only needs be appended to the DOM, which we do on the very next line.

The beauty of this Asynchronous Module Definition (AMD) pattern is that as we step through the code, the implementation details of each dependency is abstracted away by the module that we depend on. We simply “need” that module, Require.js loads it asynchronously for us, and then we use it. This makes it easier to follow and understand code that you did not write. As you follow the dependency chain, digging deeper into the code, you can see more implementation details (if you choose to do so).

social-markup.js

http://examples.kevinchisholm.com/javascript/requirejs/part-iii/social-markup.js

If you look towards the bottom of this module, you’ll see that it returns a function. That function is meant to be used as a constructor. The line “this.getLinks = function(arr){…” indicates that when instantiated, the resulting object will have a method named “getLinks()”. The private variables “makeAnchor”, “addTitle”, “addClickHandler” and “makeImage” are all helper functions that handle the implementation work needed to create the DOM object that this module returns. Lastly, notice that this module’s sole dependency is “social-icons.js”, which contains the data we need to construct the actual social media icons and event handlers.

social-icons.js

http://examples.kevinchisholm.com/javascript/requirejs/part-iii/social-icons.js

This module has no dependencies. It returns an object whose properties are all objects containing data for each social media type. Each of those individually named objects has the following properties:

Image: A data URI that provides an image, so that we don’t need to reference external resources.
Title: What users see when they hover over the icon.
Handler: A function that will be the click-event handler for that social media icon.

Now that we have taken a high-level view of the code, re-visit the full working example for this article:

http://examples.kevinchisholm.com/javascript/requirejs/part-iii/

In the full working example, you’ll notice that each social media icon allows you to share the page (e.g., “tweet” “pin”, “facebook post”, etc…). These actions are determined by the click event handler that we specified for each icon in the module: social-icons.js. The images for icons themselves are provided by the data URL for each social media type (once again in “social-icons.js”), as well as the title that you see when you hover the mouse over that icon.

Summary

In this article, we put to use, in a real-world context, the concepts and techniques that we learned in Part I and Part II. We created a social media plugin that actually works. I hope you have enjoyed this series. Require.js is a powerful and helpful JavaScript library that helps you to create loosely-coupled, modular, reusable code.

Helpful Links for Require.js and Asynchronous Module Definition (AMD)

Require.js

http://requirejs.org/

http://www.webdesignerdepot.com/2013/02/optimize-your-javascript-with-requirejs/

Asynchronous Module Definition (AMD)

http://stackoverflow.com/questions/12455537/asynchronous-module-definition-difference-between-beta-verb-and-requirebeta

http://www.sitepen.com/blog/2012/06/25/amd-the-definitive-source/

http://blog.davidpadbury.com/2011/08/21/javascript-modules/

Apr102013 by dcm4 Comments

Using the jQuery Promise Interface to Avoid the AJAX Pyramid of Doom

jQuery

Nested success callbacks are messy business. The jQuery Promise interface provides a simple and elegant solution.

So, you have to make an AJAX call, and then do something with the return data. No problem, right? Right. What if you have to make two AJAX calls, and then do something with the return data for each one? No problem, right? Right. What if the second AJAX call depends on the success of the first AJAX call?

“…um, well…. then, well… wait a minute… ok, I’ve got it:

I’ll make the first AJAX call…and then inside the success callback function, cache the data somewhere… um… in a global variable for now I guess… yeah, no one will notice. OK, and then inside of that success callback, we’ll nest another AJAX call, and then inside of the second AJAX calls’ success callback, we’ll get our first chunk of data from the global variable, and then, and then… um…and then…”

…yikes!

Obviously, the preceding diatribe was a little over the top, but c’mon…. haven’t you at least once stood at the edge of that cliff and looked over? Fortunately, jQuery features a way out of this mess that is safe, reliable and packed with vitamins.

The jqXHR object

Since version 1.5.1, jqXHR objects returned by $.ajax() implement a “Promise” interface. In short, this means that a number of methods that are exposed provide powerful abstraction for handling multiple asynchronous tasks.

I think it is important to note that the subject of the jQuery Deferred and Promise Objects is deep. It is not an easy topic to jump into and a detailed discussion of this is outside of the scope of this article. What I hope to accomplish here is to provide a simple and fast introduction to the topic, by using a real-world problem / solution.

There are certainly multiple scenarios in which the jQuery Deferred and Promise objects can be useful. I have chosen to use AJAX calls for this, since it is an example of asynchronous behavior that I think most folks can relate to. In order to dramatize the effect of an asynchronous AJAX call, I am using a PHP file that can return a delayed response. Here is the code for the server page:

<?php
	if( isset($_GET["sleep"]) ){ sleep ( $_GET["sleep"] ); }
	header("Status: 200");
	date_default_timezone_set('EST');
	echo "<p>Hello, this is the response from the server.<br/>";
	echo "This response was sent on " . date('l F jS Y') . " at " . date('h:i:s A') . " <i>(new york city time).<i></p>";
?>

<?php

if( isset($_GET["sleep"]) ){ sleep ( $_GET["sleep"] ); }

header("Status: 200");

date_default_timezone_set('EST');

echo "<p>Hello, this is the response from the server.<br/>";

echo "This response was sent on " . date('l F jS Y') . " at " . date('h:i:s A') . " <i>(new york city time).<i></p>";

OK, now some AJAX.

(Note: I highly recommend that you open up the “network” panel in Firebug or WebKit developer tools so that you can see these AJAX calls in action when viewing the working examples… especially AJAX call # 1, which will take 5 seconds to complete)

Example # 1

var success = function(d){
    $('#target').append(d);
};

$().ready(function(){

    $('#clear').click(function(){
        $('#target').html('');
    });

    $('#request1').click(function(){
        $.get('response.php?sleep=5',success);
    });

    $('#request2').click(function(){
        $.get('response.php',success);
    });
});

var success = function(d){

$('#target').append(d);

};

$().ready(function(){

$('#clear').click(function(){

$('#target').html('');

});

$('#request1').click(function(){

$.get('response.php?sleep=5',success);

});

$('#request2').click(function(){

$.get('response.php',success);

});

In Example # 1 we have a fairly straightforward setup: Two buttons, each resulting in an AJAX call. Notice that the 1st AJAX call takes 5 seconds to complete. Instead of providing an inline anonymous function for the success callback of each AJAX call, we have a generic handler named “success”.

Here is a link to the working code for Example # 1: http://examples.kevinchisholm.com/jquery/promise/promise-and-ajax-beginner/example-1.html

But what if we want AJAX call # 2 to depend on AJAX call # 1? That is, we don’t want AJAX call # 2 to even be possible until AJAX call # 1 has completed successfully.

Example # 2

$("#request1").click(function() {
  $.get("response.php", function(d1) {
    $("#request2").click(function() {
      $.get("response.php",function(d2) {

        //...this is not going anyplace good

      });
    });
  });
});

$("#request1").click(function() {

$.get("response.php", function(d1) {

$("#request2").click(function() {

$.get("response.php",function(d2) {

//...this is not going anyplace good

});

In Example # 2, we have a pattern that is known as the “Pyramid of Doom”. This might work for the short term, but it is impractical, not at all flexible, and just plain messy. What if there was a third button, and a fourth button… I think you see what I’m getting at here.

Example # 3

var aj1 = null, aj2 = null;

$('#request1').click(function(){
    aj1 = $.get('response.php?sleep=5');
});

$('#request2').click(function(){
    aj2 = $.get('response.php');

    $.when(aj1,aj2).done(function(a,b){
        success(a[0]);
        success(b[0]);
    });
});

var aj1 = null, aj2 = null;

$('#request1').click(function(){

aj1 = $.get('response.php?sleep=5');

});

$('#request2').click(function(){

aj2 = $.get('response.php');

$.when(aj1,aj2).done(function(a,b){

success(a[0]);

success(b[0]);

});

Ahhh… that’s much better!

In Example # 3, we have taken advantage of the Promise interface that is exposed as part of the jqXHR object. If you are wondering what the jqXHR object is, it is the return value of any $.ajax() call. So, while you can simply do this: $.ajax(URL,CALLBACK), the call itself returns a value. That return value is the jqXHR object, which is a superset of the XMLHTTPRequest object.

The return value of $.ajax() is the jqXHR object, which is a superset of the XMLHTTPRequest object, and packed with some powerful features.

We don’t have to dive too deeply into the good ol’ XMLHTTPRequest object (although it is important to know what it is and the critical role that it plays in AJAX). But the key point here is that the jqXHR object wraps the XMLHTTPRequest object, providing some useful features. One of those features is the “Promise” interface.

“….ok, ok Kevin, you’re givin’ me a migraine… where are you going with all this?”

Hang in there; we are at the 99 yard line here. What this all means is that instead of just making an AJAX call, you can assign that AJAX call to a variable. Since the $.ajax() method returns the jqXHR object, your variable is now a Swiss Army knife of AJAXian goodness. You can then implement methods of your object (i.e. your variable). Two of those methods are: .when() and .done();

So, in Example # 3, when we fired the first AJAX call, we assigned its return value to the variable “aj1”. Notice that we did NOT make a success handler call. We simply make the AJAX call, and that call’s return value is held by the variable “aj1”. Then when the user clicks the second button. we set the return value of the second AJAX call to the variable: “aj2”. Now we have two variables and each is a jqXHR object. These are powerful little objects!

The line where the fun really starts is: $.when(aj1,aj2).done()

Notice how the .done() function takes a callback. The callback is fired when the two arguments passed to the .when() method are resolved. And guess what those two arguments are… our two little jqXHR objects!

So, the .done() method knows how to get ahold of the data returned by each of those calls. Now we simply call our generic success handler, passing in the return data of each AJAX call (i.e. each jqXHR object). You may be wondering why I pass in the values “a[0]” and “b[0]”. This is because “a” and “b” are jqXHR objects. It just so happens that the first property of these objects (i.e. the property with the index of 0) happens to be the “responseText” property of that object (i.e. the text sent back from the server).

Phew!

I know that was a lot. But there is much to shout about when it comes to the jQuery Promise interface. As I mentioned, it is a big topic and not easily summarized. But my hope is that these examples will have put a little context around the subject, and will help you to dive in and get started.

Below is the source code for this article’s full working example:

Example # 4:

<!DOCTYPE html> 
<html> 
    <head> 
        <meta charset="utf-8"> 
        <title>jQuery When - Example # 2</title>
        <script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
    </head>
    <style>
        /* CSS removed forbrevity */
    </style>
    <body>
        <button id="request1">Send 1st AJAX Request</button>
        <button id="request2">Send 2nd AJAX Request</button>
        <button id="clear">Clear Page</button>
		<div id="target"></div>
        <script>
        //our success handler for all AJAX calls
        var success = function(d){
            //d is the text returned from the server
            $('#target').append(d);
        },
        //we'll need these later
        aj1 = null,
        aj2 = null;

        $().ready(function(){
            //re-sets the page
            $('#clear').click(function(){$('#target').html('')});

            //when the user kicks off the first ajax call...
            $('#request1').click(function(){
                //set the ajax loader image
                $('#target').html('<img class="loader" src="ajax-loader.gif" />');

                //setup the deferred object that represents this AJAX call
                //note the query string in the URL: the server will take 5 seconds to respond
                aj1 = $.get('response.php?sleep=5',function(){
                    //just a quick anonymous success handler to keep the user informed
                    $('#target').html('<p>ok, the 1st AJAX call is done. Now make the 2nd Ajax Call</p>');
                });
            });

            //when the user kicks off the second ajax call...
            $('#request2').click(function(){
                //if the first ajax call has not run, then warn the user and exit
                if(!aj1){
                    $('#target').html('<p>Please make the 1st AJAX call <u>before</u> you make the 2nd AJAX call.</p>');
                    return;
                };

                //setup the deferred object that represents this AJAX call
                aj2 = $.get('response.php');

                //setup the actions to be taken when BOTH AJAX calls have successfully completed
                $.when(aj1,aj2).done(function(a,b){
                    $('#target').html('');

                    //inside of this function, a & b represent
                    //the response objects for each AJAX call respectively

                    //call our generic success handler and pass it the return text, once for each AJAX call
                    success(a[0]);
                    success(b[0]);
                });
            });
        });
        </script>
    </body> 
</html>

<!DOCTYPE html>

<html>

<head>

<title>jQuery When - Example # 2</title>

</head>

<style>

/* CSS removed forbrevity */

</style>

<body>

<button id="request1">Send 1st AJAX Request</button>

<button id="request2">Send 2nd AJAX Request</button>

<button id="clear">Clear Page</button>

//our success handler for all AJAX calls

var success = function(d){

//d is the text returned from the server

$('#target').append(d);

//we'll need these later

aj1 = null,

aj2 = null;

$().ready(function(){

//re-sets the page

$('#clear').click(function(){$('#target').html('')});

//when the user kicks off the first ajax call...

$('#request1').click(function(){

//set the ajax loader image

$('#target').html('<img class="loader" src="ajax-loader.gif" />');

//setup the deferred object that represents this AJAX call

//note the query string in the URL: the server will take 5 seconds to respond

aj1 = $.get('response.php?sleep=5',function(){

//just a quick anonymous success handler to keep the user informed

$('#target').html('<p>ok, the 1st AJAX call is done. Now make the 2nd Ajax Call</p>');

});

//when the user kicks off the second ajax call...

$('#request2').click(function(){

//if the first ajax call has not run, then warn the user and exit

if(!aj1){

$('#target').html('<p>Please make the 1st AJAX call <u>before</u> you make the 2nd AJAX call.</p>');

return;

};

//setup the deferred object that represents this AJAX call

aj2 = $.get('response.php');

//setup the actions to be taken when BOTH AJAX calls have successfully completed

$.when(aj1,aj2).done(function(a,b){

$('#target').html('');

//inside of this function, a & b represent

//the response objects for each AJAX call respectively

//call our generic success handler and pass it the return text, once for each AJAX call

success(a[0]);

success(b[0]);

});

</script>

</body>

</html>

Here is a link to this article’s full working example: http://examples.kevinchisholm.com/jquery/promise/promise-and-ajax-beginner/example-2.html

Summary

In this article we learned about the jQuery Promise interface. We discovered that since version 1.5.1, calls to $.ajax() return a jqXHR object, which implements the Promise interface. We utilized the .when() and .done() methods of this interface to execute callback functions for two asynchronous tasks. This eliminates the need for nested success callback functions.

Helpful Links for the jQuery Deferred, jQuery Promise and jqXHR Objects

Apr82013 by dcmNo Comments

Getting Started with Require.js – Part II

Asynchronous Module Definition

Step beyond the basics, and learn how Require.js modules can return various kind of values, depend on other modules, and keep those dependencies transparent to the outside world

In Getting Started with Require.js Part I, we got to know the Require.js JavaScript library. We learned about the basics of the define() and require() methods, and how they load dependencies asynchronously and then provide access to the return value of each one.

In Part II of this series, we will use Require.JS to build a little application that displays the daily specials for a restaurant. It’s a silly little example, but perfect for taking our discussion of Require.js to the next step.

The focus of this article is to demonstrate how one module can depend on one or more modules, and each of them can have similar dependencies. The beauty of this approach is that when one module depends on another, it has no knowledge of, nor does it care about how many dependencies the module it needs may have. So for example:

index.html -> needs module-A
Module-A -> needs Module-B
Module-B -> needs Module-C and Module-D
Module-D – > needs Module-E

The beauty of this approach is that our web page index.html only cares about module-A. It has no idea that Module-A in turn needs Module-B. And so on. This approach encourages you to write code modules that are reusable, and less tightly coupled.

Before we dive into the code, it might help to see the full working example for this article:

http://examples.kevinchisholm.com/javascript/requirejs/part-ii/

NOTE: for most of the examples, I will provide a link to the actual module file. I don’t think there is much point in repeating that same code here in the article. You can simply view it in your browser.

Example # 1

menuData.js

http://examples.kevinchisholm.com/javascript/requirejs/part-ii/menuData.js

In Example # 1, we see the data that is used for this example. What is nice about the module pattern used here is that whenever this data needs to change, we only have to make that change in this one small file. The rest of the files that depend on this module have no knowledge of that, nor do they care. As long as the data is structured the way they expect, they don’t need to know about any changes to this module.

Example # 2

<!DOCTYPE html>
<html> 
<head> 
    <meta charset="utf-8"> 
    <title>Getting Started with Require.js Part II | blog.kevinchisholm.com</title>

</head> 
<body>
	<hgroup>
		<h1>Getting Started with Require.js Part II</h1>
		<h2><a title="go to blog.kevinchisholm.com" href="http://blog.kevinchisholm.com" target="_blank">blog.kevinchisholm.com</a></h2>
	</hgroup>
	<nav>
		<button id="showWeekDays">Show Week Day Specials</button>
		<button id="showWeekEnd">Show Week End Specials</button>
		<button id="showFullWeek">Show Specials For the Entire Week</button>
	</nav>
	<div id="specials"></div>
	<script src="require.js"></script>

	<script>
		require(["menuMaker","css"], function(menu) {

			//the menu argument is a <ul> element, inject into the DOM
			function specialsHandler(menu){
				if (!menu){return};
				var specials = document.getElementById('specials');
				specials.innerHTML = "";
				specials.appendChild(menu);
			};

			//sorry folks, I don't feel like wasting time with < IE9  : - (
			if(document.addEventListener){

				//get referenes to the buttons
				var showWeekDays = document.getElementById('showWeekDays'),
				showWeekEnd = document.getElementById('showWeekEnd'),
				showFullWeek = document.getElementById('showFullWeek');	

				//event handlers for each specific button
				showWeekDays.addEventListener('click',function(){
					specialsHandler(menu.weekdayMenu);
				},false);

				showWeekEnd.addEventListener('click',function(){
					specialsHandler(menu.weekendMenu);
				},false);

				showFullWeek.addEventListener('click',function(){
					specialsHandler(menu.getFullWeek);
				},false);
			};
		});
	</script>
</body> 
</html>

<!DOCTYPE html>

<html>

<head>

<title>Getting Started with Require.js Part II | blog.kevinchisholm.com</title>

</head>

<body>

<h1>Getting Started with Require.js Part II</h1>

<h2><a title="go to blog.kevinchisholm.com" href="http://blog.kevinchisholm.com" target="_blank">blog.kevinchisholm.com</a></h2>

</hgroup>

<nav>

<button id="showWeekDays">Show Week Day Specials</button>

<button id="showWeekEnd">Show Week End Specials</button>

<button id="showFullWeek">Show Specials For the Entire Week</button>

</nav>

require(["menuMaker","css"], function(menu) {

//the menu argument is a <ul> element, inject into the DOM

function specialsHandler(menu){

if (!menu){return};

var specials = document.getElementById('specials');

specials.innerHTML = "";

specials.appendChild(menu);

};

//sorry folks, I don't feel like wasting time with < IE9 : - (

if(document.addEventListener){

//get referenes to the buttons

var showWeekDays = document.getElementById('showWeekDays'),

showWeekEnd = document.getElementById('showWeekEnd'),

showFullWeek = document.getElementById('showFullWeek');

//event handlers for each specific button

showWeekDays.addEventListener('click',function(){

specialsHandler(menu.weekdayMenu);

},false);

showWeekEnd.addEventListener('click',function(){

specialsHandler(menu.weekendMenu);

},false);

showFullWeek.addEventListener('click',function(){

specialsHandler(menu.getFullWeek);

},false);

};

});

</script>

</body>

</html>

In Example # 2, we have the full source code for our web page. If you look at the require() statement, you’ll see that we have two modules as dependencies: css.js and menuMaker.js. Let’s follow the dependency tree, see what each module does, and then circle back to review the JavaScript in this page that responds to the button clicks. css.js http://examples.kevinchisholm.com/javascript/requirejs/part-ii/css.js This module simply injects a STYLE tag into the DOM. This is the CSS that makes the page look the way it does. Pretty simple stuff. menuMaker.js

http://examples.kevinchisholm.com/javascript/requirejs/part-ii/menuMaker.js

This module returns an object literal. That object has three properties. Each property is a DOM element: an unordered list (UL). None of these DOM elements exist in the page (yet) when they are returned, but they are valid unordered lists, waiting to be injected into the page. This module has two dependencies: weekParser.js and makeList.js. Inside of the anonymous function that wraps our module, they are referred to as: “weekTool” and “makeList.” We could have just as well called them “Sally” and “Sue”. It doesn’t matter. “weekTool” and “makeList.” are the variable names we chose. If you look at the object literal that is returned by menuMaker.js, you’ll see that we use “weekTool” and “makeList.” to create the object’s property values. weekParser.js

http://examples.kevinchisholm.com/javascript/requirejs/part-ii/weekParser.js

This module has the dependencies: ‘menuData’,’getDayType’. menuData is the array that contains our actual menu data. getDayType.js returns a sub-set of the ‘menuData’ array, depending on whether “weekday”, “weekend” is passed-in. getDayType.js

http://examples.kevinchisholm.com/javascript/requirejs/part-ii/getDayType.js

This module takes two arguments: the type of day (i.e. weekday or weekend), and the data array that contains the entire menu. Based on the type that was passed-in, it returns a sub-set of the array that contains only the days of type specified. makeList.js

http://examples.kevinchisholm.com/javascript/requirejs/part-ii/makeList.js

This module is unique amongst the modules we have reviewed so far in that it has no dependencies. It returns a function that takes one argument: an array. That array should contain the day objects that we want to turn into an unordered list. For each element in that array, it creates an LI element, puts the “Day” and “Menu” values into that LI, and then returns an unordered list (UL). Example # 3

if(document.addEventListener){

	//get referenes to the buttons
	var showWeekDays = document.getElementById('showWeekDays'),
	showWeekEnd = document.getElementById('showWeekEnd'),
	showFullWeek = document.getElementById('showFullWeek');	

	//event handlers for each specific button
	showWeekDays.addEventListener('click',function(){
		specialsHandler(menu.weekdayMenu);
	},false);

	showWeekEnd.addEventListener('click',function(){
		specialsHandler(menu.weekendMenu);
	},false);

	showFullWeek.addEventListener('click',function(){
		specialsHandler(menu.getFullWeek);
	},false);
};

if(document.addEventListener){

//get referenes to the buttons

var showWeekDays = document.getElementById('showWeekDays'),

showWeekEnd = document.getElementById('showWeekEnd'),

showFullWeek = document.getElementById('showFullWeek');

//event handlers for each specific button

showWeekDays.addEventListener('click',function(){

specialsHandler(menu.weekdayMenu);

},false);

showWeekEnd.addEventListener('click',function(){

specialsHandler(menu.weekendMenu);

},false);

showFullWeek.addEventListener('click',function(){

specialsHandler(menu.getFullWeek);

},false);

};

In Example # 3, we circle back to our web page. This code does a quick check to make sure that the addEventListener() method is supported, and then gets to work setting up click event handlers for each of the three buttons at top.

Notice that in each case, menu.getFullWeek is the only reference to functionality provided by one of our modules. A simple call to a property of that module’s return value kicks off the dependency chain that we discussed above, but this web page neither knows nor cares about all that. It only knows that it required a file named “menuMaker.js”, it refers to its return value as “menu” and it wants the value of menu.getFullWeek (or menu.weekendMenu, etc…). The menuMaker.js module provides that functionality, and any other modules that it depends on in order to provide that functionality, are only of concern to menuMaker.js.

Summary

In this article, we created a web page that allows the user to view the weekday, weekend or full week specials for a restaurant. We demonstrated how modules can have dependencies on other modules, and that dependency chain can grow and become complex. The key takeaway here is that while this scenario may seem to be a one-way ticket to spaghetti code, it is quite the opposite; by following the Asynchronous Module Definition pattern, each one of our modules provides clear and distinct functionality. A module may depend on other modules, but it neither knows nor cares about the dependency chain that may exist with the modules that it depends on.

There is plenty more to discover with Require.js. But I hope this article has provided a helpful introduction to the library and the benefits of Asynchronous Module Definition patterns, beyond the basics.

Once again, here is the full working example for this article:

http://examples.kevinchisholm.com/javascript/requirejs/part-ii/

Helpful Links for Require.js and Asynchronous Module Definition

Require.js

http://requirejs.org/

http://www.adobe.com/devnet/html5/articles/javascript-architecture-requirejs-dependency-management.html

http://javascriptplayground.com/blog/2012/07/requirejs-amd-tutorial-introduction

Asynchronous Module Definition

http://requirejs.org/docs/whyamd.html

http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition

https://github.com/amdjs/amdjs-api/wiki/AMD

http://www.2ality.com/2011/10/amd.html

Apr32013 by dcmNo Comments

What’s the Difference Between jQuery().each() and jQuery.each() ?

jQuery

jQuery’s two .each() methods are similar in nature, but differ in level of functionality

Some may find it difficult to understand the difference between jQuery.each() and jQuery().each(). Perhaps the easiest way to understand the difference is to start with jQuery().each(). This method can only be used against a jQuery collection. So when you do this: jQuery(‘#someDiv p’).each(), what you are saying is: “for EACH paragraph that is inside of the element with the ID of “someDiv”, I want to do something. That’s it.

The jQuery.each() method is a static method of the jQuery object. This means that it is just a method that’s out there for you to use, and you need to give it a little more info. But there is a bigger payoff with this method: it can be used to iterate over different kinds of things, not just a jQuery collection.

The syntax for the jQuery.each() method is also simple:

jQuery.each(OBJECT,CALLBACK)

1	jQuery.each(OBJECT,CALLBACK)

So, OBJECT can be an object, an array, an array-like object or even a jQuery collection. How cool is that? The CALLBACK is a function that will be run against each element in the first argument. The super-star feature here is that the first argument can be a jQuery DOM collection. This means that jQuery.each() can do ANYTHING that jQuery().each() can do. Let’s jump into some code:

jQuery().each()

Example # 1.A

<ul>
  <li>monday</li>
  <li>tuesday</li>
  <li>wednesday</li>
  <li>thursday</li>
  <li>friday</li>
  <li class="weekend">saturday</li>
  <li class="weekend">sunday</li>
</ul>

<script>
  jQuery('li').each(function(index, value) {
    jQuery(this).css('background-color','yellow');
  });

  jQuery('li.weekend').each(function(index, value) {
    jQuery(this).css('color','red');
  });
</script>

<ul>

<li>monday</li>

<li>tuesday</li>

<li>wednesday</li>

<li>thursday</li>

<li>friday</li>

<li class="weekend">saturday</li>

<li class="weekend">sunday</li>

</ul>

jQuery('li').each(function(index, value) {

jQuery(this).css('background-color','yellow');

});

jQuery('li.weekend').each(function(index, value) {

jQuery(this).css('color','red');

});

</script>

In Example # 1.A, we have an unordered list, with the days of the week as list items. The last two have the “weekend” class applied. We use the $().each() method twice. In the first run, it will iterate over every one of the list items. In the second run, the jQuery collection contains only the last two list items because they have the “weekend” class.

In both cases though, we can see how the $().each() method does one thing and does it well: it iterates over a jQuery collection. Inside of that collection, we use $(this) to get a reference to the current element being iterated over.

Here is the JSFiddle Link for Example # 1.A: http://jsfiddle.net/wcRmd/

Example # 1.B

<ul class="music">
  <li>jazz</li>
  <li class="skip">blues</li>
  <li>rock</li>
  <li class="skip">country</li>
  <li>techno</li>
  <li>metal</li>
</ul>

<script>
jQuery('li').each(function(index,element) {
  //element = 'this'

  //ignore elements with the 'skip' class
    if( jQuery(element).hasClass('skip') ){return};

  jQuery(element)
    //show the index
  .text( jQuery(element).text() + ' -> ' + index)
    .css({
        'background-color' : 'yellow',
        'font-size' : '22px',
        'font-family' : 'arial'     
         });
})
</script>

<li class="skip">blues</li>

<li class="skip">country</li>

<li>techno</li>

<li>metal</li>

</ul>

jQuery('li').each(function(index,element) {

//element = 'this'

//ignore elements with the 'skip' class

if( jQuery(element).hasClass('skip') ){return};

jQuery(element)

//show the index

.text( jQuery(element).text() + ' -> ' + index)

.css({

'background-color' : 'yellow',

'font-size' : '22px',

'font-family' : 'arial'

});

})

</script>

In Example # 1.B, we take advantage of two additional features that the jQuery().each method has to offer. The callback takes two optional arguments: the index of the current element being iterated over, and the element itself. In our example, we add the index of each element to its text, and we do so by referencing ‘element’ instead of ‘this’. Keep in mind that ‘element’ is just what we decided to name that argument variable. We could just have easily named it ‘foo’ or ‘glove’. It doesn’t matter what you name these variables, just as long as you are aware of what they are.

We also used the .hasClass() method to see if each element had the “skip” class. This was just a way to illustrate the fact that while you CAN do things to each element inside of the callback function, you can also choose not to. There are numerous ways that you can organize this kind of logic. Using the ‘skip’ class was merely a ‘quick and dirty’ approach.

Here is the JSFiddle Link for Example # 1.B: http://jsfiddle.net/9C8He/

jQuery.each()

Example # 2.A

jQuery.each(['monday', 'tuesday', 'wednesday'], function(index, value) {
  console.log(value);
});

jQuery.each(['monday', 'tuesday', 'wednesday'], function(index, value) {

console.log(value);

});

In Example # 2A, we pass-in two arguments to the static jQuery.each() method: an array and an anonymous callback function. The array has three elements, and the callback merely outputs the value of each array element to the console. Pretty simple stuff.

Here is the JSFiddle Link for Example # 2.A: http://jsbin.com/epanov/1/edit

Example # 2.B

var data =   {
    name: 'R Jones',
    accountNumber: 10203,
    phoneHome: '212-555-1212',
    phoneMobile: '212-555-1313'
  };

jQuery.each(data, function(index, value) {
  console.log(index + ': ' + value);
});

var data = {

accountNumber: 10203,

phoneHome: '212-555-1212',

phoneMobile: '212-555-1313'

};

jQuery.each(data, function(index, value) {

console.log(index + ': ' + value);

});

In Example # 2.B, we provide an object as the first argument to the jQuery.each() method. When iterating over an object, the jQuery.each() method will return the property name for ‘index’. This is a brilliant approach, as it provides a very flexible alternative to the native JavaScript “for/in” loop.

Here is the JSFiddle Link for Example # 2.B: http://jsbin.com/examuz/1/edit

Example # 2.C

<ul>
  <li>monday</li>
  <li>tuesday</li>
  <li>wedesday</li>
  <li>thursday</li>
  <li>friday</li>
  <li class="weekend">saturday</li>
  <li class="weekend">sunday</li>
</ul>

<script>
$.each( $('li.weekend'), function(index, value) {
    //value = 'this'
    $(value)
    .text( $(value).text() + ' -> ' +  index) 
  .css('color','red');
});
</script>

<ul>

<li>monday</li>

<li>tuesday</li>

<li>wedesday</li>

<li>thursday</li>

<li>friday</li>

<li class="weekend">saturday</li>

<li class="weekend">sunday</li>

</ul>

$.each( $('li.weekend'), function(index, value) {

//value = 'this'

$(value)

.text( $(value).text() + ' -> ' + index)

.css('color','red');

});

</script>

In Example # 2.C, we provide a jQuery DOM collection as the first argument to the jQuery.each() method. Essentially, this is just like using the jQuery().each() method. Inside of the callback function, ‘index’ can be used to get a numerical reference to the current element being iterated over, and ‘value’ will be the element itself. Brilliant.

NOTE: You may wonder why the last two elements have indexes of 0 and 1 respectively. This is because we specified that list items with the ‘weekend’ class should be returned in the collection. So, our jQuery collection object contains only two elements (‘saturday’ and ‘sunday’).

Here is the JSFiddle Link for Example # 2.C: http://jsfiddle.net/XjxvZ/

Summary

In this article we learned the difference between the jQuery.each() and jQuery().each() methods. We also discovered that while they do differ, the jQuery.each() is flexible enough to provide the same functionality as jQuery().each() if needed.

Helpful Links for jQuery().each() and jQuery.each()

jQuery().each()

http://api.jquery.com/each/

jQuery.each()

http://api.jquery.com/jQuery.each/

Apr12013 by dcmNo Comments

Getting Started with Require.js – Part I

Asynchronous Module Definition

Learn how to decouple your code and organize it into reusable modules

Require.js is a JavaScript library that allows you to organize your code into separate modules. It follows the Asynchronous Module Definition API. Each module is an individual JavaScript file. You may, at first, bristle at this pattern because it forces you to rethink the way you organize your JavaScript. But while it may be a bit of an acquired taste, this approach encourages you to write code that is less coupled and easier to reuse.

The two methods that you will likely use the most are require() and define(). In both cases, you specify zero or more modules that your module “depends” on. When you do so, those modules will be loaded asynchronously. These dependencies are specified by a string which is a path to that JavaScript file. These strings must be in an array even if there is only one.

Following the array is an anonymous function. That function takes each dependency as an argument. What you do inside of that function is up to you. Just keep in mind that this function’s return value is what the outside world will “see” when they require your module.

Example # 1 A

define(function(){
	console.log('Hello from module # 1.');
});

define(function(){

console.log('Hello from module # 1.');

});

Example # 1 B

<!DOCTYPE html> 
<html> 
<head> 
    <meta charset="utf-8"> 
    <title>Getting Started with Require.js Part I | blog.kevinchisholm.com</title>
</head> 
<body> 
	<script src="require.js"></script>
	<script>
		require(["module-1"], function() {

		});
	</script>
</body> 
</html>

<!DOCTYPE html>

<html>

<head>

<title>Getting Started with Require.js Part I | blog.kevinchisholm.com</title>

</head>

<body>

require(["module-1"], function() {

});

</script>

</body>

</html>

Example # 1 A shows the code for our first module. It is a single JavaScript file named module-1.js. In that file, we execute the define() function. The define function takes a single argument, which is an anonymous function. In that function, we simply output some text to the console. Our module doesn’t do too much, but we’re keeping it simple for demonstration purposes.

In Example # 1B, we have the code for our web page. At the bottom of the page, we first pull in require.js. Then we execute the require() function. The first argument that it receives is an array. In this case, that array has only one element: “module-1”. That tells require: “hey, there is a file named ‘module-1.js’; load it asynchronously, and when that script has completed loading, run the following anonymous function.” In this example, the anonymous function has no code, so it does nothing.

Example # 2

<!DOCTYPE html> 
<html> 
<head> 
    <meta charset="utf-8"> 
    <title>Getting Started with Require.js Part I | blog.kevinchisholm.com</title>
</head> 
<body> 
	<script src="require.js"></script>
	<script>
		require(["module-1"], function() {
			console.log('Finished loading module # 1.');
		});
	</script>
</body> 
</html>

<!DOCTYPE html>

<html>

<head>

<title>Getting Started with Require.js Part I | blog.kevinchisholm.com</title>

</head>

<body>

require(["module-1"], function() {

console.log('Finished loading module # 1.');

});

</script>

</body>

</html>

In example # 2, we output some text to the console in the anonymous function. That console.log() call will only fire after module-1.js has loaded. This is where we start to see the brilliance of Require.js: you can have another module as a dependency, and your code will only execute once that dependency has loaded successfully.

Example # 3 A

define(function(){
	console.log('module # 1 ran');
	return "Hello, I am the return value of module # 1."
});

define(function(){

console.log('module # 1 ran');

return "Hello, I am the return value of module # 1."

});

Example # 3 B

define(function(){
	console.log('module # 2 ran');
	return "Hello, I am the return value of module # 2."
});

define(function(){

console.log('module # 2 ran');

return "Hello, I am the return value of module # 2."

});

In Examples # 3A and 3B, we see that we now have two modules. In each case, we output some text to the console, just to show that the module executes, and then each module returns a string.

Example # 3 C

<!DOCTYPE html> 
<html> 
<head> 
    <meta charset="utf-8"> 
    <title>Getting Started with Require.js Part I | blog.kevinchisholm.com</title>
</head> 
<body> 
	<script src="require.js"></script>
	<script>
		require(["module-1","module-2"], function(mod1,mod2) {
			console.log('mod1 -> ' + mod1);
			console.log('mod2 -> ' + mod2);			
		});
	</script>
</body> 
</html>

<!DOCTYPE html>

<html>

<head>

<title>Getting Started with Require.js Part I | blog.kevinchisholm.com</title>

</head>

<body>

require(["module-1","module-2"], function(mod1,mod2) {

console.log('mod1 -> ' + mod1);

console.log('mod2 -> ' + mod2);

});

</script>

</body>

</html>

In example # 3C, we pass an array with two elements as the first argument to the require() function: “module-1” and ,”module-2”. The anonymous function that is the second argument receives the return value of each member of that array. We can name these whatever we want. I used “mod1” and “mod2”, but I could just as well have named them “sally” and “sam”. It doesn’t matter; they are simply identifiers for the return value of each dependency. We demonstrate all of this by outputting the return value of each module to the console.

The working example for this article can be found here: http://examples.kevinchisholm.com/javascript/requirejs/part-i/

Summary

In this article, we were introduced to Require.js. We learned about how this JavaScript library allows you to organize your code into individual JavaScript files called “modules”. We learned about the define() and require() functions, their signatures, and how they are used in order to asynchronously load dependencies and create references to their return values.

Helpful Links for Require.js

http://requirejs.org/

http://blog.teamtreehouse.com/organize-your-code-with-requirejs

http://net.tutsplus.com/tag/requirejs/

http://requirejs.org/docs/whyamd.html

Mar272013 by dcmNo Comments

Super Flexible JavaScript Object and Array Iteration with jQuery.each()

jQuery

The jQuery.each() method makes it trivial to iterate over or inspect any kind of collection: arrays, objects, array-like objects, even jQuery DOM Objects.

Working with JavaScript means working with Objects. There is almost no way around this. So even in the simplest of scenarios, at some point you are likely to encounter an object and you need to inspect it.

Keep in mind that in JavaScript, there are different kinds of objects. For example, an array is an object. And, a DOM element is an object. It’s no secret that I am a huge fan of the JavaScript “For/In” loop. If you are not able to use jQuery then that is your go-to tool for object inspection. If you are using jQuery, then the static .each() method is a real winner.

It is important to make sure you understand that this is not the same thing as the $().each() method. When you pass a CSS selector to jQuery and then call the .each() method on the collection that is returned, you are calling a different method in jQuery. It is very similar, but that syntax is meant especially for DOM collections.

The jQuery.each() method is a static method of the jQuery object. It is a more generalized method that can be used to iterate over any object, array or array-like object. So the syntax is quite simple:

jQuery.each(OBJECT,CALLBACK);

1	jQuery.each(OBJECT,CALLBACK);

The OBJECT argument is any object, array or array-like object. The CALLBACK argument can be an inline anonymous function, a named function expression or a variable that points to an anonymous function.

Example # 1

$.each(['monday', 'tuesday', 'wednesday'], function(index, value) {
  console.log(value);
});

$.each(['monday', 'tuesday', 'wednesday'], function(index, value) {

console.log(value);

});

In Example # 1, we have provided a simple array: three strings, each representing a corresponding day of the work week. The callback function executes for each one of the array elements, and inside of that function the variable “value” represents the value of that array element. We could have called that variable “baseball”; it doesn’t matter what you call it. The most important thing to remember is that the second argument to the callback will return the value of the current array element that is being iterated over. So, simple stuff.

Here is a JSBin link for Example # 1: http://jsbin.com/epanov/1/edit

Example # 2

$.each(['monday', 'tuesday', 'wednesday'], function(index, value) {
  console.log(index + ': ' + value);
});

$.each(['monday', 'tuesday', 'wednesday'], function(index, value) {

console.log(index + ': ' + value);

});

In Example # 2, we take advantage of the “index” argument. In the console, we output the value of that variable. Again, this variable can be named anything. As with “value”, it’s most important to be aware that the first argument of the callback will return the index of the array element that is currently being iterated over.

Here is a JSBin link for Example # 2: http://jsbin.com/epezuc/1/edit

Example # 3

$.each(['monday', 'tuesday', 'wednesday',], function(index, value) {
  console.log( value.replace('day', '') );
});

$.each(['monday', 'tuesday', 'wednesday',], function(index, value) {

console.log( value.replace('day', '') );

});

In Example # 3, we take things a step further to illustrate the fact that we can not only access the value of the current array element, but we can do things with it. Here, we simply remove ‘day’ from the string. But there is certainly a whole lot more that one might do. For example, if these array elements were objects instead of primitive strings, we could make changes to the objects and the next person or function who reached for that object would find it changed.

Here is a JSBin link for Example # 3: http://jsbin.com/okoxej/1/edit

Example # 4

var data = [
  {name: 'R Jones',accountNumber: 10203},
  {name: 'K Frost',accountNumber: 242526},
  {name: 'J Sommers',accountNumber: 717273}
];

$.each(data, function(index, value) {
  console.dir(value);
});

var data = [

{name: 'R Jones',accountNumber: 10203},

{name: 'K Frost',accountNumber: 242526},

{name: 'J Sommers',accountNumber: 717273}

];

$.each(data, function(index, value) {

console.dir(value);

});

In Example # 4, we move the object out of the jQuery.each() call and then simply reference it as the variable “data”. This time we have provided an array of objects. So on each iteration of the callback, instead of simply outputting a string, we are inspecting an object.

Here is a JSBin link for Example # 4: http://jsbin.com/usewoj/1/edit

Example # 5

var data =   {
    name: 'R Jones',
    accountNumber: 10203,
    phoneHome: '212-555-1212',
    phoneMobile: '212-555-1313'
  };

$.each(data, function(index, value) {
  console.log(index + ': ' + value);
});

var data = {

accountNumber: 10203,

phoneHome: '212-555-1212',

phoneMobile: '212-555-1313'

};

$.each(data, function(index, value) {

console.log(index + ': ' + value);

});

In Example # 5, things get even more interesting. Here, we can see the brilliance of the jQuery.each() method. In this case we provide an object literal as the first argument to the .each() method. When an object is passed in, then the value of the “index” variable will be the name of the key or property of the object. So this saves you the time it would take to roll your own “For/In” loop.

Here is a JSBin link for Example # 5: http://jsbin.com/examuz/1/edit

Example # 6

$.each( $('li.weekend')), function(index, value) {
  $(this).css('color','red');
});

$.each( $('li.weekend')), function(index, value) {

$(this).css('color','red');

});

In Example # 6, the object that is provided is a jQuery collection object. So now, on each execution of the callback, we can use $(this) to reference the jQuery DOM element object that is being iterated over, and of course do all the usual kinds of fun things to the element with jQuery.

Here is a JSFiddle link for Example # 6: http://jsfiddle.net/n7PRD/

Example # 7

var
data1 =   {
   name: 'R Jones',
   accountNumber: 10203,
   phoneHome: '212-555-1212',
   phoneMobile: '212-555-1313'
 }, 
data2 =   {
   name: 'S Frost',
   accountNumber: 919293,
   phoneHome: '212-555-1234',
   phoneMobile: '212-555-4321'
 };

var inspect = function(index, value) {
 console.dir(value);
};

$.each([data1, data2], inspect);

var

data1 = {

accountNumber: 10203,

phoneHome: '212-555-1212',

phoneMobile: '212-555-1313'

data2 = {

accountNumber: 919293,

phoneHome: '212-555-1234',

phoneMobile: '212-555-4321'

};

var inspect = function(index, value) {

console.dir(value);

};

$.each([data1, data2], inspect);

And here, in Example # 7, we have abstracted the callback. Instead of providing an inline anonymous function, we provide a reference to a variable that is a function: “inspect”. So, that function will be called for every element provided in the data. The data we have provided in an array, and each element of that array is an object with some user account data. Phew! So, on each iteration of the callback (which is really the variable “inspect”, which is a function), we output the contents of that object to the console. We certainly could have done much more here, but the point of the example is that you can abstract any aspect of this that you like. So, as you can see, there is a ton of flexibility here and you are only limited by your imagination.

Here is a JSBin link for Example # 7: http://jsbin.com/iriwer/1/edit

Summary

In this article we learned a bit about the jQuery.each() method. We discussed the simple syntax, as well as the two arguments that are used in the callback. We also explored multiple scenarios such as inspecting an array of strings, inspecting an array of objects, inspecting objects and inspecting jQuery DOM objects.

Helpful Links for the jQuery.each() Method.

http://api.jquery.com/jQuery.each/

http://www.jquery4u.com/jquery-functions/jquery-each-examples/

http://stackoverflow.com/questions/722815/jquery-each-practical-uses

Mar252013 by dcmNo Comments

Hand-Coded JavaScript AJAX – The Absolute Basics

AJAX

Understanding the basic components of an AJAX request / response, and being able to write it all out by hand is an important skill for any JavaScript developer to have.

Yeah yeah yeah, you’ve used jQuery.ajax(). But can you write AJAX code by hand, starting with a blank sheet of paper? While some might feel that jQuery, DoJo and other popular libraries abstract these kinds of details just fine, it’s important to understand what is happening under the hood. So, give me a moment to step down from my soapbox.js and let’s jump into the code.

The XMLHttpRequest Object

The XMLHttpRequest object is the key to AJAX. It is a constructor function that is a property of the window object. You instantiate this object, and then take advantage of the various properties and methods of the instance object that is returned.

Determining Support for the XMLHttpRequest object

Previous to Internet Explorer version # 8, there was no support for the native XMLHttpRequest object. You had to instantiate IE’s ActiveXObject(), and pass in the argument: “Microsoft.XMLHTTP”. Even though the IE6 and below audience is dwindling, someone out there is still using IE6 or IE5, so it’s a good idea to handle that scenario gracefully.

Example # 1

//figure out what kind of support we have for the XMLHttpRequest object
if (window.XMLHttpRequest){
     //modern browsers
     req = new XMLHttpRequest();   
} else {
    //good ol' lousy IE
    req = new ActiveXObject("Microsoft.XMLHTTP");
};

//figure out what kind of support we have for the XMLHttpRequest object

if (window.XMLHttpRequest){

//modern browsers

req = new XMLHttpRequest();

} else {

//good ol' lousy IE

req = new ActiveXObject("Microsoft.XMLHTTP");

};

In Example # 1, we use an IF/ELSE block to determine support for the XMLHttpRequest object. If it is supported, we instantiate the object and if not, we instantiate IE’s native ActiveXObject object.

The onreadystatechange Event

Of the eight events fired by the XMLHttpRequest object, the one we tend to care about most is the onreadystatechange event. It indicates the “readiness” of the XMLHttpRequest object’s request. A ready state of four (4), indicates that the XMLHttpRequest object’s request has generated a response, and that response is in the browser, and ready to be consumed.

The status Property

XMLHttpRequest object’s “status” property represents the HTTP status code returned by the server when our XMLHttpRequest object’s request was sent. There are numerous HTTP status codes that can be returned by a web server, but a detailed discussion of them is outside of the scope of this article. Simply put, we are most often only interested in an HTTP status code of “200” which means: “ok”. It is the web server’s way of saying: “I have completed your request, here it is, and there were no problems”.

So, the combination of an XMLHttpRequest object readystate of 4, and HTTP response code of 200 is the scenario we want. This scenario means that our request was returned, it is ready and there was no problem with the request. Once we know that this condition exists, then we can do something with whatever was returned by the XMLHttpRequest object’s response request.

//when the onreadystatechange event fires, this function will execute

1	//when the onreadystatechange event fires, this function will execute

req.onreadystatechange = function(){ if (req.readyState === 4 && req.status === 200){ //if readyState is “4” and the server response was 200/ok… //inject the returned HTML into the DOM document.getElementById(‘target’).innerHTML = req.responseText; }; };

Opening the XMLHttpRequest Object’s Request

So far, nothing has happened. All we have done is instantiate the XMLHttpRequest object, and set up a function that will execute when we know that the request’s response is “ready” and there was no problem with the request. Now we will open the request.

When calling the open() method of the XMLHttpRequest object, we pass in three arguments:

The type of request (“GET” or “POST”)
The URL that the request should be set to
If the request should be sent asynchronously (you will almost always want this to be “true”)

req.open("GET","ajax-example-1-response.php",true);

1	req.open("GET","ajax-example-1-response.php",true);

Sending the XMLHttpRequest Object’s Request

So this is the final step in writing an AJAX call: sending the request. There is nothing more to do than simply execute the .send() method:

req.send();

1	req.send();

Now let’s look at the markup we’ll need for the article’s example. Below you’ll see two buttons. One will kick off the AJAX request, and the other simply clears the contents of the page. There is also a DIV with an id of “target”. That is the element in which our AJAX request’s response text is injected.

<button id="request">Send AJAX Request</button>
<button id="clear">Clear Page</button>
<div id="target"></div>

<button id="request">Send AJAX Request</button>

<button id="clear">Clear Page</button>

We also have some JavaScript that sets up event handlers for the button clicks. When clicking the button with the ID of “click”, the AJAX request is kicked off and the requests response text is injected into the DIV with the ID of “target”. When clicking the button with the ID of “clear”, the “target” DIV’s contents are cleared.

//setup the click event for the buttons
document.getElementById('request').onclick = ajaxRequest;

document.getElementById('clear').onclick = function(){
	document.getElementById('target').innerHTML = '';
};

//setup the click event for the buttons

document.getElementById('request').onclick = ajaxRequest;

document.getElementById('clear').onclick = function(){

document.getElementById('target').innerHTML = '';

};

It is not critical to be aware of the server page’s code for this very simple example, but in case you are interested, it is a simple PHP page that sends a message that includes the time of the request, allowing us to verify that the requests are being made in real time.

Server Code

<?php
	date_default_timezone_set('EST');
	echo "<p>Hello, this is the response from the server.</p>";
	echo "<p>This response was sent on " . date('l F jS Y') . " at " . date('h:i:s A') . " <i>(new york city time).<i></p>";
?>

<?php

date_default_timezone_set('EST');

echo "<p>Hello, this is the response from the server.</p>";

echo "<p>This response was sent on " . date('l F jS Y') . " at " . date('h:i:s A') . " <i>(new york city time).<i></p>";

Below is the full working code for our AJAX eample:

Example # 2

<!DOCTYPE html>
<html>
	<head>
		<meta charset="utf-8">
		<title>Hand-Coded Ajax Example# 1 </title>
	</head>
	<style>
	p{
		width:40%;
		margin:50px auto 0;
		padding:22px;
		background-color:#ededed;
		border:1px solid #ccc;
		-webkit-border-radius: 05px;
		-moz-border-radius: 05px;
		border-radius: 05px;
		font-family: "HelveticaNeue-Light","Helvetica Neue Light","Helvetica Neue",Helvetica,Arial,"Lucida Grande",sans-serif;
		font-weight: 300;
	}
	p:first-child{
		font-size:32px;
	}
	p:last-child{
		font-size:18px;
	}
	</style>
	<body>
		<button id="request">Send AJAX Request</button>
		<button id="clear">Clear Page</button>
		<div id="target"></div>
		<script>
		function ajaxRequest(){
			//declare the variable at the top, even though it will be null at first
			var req = null;

			//figure out what kind of support we have for the XMLHttpRequest object
			if (window.XMLHttpRequest){
				//modern browsers
				req = new XMLHttpRequest();
			} else {
				//good ol' lousy IE
				req = new ActiveXObject("Microsoft.XMLHTTP");
			};

			//setup the readystatechange listener
			req.onreadystatechange = function(){
				//right now we only care about a successful and complete response
				if (req.readyState === 4 && req.status === 200){
					//inject the returned HTML into the DOM
					document.getElementById('target').innerHTML = req.responseText;
				};
			};

			//open the XMLHttpRequest connection
			req.open("GET","response.php",true);

			//send the XMLHttpRequest request (nothing has actually been sent until this very line)
			req.send();
		};

		//setup the click event for the buttons
		document.getElementById('request').onclick = ajaxRequest;

		document.getElementById('clear').onclick = function(){
			document.getElementById('target').innerHTML = '';
		};
		</script>
	</body>
</html>

<!DOCTYPE html>

<html>

<head>

<title>Hand-Coded Ajax Example# 1 </title>

</head>

<style>

width:40%;

margin:50px auto 0;

padding:22px;

background-color:#ededed;

border:1px solid #ccc;

-webkit-border-radius: 05px;

-moz-border-radius: 05px;

border-radius: 05px;

font-family: "HelveticaNeue-Light","Helvetica Neue Light","Helvetica Neue",Helvetica,Arial,"Lucida Grande",sans-serif;

font-weight: 300;

}

p:first-child{

font-size:32px;

}

p:last-child{

font-size:18px;

}

</style>

<body>

<button id="request">Send AJAX Request</button>

<button id="clear">Clear Page</button>

function ajaxRequest(){

//declare the variable at the top, even though it will be null at first

var req = null;

//figure out what kind of support we have for the XMLHttpRequest object

if (window.XMLHttpRequest){

//modern browsers

req = new XMLHttpRequest();

} else {

//good ol' lousy IE

req = new ActiveXObject("Microsoft.XMLHTTP");

};

//setup the readystatechange listener

req.onreadystatechange = function(){

//right now we only care about a successful and complete response

if (req.readyState === 4 && req.status === 200){

//inject the returned HTML into the DOM

document.getElementById('target').innerHTML = req.responseText;

};

//open the XMLHttpRequest connection

req.open("GET","response.php",true);

//send the XMLHttpRequest request (nothing has actually been sent until this very line)

req.send();

};

//setup the click event for the buttons

document.getElementById('request').onclick = ajaxRequest;

document.getElementById('clear').onclick = function(){

document.getElementById('target').innerHTML = '';

};

</script>

</body>

</html>

Here is a link to the full working page for this article’s example:

http://examples.kevinchisholm.com/ajax/example-1/

Summary

In this article we discussed the XMLHttpRequest object. We learned how to test for the browsers support of this object, instantiate it and assign an anonymous function to handle its onreadystatechange event. Inside of that function, we learned how to check for the readyState property value, the status property and then inject the return text into the DOM. We also discussed how to open the XMLHttpRequest object’s request, and then send it.

Hand-coded AJAX is no big deal, and I’m hoping that this article has left you feeling this way. The key is getting to know the XMLHttpRequest object, specifically its various properties and methods. There is plenty more to talk about with regard to AJAX in native JavaScript, but what we covered in this article is the bare minimum needed to get up and runing.

Helpful Links for hand-coded AJAX

What’s the difference between jQuery.ajax(), jQuery.get() and jQuery.post()?
Using the jQuery Promise Interface to Avoid the AJAX Pyramid of Doom
Using jQuery Deferred to Manage Multiple AJAX calls
What Are the Top 10 JavaScript Links for AJAX ?

Mar182013 by dcmNo Comments

JavaScript Callback Functions – The Absolute Basics

Functions

Callbacks are a critical tool for properly handling asynchronous events in JavaScript.

Timing is one of the most difficult techniques to master in JavaScript. At first, many look to the setTimeout() method to address the asynchronous nature of JavaScript. But that is most often not the best approach. The concept of a callback function is one of the things that makes JavaScript such a special language.

In order to understand callbacks, it is important to be aware that functions are first class citizens in JavaScript. This means (among other things) that a function can be passed as a value to another function. The upside to this is the fact that if you call function A, and pass it function B as an argument, then inside of function A, you can execute function B. That’s really what it all boils down to: You call a function, and pass it another function. And inside of the first function, when an event that you need to complete has completed, you then “call back” to the function that was passed in.

While you can pass a named function as an argument, quite often you will see an anonymous function passed. Before we demonstrate a callback function, let’s demonstrate why they are so helpful in JavaScript.

Example # 1

PHP FIle:

<?php
	sleep(3);
	header('content-type: text/javascript; charset=utf-8');
?>

console.log("1) hello from the script you just loaded");

<?php

sleep(3);

header('content-type: text/javascript; charset=utf-8');

console.log("1) hello from the script you just loaded");

Client-side JavaScript:

function getScript(){
//create a script element and inject it into the page
var script = document.createElement('script');
script.src = 'http://sub1.kevinchisholm.com/blog/examples/sleep1.php';
document.getElementsByTagName('head')[0].appendChild(script);
};

getScript();
console.log("2) the new script has been loaded"); //fires before the script finishes loading

function getScript(){

//create a script element and inject it into the page

var script = document.createElement('script');

script.src = 'http://sub1.kevinchisholm.com/blog/examples/sleep1.php';

document.getElementsByTagName('head')[0].appendChild(script);

};

getScript();

console.log("2) the new script has been loaded"); //fires before the script finishes loading

In Example # 1, we have two chunks of code: A server-side page that sleeps for three seconds, and then returns a JavaScript file. That JavaScript file simply outputs a message to the console.

When the script loads, it outputs a message to the console (message # 1). We want that message to be output before the 2nd message. The problem is that the script loading process is asynchronous; it could take 200ms, it could take five minutes. I’ve forced the PHP page that returns the JavaScript to “sleep” for three seconds, to exaggerate the effect. But the bottom line is: we don’t know how long that script loading process will take, which means that we have to find a way to execute message # 2 only after the script has finished loading.

Here is a JSFiddle link for Example # 1: http://jsfiddle.net/CZeLv/

Example # 2

function getScript(callback){
   //create a script element and inject it into the page
   var script = document.createElement('script');
   script.src = 'http://sub1.kevinchisholm.com/blog/examples/sleep1.php';
   document.getElementsByTagName('head')[0].appendChild(script);

   //when the new script's load event fires, execute the callback
   script.onload = callback;
};

getScript(function(){
   console.log("the new script has been loaded"); //much better!
});

function getScript(callback){

//create a script element and inject it into the page

var script = document.createElement('script');

script.src = 'http://sub1.kevinchisholm.com/blog/examples/sleep1.php';

document.getElementsByTagName('head')[0].appendChild(script);

//when the new script's load event fires, execute the callback

script.onload = callback;

};

getScript(function(){

console.log("the new script has been loaded"); //much better!

});

In Example # 2, we pass an anonymous function to the getScript() method. Inside of getScript(), we take advantage of the fact that any dynamically loaded script element has an “onload” event. We assign that event to the callback that was passed-in. This means that when the script has successfully loaded, we execute the callback. As a result, we have complete control over the timing of events, even though the entire process is asynchronous. What happens is that message # 1 executes first, and then message # 2. This is what we want.

Here is a JSFiddle link for Example # 2: http://jsfiddle.net/dfCM2/

What if the script that we are loading has properties and methods that we need to act upon once the script is available? In Example # 3, we demonstrate how using a callback allows us to call a method that does not exist before the script is loaded, but we are able to control the timing of when it is called, so that it works every time.

Example # 3

PHP File:

<?php
sleep(3);
header('content-type: text/javascript; charset=utf-8');
?>

window.getSecretWord = function(){
	return "milkshake";
};

<?php

sleep(3);

header('content-type: text/javascript; charset=utf-8');

window.getSecretWord = function(){

return "milkshake";

};

Client-side JavaScript:

function getScript(callback){
   //create a script element and inject it into the page
   var script = document.createElement('script');
   script.src = 'http://sub1.kevinchisholm.com/blog/examples/sleep2.php';
   document.getElementsByTagName('head')[0].appendChild(script);

  //when the new script's load event fires, execute the callback
   script.onload = callback;
};

getScript(function(){
   //window.getSecretWord now exists
   var secret = getSecretWord();

   //output the secret
   console.log("The secret word is: " + secret);
});

function getScript(callback){

//create a script element and inject it into the page

var script = document.createElement('script');

script.src = 'http://sub1.kevinchisholm.com/blog/examples/sleep2.php';

document.getElementsByTagName('head')[0].appendChild(script);

//when the new script's load event fires, execute the callback

script.onload = callback;

};

getScript(function(){

//window.getSecretWord now exists

var secret = getSecretWord();

//output the secret

console.log("The secret word is: " + secret);

});

In Example # 3, after the PHP file “sleeps” for three seconds, it adds a new method to the window object. That method returns a secret word. We need access to that secret word in our page, but we need to make sure that we don’t try to call the method getSecretWord() until it is available. So by passing a callback to the getScript() function, we yield control to getScript() and basically ask it to fire our callback for us. Inside of getScript(), the script’s onload event is assigned to the callback, which means we only attempt to execute getSecretWord() once we know for sure that it exists (because the script’s onload event fired).

So the important thing to keep in mind here is that if the script we are loading takes five minutes to return, or never returns, it does not matter. Our callback will only fire when that script successfully loads. While it is loading, the user still has complete access to the browser. That is really important.

Here is a JSFiddle link for Example # 3: http://jsfiddle.net/fAn4g/

Summary

In this article, we covered the very basics of JavaScript callback functions. We learned that functions are first-class citizens in JavaScript, and can be passed to and from functions. We looked at an example of why callbacks are so critical to the JavaScript language and how they are an excellent tool for working around the asynchronous nature of the language,

Helpful Links for JavaScript Callback Functions

http://recurial.com/programming/understanding-callback-functions-in-javascript/

http://www.impressivewebs.com/callback-functions-javascript/

http://javascript.about.com/od/byexample/a/usingfunctions-callbackfunction-example.htm

Mar42013 by dcmNo Comments

jQuery Plugin Authoring – The Absolute Basics – Part II

jQuery

Once you have jQuery plugin basics down, it’s time to implement some best practices

In the previous post “jQuery Plugin Authoring – The Absolute Basics – Part I”, we to a detailed look at the architecture of a jQuery plugin. Now that you understand the building blocks, let’s discuss a few best practices. These techniques are considered standard for quality jQuery plugin authoring, and will dress you for success.

Protecting the Dollar Sign

Most jQuery consumers associate the dollar sign with jQuery. But that dollar sign is simply a shortcut to the jQuery object, which is a property of the window object. You could write all of your jQuery code without ever using the dollar sign, and simply “jQuery” instead. But most people prefer the dollar sign because it is of course quite a bit easier and faster to type.

But jQuery offers a “no conflict” mode that allows another library to take over the dollar sign. It is considered best practice to anticipate this scenario and pass the global jQuery object into the immediate function that wraps your plugin. This way, inside of the nice and safe sandbox of your plugin, you can use the dollar sign all you like, without the slightest concern for how it is being used in the global context.

Example # 1

(function($){
	$.fn.myPlugin = function() {
		this.each(function(index){
			//plugin code goes here....
		});
	};	
})(jQuery);

(function($){

$.fn.myPlugin = function() {

this.each(function(index){

//plugin code goes here....

});

};

})(jQuery);

In Example # 1, we pass the global jQuery object into the immediate function. The immediate function takes that jQuery object as “$”, so from there on we are free to use the dollar sign safely, even if jQuery is in no-conflict mode.

Chainability

Method chaining is a popular technique in JavaScript. Many web developers use this technique when they leverage jQuery without even knowing it. How many time have you seen something like this:

$(SOME PARENT).find(SOME CHILD).CSS(“prop”,”val”).click();

What signifies the chaining activity is the fact that we have only one reference to the jQuery collection returned by $(SOME PARENT). Since each method used returns the jQuery object, we can use that return value to invoke another jQuery method, and so on. This is called “Chaining” method calls together.

It is considered best practice to allow method chaining when authoring your own jQuery plugin. Doing so is quite simple; you just need to return the jQuery object from each method.

Example # 2

(function($){
	$.fn.myPlugin = function() {
		this.each(function(index){
			//plugin code goes here....
		});
	return this;
	};	
})(jQuery);

(function($){

$.fn.myPlugin = function() {

this.each(function(index){

//plugin code goes here....

});

return this;

};

})(jQuery);

In Example # 2, we return “this” from our plugin function. It’s important to note where the return statement is. Because the return statement occurs as the last line of code in our plugin’s function, the jQuery collection object is returned to the next method that wants to “chain”, without the need to re-state a jQuery collection.

Example # 3

$('a').myPlugin().attr("target","_blank");

1	$('a').myPlugin().attr("target","_blank");

In Example # 3, we have an example of method chaining in jQuery. Note that $(‘a’) only occurs once. That call to jQuery returns a jQuery collection object, which is returned from our jQuery plugin. As a result, the .attr() method can “chain” onto that return value and function properly.

Example # 4

$('a')
.myPlugin()
.attr("target","_blank")
.css("font-size","30px")
.click(function(){
    alert("You clicked: " + $(this).text() + "!");
    return false;
});

$('a')

.myPlugin()

.attr("target","_blank")

.css("font-size","30px")

.click(function(){

alert("You clicked: " + $(this).text() + "!");

return false;

});

In Example # 4, we have an even more complex example of method chaining. First we invoke “myPlugin”, and the the jQuery methods: .attr(), .css() and .click()

Here is a fully working JSFiddle.net link that demonstrates the best practices we have covered in this article. Be sure to click a few of the links to demonstrate the method chaining from example # 4:

http://jsfiddle.net/fTA95/

Summary

In this article we discussed a few jQuery plugin authoring best practices. We covered how to safely use the dollar sign in your plugin code, even when jQuery is in no-conflict mode. We also covered how to implement method chaining.

Helpful Links for jQuery plugin authoring

http://docs.jquery.com/Plugins/Authoring
http://stackoverflow.com/questions/12632382/jquery-plugin-authoring-and-namespacing

Feb252013 by dcmNo Comments

jQuery Plugin Authoring – The Absolute Basics – Part I

jQuery

You know a little jQuery, you have used a few jQuery plugins, and now you want to write your own jQuery plugin. Don’t worry, it’s no big deal. In fact it’s fun.

If you have been putting off authoring your first jQuery plugin, it’s time to wrap a bandana around your head, fire up “The Eye of the Tiger” by “Survivor” and figure out how to defeat Apollo Creed. Sorry, for the cheesy 80s reference, I couldn’t resist.

But seriously, it really is no big deal. The most important thing is to get a firm grip on the fundamentals. That part is serious. If you don’t understand what you are doing from a jQuery-architecture standpoint, then you will quickly find yourself in a quagmire of muck and filth, and you don’t want that.

In this article we will discuss the absolute basics of how to author a jQuery plugin:

Wrapping your plugin in a self-executing anonymous function
Extending the jQuery prototype,
Iterating over each element in the jQuery collection returned by your plugin.

This is the big stuff. Once you get your noggin around these concepts, the fun can begin.

A note about Self-executing anonymous functions

These are otherwise known as “immediate functions”. An immediate function is simply a function that is wrapped in parentheses, and followed by a pair of parentheses:

(function(){
	//code here fires right away, you don’t need to call the function
})();

(function(){

//code here fires right away, you don’t need to call the function

})();

You can learn more about immediate functions in my blog post: “Immediate Functions in JavaScript – The Basics” as well as my blog post: “Using an Immediate Function to Create a Global JavaScript Variable That Has Private Scope”

The main point here is to make sure you are comfortable with the concept of an immediate function in JavaScript. It’s important to do before reading further.

Where does my jQuery plugin code go?

Good question. The answer is: In its own file. By convention, you’ll want to create a JavaSript file named jquery.myPlugin.js. Then you’ll need to reference it just as you would any other JavaScript file:

<script src=”[PATH TO]/jquery.myPlugin.js”></script>

1	<script src=”[PATH TO]/jquery.myPlugin.js”></script>

Just make sure you reference jQuery before you reference your plugin.

For simplicity sake, we will reference our jQuery plugin via a set of SCRIPT tags, right in the page (that is perfectly valid, but definitely not practical).

<!DOCTYPE html>
<html> 
    <head> 
        <meta charset="utf-8"> 
        <title>My first jQuery Plugin</title>
        <script src="jquery.js"></script>
    </head> 
    <body>
    	<p>some content here...</p>

	<script>
			//our plugin code is gonna go right here!
	</script>

	<script>
		$(document).ready(function(){
			//we're gonna invoke our plugin here!
		});
	</script>
    </body> 
</html>

<!DOCTYPE html>

<html>

<head>

<title>My first jQuery Plugin</title>

</head>

<body>

<p>some content here...</p>

//our plugin code is gonna go right here!

</script>

$(document).ready(function(){

//we're gonna invoke our plugin here!

});

</script>

</body>

</html>

Example # 1

(function(){
	$.fn.myPlugin = function() {
		this.each(function(){
			//plugin code goes here
		});
	};	
})();

(function(){

$.fn.myPlugin = function() {

this.each(function(){

//plugin code goes here

});

};

})();

In example # 1 we have the absolute bare-bones code needed for a jQuery plugin. Here are the important points to consider for example # 1:

Wrap your jQuery plugin in an immediate Function

This is considered a best-practice and for good reason. Taking this approach allows you to create as many variables as you need in your plugin, without polluting the global namespace. Don’t overlook this, it allows you complete freedom with regards to the number of variables you need to create, and sandboxes all of these variables very nicely.

Again, an immediate function is simply a function that is wrapped in parentheses, and followed by a pair of parentheses. It fires right away when the JavaScript is evaluated, you don’t need to (and cannot) call the function. It just fires right away and whatever code you implement in that function executes. It’s a great way to provide private variable scope to some code without a whole lotta fuss.

If you are still having a tough time with the concept of immediate functions, stop, do a google search for JavaScript Immediate Function, learn it, live it, ask it out on a date, marry it, and then come back here to keep on reading.

https://www.google.com/search?q=javascript+immediate+function

(I’m serious about this immediate function thingy)

Your jQuery plugin becomes a property of the jQuery prototype object

jQuery is a function. Actually, the code in jQuery follows the factory pattern and returns a function that in-turn returns different kinds of things, depending on what you pass into that function. Most of the time, it returns an HTML collection wrapped with jQuery (hence a jQuery collection object), but again, the actual return value depends on what you are passing in.

Every JavaScript object has a prototype property, this includes functions. jQuery exposes its prototype property as “fn”. So, you simply assign your plugin to be a property of that “fn” object. Once you have done that, jQuery now has a new method that is YOUR plugin.

$.fn.myPlugin = function(){
	//insert awesome code here
};

$.fn.myPlugin = function(){

//insert awesome code here

};

Now you can do this:

$(‘div’).myPlugin();

1	$(‘div’).myPlugin();

Inside of your plugin, the JavaScript keyword “this” is already a jQuery object

Most people know that inside of a jQuery callback, “this” usually refers to the current native DOM element that is being iterated over. When you wrap “this” in jQuery, it becomes a jQuery object. So, we often refer to “this” as “$(this)”.

Inside of your plugin, there is no need to do that because the JavaScript keyword “this” is already a jQuery object. If you refer to “this” as “$(this)”, it’s not going to kill anyone, but it is not necessary and just uses more memory than is needed.

$.fn.myPlugin = function(){
	//”this” is already a jQuery collection object
};

$.fn.myPlugin = function(){

//”this” is already a jQuery collection object

};

Your jQuery plugin returns a jQuery collection

What your jQuery plugin returns depends on the CSS selector that was passed-in. For example, if you do this: $(body).myPlugin(), your jquery plugin will return a jQuery collection that has exactly one element: the BODY tag of your document (unless of course you have more than one BODY element in your page, which would be a bit of a head-scratcher). So, if you have an unordered list that has for example three items, and you invoke your plugin like this: $(ul li).myPlugin(), then your plugin will return a jQuery collection that contains three elements.

Use this.each() to iterate over all of the elements that are returned by your jQuery plugin

jQuery’s .each() method is a lovely little tool that allows you to iterate over a jQuery collection and “do something” to each element. Keep in mind that a jQuery collection can always contain exactly one element, and when it does, then the .each() method will run once. But when a jQuery collection contains multiple elements, then the .each() method will run once for EACH element in that collection.

When you use the .each() method, you pass in an anonymous function, and inside that function you have access to the current element that is being iterated over. It is here that you will need to wrap “this” with jQuery if you want it to be a jQuery object: Use $(this) for the jQuery object that represents the current element, or simply “this” for the native DOM element implementation. This anonymous function takes as its first argument the index of the current element. This is surprisingly handy: what if you want to know if this the the first element in the collection? or the last? That index number will help you with that task.

Now you are ready to write some awesome jQuery plugin code

Thanks for hanging in there. The preceding details were important. I know you are anxious to write some code, but understanding the outer architecture of a jQuery plugin is critical. If you do not understand what was just covered, then you will quickly be awash in spaghetti code that is not working right and will be difficult to debug. I promise you.

Example # 2

//Example # 2A
//run myPlugin against every A tag in the document
$(document).ready(function(){
	$('a').myPlugin();	
});

//Example # 2A

//run myPlugin against every A tag in the document

$(document).ready(function(){

$('a').myPlugin();

});

In example # 2, we invoke our jQuery plugin. We wrap it in a $(document).ready() call so that it only fires once the document is ready.

Invoking our plugin is as simple as $(CSS SELECTOR).myPlugin().

This is because our plugin is a property of the jQuery prototype object, which makes it a completely valid jQuery method. Nice.

Example # 3

//Example # 3A
//run myPlugin against every LI tag in the document
$(document).ready(function(){
	$('li').myPlugin();	
});

//Example # 3B
//run myPlugin against every LI tag in the document that is the last one in a list
$(document).ready(function(){
	$('li:last').myPlugin();	
});

//Example # 3C
//run myPlugin against the BODY tag
$(document).ready(function(){
	$('body').myPlugin();	
})

//Example # 3A

//run myPlugin against every LI tag in the document

$(document).ready(function(){

$('li').myPlugin();

});

//Example # 3B

//run myPlugin against every LI tag in the document that is the last one in a list

$(document).ready(function(){

$('li:last').myPlugin();

});

//Example # 3C

//run myPlugin against the BODY tag

$(document).ready(function(){

$('body').myPlugin();

})

In example # 3, we see how our plugin can behave differently depending on what we pass into it. In each case, the jQuery collection object returned by our plugin will differ, depending again on what CSS selector we passed-in.

Example # 4

(function(){
	$.fn.myPlugin = function() {
		//for each element in the collection
		this.each(function(){
			//make the element green,
//..the background yellow,
//...and the font bold 18px Comic Sans 
			$(this).css({
				'color':'green',
				'background-color': 'yellow',
				'font': 'bold 18px "Comic Sans MS",cursive,sans-serif'
			});
		});
	};	
})();

(function(){

$.fn.myPlugin = function() {

//for each element in the collection

this.each(function(){

//make the element green,

//..the background yellow,

//...and the font bold 18px Comic Sans

$(this).css({

'color':'green',

'background-color': 'yellow',

'font': 'bold 18px "Comic Sans MS",cursive,sans-serif'

});

};

})();

In example # 4, we have included some implementation code so that our jQuery plugin actually does something. I this case, for each element returned in the jQuery collection, we change the CSS so that the element’s color is green, the background color is yellow, and the font is “Comic Sans”. Not too pretty, but just enough so that when we run the code, we can see that our plugin is working perfectly. More importantly, if you vary the CSS selector that is passed-in, you will see that our plugin behaves differently in each case (i.e. the HTML elements that become green with yellow backgrounds and Comic Sans font will vary).

Full Working Code for this Article
http://jsfiddle.net/wdUtL/

Full Working Code for this ArticleWith Comments
http://jsfiddle.net/ewTez/

Summary

In this article we discussed the absolute basics of how to author a jQuery plugin. We covered how to wrap your plugin in a self-executing anonymous function, how to extend the jQuery prototype, and how to iterate over each element in the jQuery collection returned by your plugin.

This example provided in this article was very simple. The main purpose of the article was to provide the overview needed so that you understand how a jQuery plugin is constructed, how it works at the most basic level, and importantly how the value of the JavaScript keyword “this” will vary a bit, depending on where you are in the code.

With a firm understanding of how a jQuery plugin is constructed, we can move on to best practices and more intermediate jQuery plugin authoring techniques.

Helpful Links for jQuery plugin authoring basics

http://docs.jquery.com/Plugins/Authoring

http://coding.smashingmagazine.com/2011/10/11/essential-jquery-plugin-patterns/

http://blog.kevinchisholm.com/jquery/jquery-each-method/

Feb192013 by dcm1 Comment

Mustache.js – The Absolute Basics

JavaScript-Templating

If you’ve been writing client side code for more than 15 minutes, you have likely had to consume and present JSON data. This is becoming a common scenario for front-end web developers.

The problem is that in most cases, you are inserting the return values into the same markup. So this means that you might be writing your own for-loops and element creation functions. But even with the help of the mighty jQuery, this can get tedious. More importantly, you are likely writing the same code more than once, each time customizing it for the specific situation. Well, regardless of the details, if this even partially describes some of the challenges you have faced lately, then it is likely that a client-side templating solution is needed.

Enter Mustache.js

Mustache.js is a lightweight JavaScript library that provides client-side templating. The feature-set is intentionally small. While some may see this as a drawback, I agree with their approach. The footprint is so small, that it is really a non-issue when it comes to considering the additional HTTP request (and you can, of course, concatenate it to your main JS file if you so choose). Websites such as Twitter, CNN and eBay, Inc. have turned to this JavaScript library, which is a testament to its power and usefulness.

The syntax is pretty simple

var foo = Mustache.render(TEMPLATE,DATA);
document.getElementById(SOME-ELEMENT).appendChild(foo);

1 2	var foo = Mustache.render(TEMPLATE,DATA); document.getElementById(SOME-ELEMENT).appendChild(foo);

TEMPLATE = Your HTML code with {{VALUE}} placeholders
DATA = Your JSON Data

Example # 1

(function(){
    //pass a template and some JSON data to Mustache.js
    var output = Mustache.render("{{name}}&lt;br /&gt;{{city}}",{
        "name": "Joe Smith",
        "city": "London"
    });

    //append the HTML that Mustache.js has created to the DOM
    $('#container').append(output);
})();

(function(){

//pass a template and some JSON data to Mustache.js

var output = Mustache.render("{{name}}<br />{{city}}",{

"name": "Joe Smith",

"city": "London"

});

//append the HTML that Mustache.js has created to the DOM

$('#container').append(output);

})();

Here is the fully-working JSFiddle.net link for Example # 1: http://jsfiddle.net/MsuPp/

In Example # 1, we call the render() method, which is a static member of the Mustache object. This method takes two arguments: the templated markup and the JSON data. This is not the most efficient way to utilize the method, but it is a good way to demonstrate how simple it is. Just create your HTML wtih the {{tag}} syntax where you want your output, and provide some data. Then use jQuery to append the return value of this method call to the element with the id of “container”.

Example # 2

<!-- this is the HTML template -->
<script type="text/html" id="template">
		<h1>My Favorite European Cities</h1>
		<ul>
			{{#cities}}
			<li>{{name}}</li>
			{{/cities}}
		</ul>
</script>

<!-- this div is empty on page load -->
<div id="container"></div>

<script>
	(function(){
		//this is our JSON (data)

		var data = {
			"cities": [
				{"name": "London"},
				{"name": "Paris"},
				{"name": "Munich"}
			]
		},

		//get a reference to our HTML template
		template = $('#template').html(),

		//tell Mustache.js to iterate through the JSON and insert the data into the HTML template
		output = Mustache.render(template, data);

		//append the HTML template to the DOM
		$('#container').append(output);
	})();
</script>

<h1>My Favorite European Cities</h1>

<ul>

</ul>

</script>

(function(){

//this is our JSON (data)

var data = {

"cities": [

{"name": "London"},

{"name": "Paris"},

{"name": "Munich"}

]

//get a reference to our HTML template

template = $('#template').html(),

//tell Mustache.js to iterate through the JSON and insert the data into the HTML template

output = Mustache.render(template, data);

//append the HTML template to the DOM

$('#container').append(output);

})();

</script>

Here is the fully-working JSFiddle.net link for Example # 2: http://jsfiddle.net/WhxMa/2/

Mustache.js spares you the headaches of writing the same JSON iteration / DOM creation code over and over with each project.

In Example # 2, we use a slightly more advanced approach. First, note the SCRIPT tag with the id of “template”. Instead of giving the type attribute a value of “text/javascript”, we use type=”text/html”. Since this makes no sense to the browser, the text node inside of the SCRIPT tags is ignored. But at the same time, that same text is available to us, so it is a great place to store template markup.

Inside of this SCRIPT tag, we have the opening and closing {{#cities}}{{/cities}} placeholders. This is used as a loop. What it does is tell Mustache.js: “Hey for each one of the elements in the ‘cities’ array, populate the markup accordingly.” So, Mustache.js iterates over that same markup for each element in the “cities” array, and inserts the value of cities[“name”] where the {{name}} placeholder appears.

Summary

These example are very basic and there is much more to dive into with Mustache.js. My hope is that this post has provided an overview that, at minimum, helps you to begin understanding and implementing this library.

Helpful Links for Mustache.js

https://github.com/janl/mustache.js/

http://mustache.github.com/

http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-using-the-mustache-template-library/

http://www.youtube.com/results?search_query=Mustache.js

Feb132013 by dcm3 Comments

What is the Difference Between Scope and Context in JavaScript?

JavaScript

In JavaScript, scope and context are not the same thing, and it’s important to understand the difference between them. Fortunately, the answer is short and simple.

Why Should We Care About Scope and Context ?

When interviewing front-end developers, I usually try to include a question about scope and context in JavaScript. I always ask what the difference is, and I am often surprised by the answers I get. It seems that even those with some experience have difficulty answering this question.

The answer is short and simple: Scope pertains to the visibility of variables, and context refers to the object to which a function belongs.

Scope in JavaScript

Scope has to do with the the visibility of variables. In JavaScript, scope is achieved through the use of functions. When you use the keyword “var” inside of a function, the variable that you are initializing is private to the function, and cannot be seen outside of that function. But if there are functions inside of this function, then those “inner” functions can “see” that variable, and that variable is said to be “in-scope”. Functions can “see” variables that are declared inside of them. They can also “see” any that are declared outside of them, but never those declared inside of functions that are nested in that function. This is scope in JavaScript.

Context in JavaScript

Context is related to objects. It refers to the object to which a function belongs. When you use the JavaScript “this” keyword, it refers to the object to which function belongs.

Scope refers to the visibility of variables, and content refers to the object to which a function belongs.

For example, inside of a function, when you say: “this.accoutNumber”, you are referring to the property “accoutNumber”, that belongs to the object to which that function belongs. If the object “foo” has a method called “bar”, when the JavaScript keyword “this” is used inside of “bar”, it refers to “foo”. If the function “bar” were executed in the global scope, then “this” refers to the window object (except in strict mode). It is important to keep in mind that by using the JavaScript call() or apply() methods, you can alter the context within which a function is executed. This, in-turn, changes the meaning of “this” inside of that function when it is executed.

Summary

As a front-end developer, you can surely appreciate what an important topic this is, and how critical it is to understand the difference between scope and context in JavaScript. These two subjects become very important as soon as you have to write or edit even intermediate-level JavaScript, and your ability to comfortably and confidently write / edit JavaScript will only improve once you have a good working knowledge of the difference between scope and context. The good news is, it’s not that difficult to understand and once you get it, you’ve got it.

Helpful Links for understanding the difference between scope and context in JavaScript

What’s the Difference Between Scope and Context in JavaScript ? | Skillshare

Understanding Scope in JavaScript – Function Level Scope | Kevin Chisholm – Blog

Understanding Context in JavaScript – Object Literals | Kevin Chisholm – Blog

Nov42012 by dcm4 Comments

Two Ways to Dynamically Append an Element to a JavaScript Array

JavaScript

There are two ways to dynamically add an element to the end of a JavaScript array. You can use the Array.prototype.push() method, or you can leverage the array’s “length” property to dynamically get the index of what would be the new element’s position.

I have provided candidate pre-screening services for recruiters in the past, and one of the classic JavaScript interview questions is: “Name two ways to dynamically append an element to a JavaScript array.” Some folks nail that question, but some are left scratching their heads. So I thought I’d quickly re-visit the logic behind this concept.

At first glance, some might say: “Well, you are the programmer. So you know how long the array is and can dynamically append an element by doing the following: foo[x] = newElement. Right?” Well, yes, but that is not what we are really trying to do.

Why Dynamically Append an Element to a JavaScript Array ?

I think that most programmers will agree that what you want in this situation is to be able to add an element to the array, regardless of the length. What you want to assume is that you will not know the length. And from a pseudo-code perspective, you want to say: “Hey, I have an array named ‘foo’ and however long it is, add this new element named ‘newElement’ to the end of it.” I think that when you can accomplish that, you have significantly more power.

Array.prototype.push() – Example # 1

In Example # 1, we used JavaScript’s Array.prototype.push() method. This wonderful little utility adds whatever you pass it to the end of the array.

The syntax is: yourArray.push(WhatYouWantToAdd)

It’s literally that simple.

Using the array’s “length” property – Example # 2

In Example #2, we leverage the “length” property of the array. The reason this works so well is that the value of an array’s “length” property will always be exactly one higher than the index of the last element in the array. Why? Because while array indexes are zero-based (i.e. the first element in the array is element 0, and the second element in the array is element # 1, and the third element is element # 2, etc…), the array’s “length’”property is a one-based value (i.e., if there are three elements in the array, the length is: 3).

So, if the array “foo” has three elements, foo[2] is the last element in the array, and the value of foo’s “length” property is “3”. Therefore, foo[3] does not exist yet (remember foo[2] is the last element).

Since we may not always know the length of the array when we need to dynamically append an element by simply adding a new element to the end, we can reference foo[.foo.length]. This way, no matter how many elements are in foo, we can simply assign the new element to foo[.foo.length].

Helpful Links for JavaScript Arrays

JavaScript for Beginners | Arrays: Adding and Removing Elements

JavaScript Array Management with Push(), Pop(), Shift() and Unshift()

Why is a JavaScript Array’s Length Property Always One Higher Than the Value of the Last Element’s Index?

Summary

There are two ways to dynamically append an element to the end of a JavaScript array. You can use the Array.prototype.push() method, or assign the new variable to the index that is equal to the array’s “length” method.

Sep102012 by dcm2 Comments

Making Your JavaScript Code Easier to Understand: Object Literals

JavaScript

When it comes to organizing your object literals, there are multiple approaches you can take

Object Literals are a very useful feature of JavaScript. They allow you to easily build structures of data or functionality (or both mixed together), without too much fuss and drama. The syntax is simple and they make it easy to name-space your code. But, when your object literals start to grow in size, they can become a bit difficult to manage. And, it can sometimes make your code harder to follow.

In the next few examples, I will cover a couple of alternate ways to organize your JavaScript Object Literals. This can make your code easier to manage and understand.
Example # 1

var mathFuncs = {
	add: function(a,b){
	return a + b;
     },
	subtract: function(a,b){
		return a - b;
     },
	multiply: function(a,b){
		return a * b;
     }
}

var mathFuncs = {

add: function(a,b){

return a + b;

subtract: function(a,b){

return a - b;

multiply: function(a,b){

return a * b;

}

In Example # 1, we have an object literal that has been assigned to the variable “mathFuncs”. This object has three members: “add”, “subtract” and “multiply”. Each is a function. This is not too bad, but what if each function was tens or even hundreds of lines of code? The entire “mathFuncs” object itself would grow to become thousands of lines long. This can become unwieldy. Also, if while making edits, one semicolon gets knocked out of place, the entire object is likely to become defective, which will pretty much kill the script.

Example # 2

mathFuncs = {};

mathFuncs.add = function(a,b){
	return a + b;
};

mathFuncs.subtract = function(a,b){
		return a - b;
};

mathFuncs.multiply = function(a,b){
		return a * b;
}

mathFuncs = {};

mathFuncs.add = function(a,b){

return a + b;

};

mathFuncs.subtract = function(a,b){

return a - b;

};

mathFuncs.multiply = function(a,b){

return a * b;

}

In Example # 2, “mathFuncs” is initially one line of code: an empty object. We then extend the object by adding more properties. In this case, the three properties we add are “add”, “subtract” and “multiply”. Functionally, there is no difference between this approach and Example # 2. These anonymous functions will perform no differently. What is different is that the code is a little bit easier to follow. First you see that “mathFuncs” is an empty object, and then we add properties to it. These properties are all functions, so they should be referred to as “methods”. Also, if you have a bug in one of the anonymous functions, it is less likely to break the entire script, and could be easier to track down.

Since these functions are very small, there is yet another level of optimization that we can apply:

Example # 3

mathFuncs = {};

mathFuncs.add = function(a,b){return a + b};

mathFuncs.subtract = function(a,b){	return a - b};

mathFuncs.multiply = function(a,b){return a * b};

mathFuncs.bigFunc1 = function(){
	//this is a much bigger function
	//with multiple lines of code
	//so let’s put it at the bottom
};

mathFuncs.bigFunc2 = function(){
	//this is a much bigger function
	//with multiple lines of code
	//so let’s put it at the bottom

};

mathFuncs = {};

mathFuncs.add = function(a,b){return a + b};

mathFuncs.subtract = function(a,b){ return a - b};

mathFuncs.multiply = function(a,b){return a * b};

mathFuncs.bigFunc1 = function(){

//this is a much bigger function

//with multiple lines of code

//so let’s put it at the bottom

};

mathFuncs.bigFunc2 = function(){

//this is a much bigger function

//with multiple lines of code

//so let’s put it at the bottom

};

In Example # 3 we tightened up the first three functions because there is so little going on in them, so it’s no harm to make them all one line each. Again, it’s just easier for someone else to quickly read and understand. We added two new properties, both anonymous functions as well. Since these are bigger functions (let’s pretend they are each 50+ lines of code), we put them last so that they are a bit out of the way, and we only have to see all that implementation code if we care to.

This is all a matter of preference. From time to time, I think that not everyone realizes that there are options when it comes to object literals and how you choose to write them out. The approach taken in Example # 1 is fine, especially when the objects are small. But when you have many properties in your object, and those properties are anonymous functions that contain tens or hundreds of lines of code, it can make your logic hard for someone else to follow.

Summary

There are many ways to skin a cat, and as many ways to organize your JavaScript code. The purpose of this post was to offer a few suggestions that can make your object literals a little bit easier to read, especially for someone else who, in the future, might have to read, understand and then make changes to your code.

Aug272012 by dcm3 Comments

Understanding Context in JavaScript – Object Literals

JavaScript

Why is the word “this” so important in JavaScript?

In the post: “Understanding Scope in JavaScript,” I covered the basics of how scope works when dealing with functions. Sometimes the words “scope” and “context” are used interchangeably, which only leads to confusion because they are not the same thing.

In JavaScript, “context” refers to an object. Within an object, the keyword “this” refers to that object (i.e. “self”), and provides an interface to the properties and methods that are members of that object. When a function is executed, the keyword “this” refers to the object that the function is executed in.

Here are a few scenarios:

When a function executes in the global context, “this” refers to the global, or “window” object
When a function is a method of an Object, “this” refers to that object (unless it is manually executed in the context of a different object)
When a function executes inside of another function (no matter how deeply nested), “this” refers to the object whose context within which it is executed
When you instantiate a constructor function, inside of the instance object, “this” refers to the instance object

So, as you can see, “this” can easily give you a headache. But hang in there; we are getting to the good stuff now.

In a nutshell, in Object-literals, you don’t have local variables; you have properties of the object. So, where inside of the function foo() I might say “var drink = ‘beer’; “, for an object literal called “bar”, I would say “bar.dink = ‘beer’. “ The difference is that “beer” is a property of “bar”, whereas when a function is executing, a local variable is defined by the “var” keyword and cannot be seen by anyone or anything outside of the function.

Example # 1

drink = 'wine';

var foo = {
    drink: "beer",
    getDrink: function(){
        return drink;
    }    
};

console.log( foo.getDrink() ); // wine

drink = 'wine';

var foo = {

drink: "beer",

getDrink: function(){

return drink;

}

};

console.log( foo.getDrink() ); // wine

Here is the jsFiddle.net link for Example # 1: http://jsfiddle.net/Q9RJv/

In Example # 1, we first create a global variable named “drink”, and set it equal to “wine”. We’ll come back to that in a minute.

Next, we create an Object Literal named “foo”, with a property “drink” that is equal to “beer”. There is also a method that simply returns “drink”. But why does it return “wine”, and not “beer”? This is because in the object “foo”, “drink” is a property of foo, not a variable. Inside of functions, when reference is made to a variable, the JavaScript engine searches the scope chain and returns the first match it finds.

Although this function executes in the context of “foo”, “foo” does not have a variable named “drink”. It has a property named “drink”, but not a variable. So the JavaScript engine searches the next level of the scope chain. The next level of the scope chain is the global object, which contains a variable named “drink”, so the value of that variable (“wine”), is returned.

But wait a minute Kevin, how can we make reference to the property “drink” that is in the context of the object “foo”?

I’m glad you asked.

Example # 2

var drink = 'wine';

var foo = {
    drink: "beer",
    getDrink: function(){
        return this.drink; // 'this' refers to the object "foo"
    }    
};

console.log( foo.getDrink() ); // beer

var drink = 'wine';

var foo = {

drink: "beer",

getDrink: function(){

return this.drink; // 'this' refers to the object "foo"

}

};

console.log( foo.getDrink() ); // beer

Here is the jsFiddle.net link for Example # 2: http://jsfiddle.net/HGM93/

In Example # 2, the only change we have made is that in the anonymous function that is assigned to “getDrink”, we return “this.drink” instead of “drink”

This is an important detail. When a function executes in the context of an object , the keyword “this” refers to that object. You can access any of the properties of the object by using the “this” keyword, add new ones (e.g. this.color = “blue”), and change existing ones (e.g. this.drink = “juice).

Using Dot Notation to Create a JavaScript Object Literal

Example # 3

var drink = 'wine';

var foo = {};

foo.drink = "beer";

foo.getDrink = function(){
        return this.drink; // 'this' refers to the object "foo"
    };

console.log( foo.getDrink() ); // beer

var drink = 'wine';

var foo = {};

foo.drink = "beer";

foo.getDrink = function(){

return this.drink; // 'this' refers to the object "foo"

};

console.log( foo.getDrink() ); // beer

Here is the jsFiddle.net link for Example # 3: http://jsfiddle.net/ZA77k/

In Example # 3, we have the exact same functionality as Example # 2. From the JavaScript engine’s perspective, we have achieved the same goal, and the console output is exactly the same.

The difference is how we organized our code. In Example # 2, we created the properties “drink” and “getDrink” at the exact same time that we created the object literal “foo”. It is all one expression. In Example # 3, we create an empty object named “foo” first, and then use dot notation to add properties to the object one-by-one. I just wanted to point out that there is more than one way to go about all of this from a syntax perspective.

Object Literals Can Contain Other Object Literals, and those Objects Have Their Own Context

Example # 4

var drink = 'wine';

var foo = {};

foo.drink = "beer";

foo.getDrink = function(){
        return this.drink; // 'this' refers to the object "foo"
    };

foo.under21 = {};

foo.under21.drink = 'soda';

foo.under21.getDrink = function(){
        return this.drink; // 'this' refers to the object "foo.under21"
    };

console.log( foo.getDrink() ); // beer

console.log( foo.under21.getDrink() ); // soda

var drink = 'wine';

var foo = {};

foo.drink = "beer";

foo.getDrink = function(){

return this.drink; // 'this' refers to the object "foo"

};

foo.under21 = {};

foo.under21.drink = 'soda';

foo.under21.getDrink = function(){

return this.drink; // 'this' refers to the object "foo.under21"

};

console.log( foo.getDrink() ); // beer

console.log( foo.under21.getDrink() ); // soda

Here is the jsFiddle.net link for Example # 4: http://jsfiddle.net/8p38y/

In Example # 4, we have added a new property to “foo”, and that property is yet another object. At first it is empty (i.e. foo.under21 = {}), and then we add two properties to it. The first property is “drink”, which is set equal to “soda”. Don’t’ confuse this with the property “drink” that is set in the context of “foo” which is equal to “beer”. In the context of “foo.under21”, “drink” is equal to “soda”.

The second property of “foo.under21” has an anonymous function assigned to it. That anonymous function returns “this.drink”. In the context of “foo.under21”, “drink” is equal to “soda”, so calling that function returns “soda”.

So the point of this example is that object literals can have properties that are themselves objects, and those objects have their own context. When functions execute in the context of those objects “this” refers to the object, and so on. I am aware of no limit to this kind of object nesting.

The JavaScript .call() and .apply() Methods Allow You to Dynamically Change the Context In Which a Function is Executed

Example # 5

drink = 'wine';

var foo = {};

foo.drink = "beer";

foo.getDrink = function(){      
        return this.drink; // 'this' refers to the object "foo"
    };

foo.under21 = {};

foo.under21.drink = 'soda';

foo.under21.getDrink = function(){
       return foo.getDrink.call(); // execute foo.getDrink()                
    };

console.log( foo.getDrink() ); // beer

console.log( foo.under21.getDrink() ); // wine

drink = 'wine';

var foo = {};

foo.drink = "beer";

foo.getDrink = function(){

return this.drink; // 'this' refers to the object "foo"

};

foo.under21 = {};

foo.under21.drink = 'soda';

foo.under21.getDrink = function(){

return foo.getDrink.call(); // execute foo.getDrink()

};

console.log( foo.getDrink() ); // beer

console.log( foo.under21.getDrink() ); // wine

Here is the jsFiddle.net link for Example # 5: http://jsfiddle.net/A5ydt/

Ok, so here is the bonus question: In Example # 5, why does a call to “foo.under21.getDrink()” now return “wine” ?

This is because we changed the inner-workings of that function. Instead of simply returning “this.drink”, we use the JavaScript “.call()” method, which allows you to execute any function in the context of another object. When you do not specify the context in which that function is to be “called”, it executes in the context of the global object. In the global context, there is a variable named “drink” and it is equal to “wine”, so “wine” is returned.

Example # 6:

drink = 'wine';

var foo = {};

foo.drink = "beer";

foo.getDrink = function(){      
        return this.drink; // 'this' refers to the object "foo"
    };

foo.under21 = {};

foo.under21.drink = 'soda';

foo.under21.getDrink = function(){
       return foo.getDrink.call(this); // execute foo.getDrink()                
    };

console.log( foo.getDrink() ); // beer

console.log( foo.under21.getDrink() ); // soda

drink = 'wine';

var foo = {};

foo.drink = "beer";

foo.getDrink = function(){

return this.drink; // 'this' refers to the object "foo"

};

foo.under21 = {};

foo.under21.drink = 'soda';

foo.under21.getDrink = function(){

return foo.getDrink.call(this); // execute foo.getDrink()

};

console.log( foo.getDrink() ); // beer

console.log( foo.under21.getDrink() ); // soda

Here is the jsFiddle.net link for Example # 6: http://jsfiddle.net/cS4cv/

In Example # 6, “soda” is returned because when we used the JavaScript “.call()” method, we specified the context in which the function is to execute. In this case, the context we specify is “this”. “this” refers to the context of “foo.under21”, and “foo.under21” has a property named “drink”, so the value “soda” is returned.

Summary

The last two examples may seem like overkill, but I wanted to point out that just when you start to get a handle on the concept of context in JavaScript object literals, you must realize that there is a bit more to consider. JavaScript Object Literals can have properties that are also objects, and those objects have their own context.

In each case, when a function executes within that context, inside of the function, the “this” keyword refers to the object that the function is a property of, because the function executes in the context of that object. By using the JavaScript “.call()” method (or “.apply()” method), you can programmatically change the context in which that function executes, which changes the meaning of the “this” accordingly.

Aug202012 by dcm2 Comments

Understanding Scope in JavaScript

JavaScript

Although the ‘with’ statement creates a block-level scope effect, and recent implementations of the “let” statement have the same effect, these are fodder for another conversation. I’m not a big fan of the “with” statement, and at the time of this writing, you can’t be 100% sure that the “let” statement is fully supported by the user’s browser. The end result of this is the fact that there is no block-level scope in JavaScript. Scope is created by functions.

Example # 1

month = 'july'; //global variable

function foo(){
    var month = "august"; //private
    console.log(month);

};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

month = 'july'; //global variable

function foo(){

var month = "august"; //private

console.log(month);

};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

Here is the jsFiddle.net link for Example # 1 : http://jsfiddle.net/2ZkkR/

In Example # 1, we set the global variable “month” equal to “july”. But inside of the function “foo()”, we also create a variable named “month”, and give it a value of “august”. The second statement in foo() is a call to the console, telling it to output the value of the variable “month”.

So, why is it that in the global scope, “console.log(month)” outputs “july”, but executing “foo()” outputs “august” ?

The reason is that inside of the function “foo()”, we used the “var” keyword to create the variable “month”. When you use the “var” keyword, the variable you create becomes local to the function that you create it in. So, inside of “foo()”, the variable “month” is local, and equal to “july”. As a result, on the very next line, the statement: “console.log(month)” outputs “july”. Inside of “foo()”, we have no knowledge of the global variable “month”, because in the scope chain, the variable “month” is found locally, so the search for “month” ends within the local scope of “foo()”.

Example # 2

month = 'july'; //global variable

function foo(){
    var month = "august"; //private
    console.log(month);
};

function bar(){
    console.log(month); //no local "month", so it looks to the global "month"
};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

bar(); //in the local scope of the bar function, month = july

month = 'july'; //global variable

function foo(){

var month = "august"; //private

console.log(month);

};

function bar(){

console.log(month); //no local "month", so it looks to the global "month"

};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

bar(); //in the local scope of the bar function, month = july

Here is the jsFiddle.net link for Example # 2 : http://jsfiddle.net/6TBEM/

In Example # 2, we have added a function named “bar()”. Bar does not have a local variable named “month”. So, when “bar()” executes, the statement “console.log(month)” kicks off a search for the variable “month”. In the scope chain, there is no local variable named “month”, so the JavaScript engine looks to the next level of the scope chain, which happens to be the global scope. In the global scope, there is a variable named “month”, so the value of that variable is returned, and it is “july”.

So, “foo()” outputs: “august” and “bar()” outputs: “july”, because, although they both look for a variable named “month”, they find completely different values; in their respective scope chains, the value of a variable named “month” differs.

Example # 3

month = 'july'; //global variable

function foo(){
    var month = "august"; //private
    window.season = 'summer'; //global    
    console.log(month);
};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

console.log(season); //in the global scope, season = summer

month = 'july'; //global variable

function foo(){

var month = "august"; //private

window.season = 'summer'; //global

console.log(month);

};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

console.log(season); //in the global scope, season = summer

Here is the jsFiddle.net link for Example # 3 : http://jsfiddle.net/ZaXxk/

In Example # 3, notice a new statement in the “foo()” function: “window.season”.

In this statement, we are creating a global variable named “season”. Although we are within the context of the “foo()” function, we can reference the global scope by mutating the “window” object. “window” is essentially the global object. Creating a global variable while inside of the local scope of “foo()” is easily done by adding a property to the “window” object; in our case we name it “season” and give it a value of “summer”.

So once again, although we are in the local scope of “foo()”, we have just created a global variable named “season” and given it the value of “summer”, by adding a new property to the “window” object (e.g., window.season = ‘summer’).

Example # 4

month = 'july'; //global variable

function foo(){
    var month = "august"; //private
    window.season = 'summer'; //global
    weather = 'hot'; //global    
    console.log(month);
};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

console.log(season); //in the global scope, season = summer

console.log(weather); //in the global scope, weather = hot

month = 'july'; //global variable

function foo(){

var month = "august"; //private

window.season = 'summer'; //global

weather = 'hot'; //global

console.log(month);

};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

console.log(season); //in the global scope, season = summer

console.log(weather); //in the global scope, weather = hot

Here is the jsFiddle.net link for Example # 4 : http://jsfiddle.net/XYu4x/

In Example # 4, we create another global variable while within the local scope of “foo()”, named “weather”. This approach is different because when we say: weather = “hot”, the absence of the “var” keyword automatically makes the variable global. This is important to remember and make note of: If you omit the “var” keyword when creating a variable, no matter where you do it, that variable becomes global.

In general, this is something that you want to avoid, as it can lead to code that is hard to understand and even harder to maintain. But for the purpose of this discussion, it illustrates an important behavior in JavaScript: omitting the “var” keyword when creating a variable makes that variable global, no matter where you do it. I’m repeating this because it is an important detail to remember.

Example # 5

month = 'july'; //global variable

function foo(){
    var month = "august"; //private
    window.season = 'summer'; //global
    weather = 'hot'; //global    
    this.activity = 'swimming' //global
    console.log(month);
};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

console.log(season); //in the global scope, season = summer

console.log(weather); //in the global scope, weather = hot

console.log(activity); //in the global scope, activity = swimming

month = 'july'; //global variable

function foo(){

var month = "august"; //private

window.season = 'summer'; //global

weather = 'hot'; //global

this.activity = 'swimming' //global

console.log(month);

};

console.log(month); //in the global scope, month = july

foo(); //in the local scope of the foo function, month = august

console.log(season); //in the global scope, season = summer

console.log(weather); //in the global scope, weather = hot

console.log(activity); //in the global scope, activity = swimming

Here is the jsFiddle.net link for Example # 5 : http://jsfiddle.net/NTjYe/

In Example # 5, we yet again create a new global variable from within the local scope of “foo()”. This variable is named “activity”. We demonstrate yet another way in which you can do this by saying: this.activity = ‘swimming’. This introduces another concept: the meaning of “this” inside a function (no pun intended).

Inside a function, the “this” keyword refers to the context in which the function is executed. In our example, “foo()” is executed in the context of the global object, so “this” referes to the global object, which means that “this.activity” adds a property to the global object named “activity”.

Make note: While “foo()” has it’s own “local” scope, the keyword “this” refers to the context in which “foo()” is executed. This is another important detail to remember. It will come up a lot when writing more advanced JavaScript.

Another (very) important note: An “implied global” is what occurs when you omit the “var” keyword when declaring a variable. There is a subtle, yet important difference between that and a variable created using the “var” keyword in the global scope: an implied global is actually not a variable; it is a property of the “window” object. For the most part, it behaves very much like a global variable, but there are differences: for example, you cannot delete a global variable, but you can delete a property of the window object. This is a topic worth looking into when you have time, and at minmum, good to be aware of.

Summary

At first, the concept of scope in JavaScript can be a challenge to fully understand. But it is very much worth the effort. Once you understand scope, the JavaScript language becomes a sharp knife that can be used to sculpt elegant and expressive code. This tutorial discussed only the most basic concept of scope in JavaScript. I highly recommend exploring it in-depth.

Helpful Links for Scope in JavaScript

https://developer.mozilla.org/en/JavaScript/Reference/Functions_and_function_scope/

http://coding.smashingmagazine.com/2009/08/01/what-you-need-to-know-about-javascript-scope/

http://oranlooney.com/function-scope-javascript/

Gracefully handling corner cases is the key to writing more robust, error-free JavaScript.

Example # 1A

Example # 1B

Example # 2

Example # 3

Summary

You have an anchor tag, the href is a “mailto”, but what if you can’t have the hyper link follow?

Sometimes “return false” is not enough; you need to prevent the event from bubbling up the DOM

Decent programmers tests their code before deploying it. In JavaScript development, this usually means viewing the web page that your code interacts with, and clicking one or more elements in the page to ensure that the desired result is achieved

jQuery QUnit

Learn How to Build a Social Media Plugin, Using Require.js and the Asynchronous Module Definition (AMD) Pattern

Helpful Links for Require.js and Asynchronous Module Definition (AMD)

Require.js

Asynchronous Module Definition (AMD)

Nested success callbacks are messy business. The jQuery Promise interface provides a simple and elegant solution.

The jqXHR object

Here is a link to the working code for Example # 1: http://examples.kevinchisholm.com/jquery/promise/promise-and-ajax-beginner/example-1.html

Here is a link to this article’s full working example: http://examples.kevinchisholm.com/jquery/promise/promise-and-ajax-beginner/example-2.html

Summary

Helpful Links for the jQuery Deferred, jQuery Promise and jqXHR Objects

jQuery Deferred

jQuery Promise

jQuery jqXHR

Step beyond the basics, and learn how Require.js modules can return various kind of values, depend on other modules, and keep those dependencies transparent to the outside world

Once again, here is the full working example for this article:

Helpful Links for Require.js and Asynchronous Module Definition

Require.js

Asynchronous Module Definition

jQuery’s two .each() methods are similar in nature, but differ in level of functionality

jQuery().each()

Here is the JSFiddle Link for Example # 1.A: http://jsfiddle.net/wcRmd/

Here is the JSFiddle Link for Example # 1.B: http://jsfiddle.net/9C8He/

jQuery.each()

Here is the JSFiddle Link for Example # 2.A: http://jsbin.com/epanov/1/edit

Here is the JSFiddle Link for Example # 2.B: http://jsbin.com/examuz/1/edit

Here is the JSFiddle Link for Example # 2.C: http://jsfiddle.net/XjxvZ/

Summary

Helpful Links for jQuery().each() and jQuery.each()

jQuery().each()

jQuery.each()

Learn how to decouple your code and organize it into reusable modules

The working example for this article can be found here: http://examples.kevinchisholm.com/javascript/requirejs/part-i/

The jQuery.each() method makes it trivial to iterate over or inspect any kind of collection: arrays, objects, array-like objects, even jQuery DOM Objects.

Example # 1

Here is a JSBin link for Example # 1: http://jsbin.com/epanov/1/edit

Example # 2

Here is a JSBin link for Example # 2: http://jsbin.com/epezuc/1/edit

Example # 3

Here is a JSBin link for Example # 3: http://jsbin.com/okoxej/1/edit

Example # 4

Here is a JSBin link for Example # 4: http://jsbin.com/usewoj/1/edit

Example # 5

Here is a JSBin link for Example # 5: http://jsbin.com/examuz/1/edit

Example # 6

Here is a JSFiddle link for Example # 6: http://jsfiddle.net/n7PRD/

Example # 7

Here is a JSBin link for Example # 7: http://jsbin.com/iriwer/1/edit

Summary

Helpful Links for the jQuery.each() Method.

Understanding the basic components of an AJAX request / response, and being able to write it all out by hand is an important skill for any JavaScript developer to have.

The XMLHttpRequest Object

Determining Support for the XMLHttpRequest object

Example # 1

The onreadystatechange Event

The status Property

Opening the XMLHttpRequest Object’s Request

Sending the XMLHttpRequest Object’s Request

Server Code

Example # 2

Here is a link to the full working page for this article’s example:

Summary

Helpful Links for hand-coded AJAX

Callbacks are a critical tool for properly handling asynchronous events in JavaScript.

Here is a JSFiddle link for Example # 1: http://jsfiddle.net/CZeLv/

Here is a JSFiddle link for Example # 2: http://jsfiddle.net/dfCM2/

Here is a JSFiddle link for Example # 3: http://jsfiddle.net/fAn4g/

Summary

Helpful Links for JavaScript Callback Functions

Once you have jQuery plugin basics down, it’s time to implement some best practices

Protecting the Dollar Sign