Getting Started with Require.js Part II

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.