Course info
Jan 13, 2015
1h 57m

This course introduces RequireJS, a module loader and dependency injection framework for JavaScript. In this course, we will learn how to use RequireJS to better organize our code into separate modules. We will then use the r.js tool to optimize our code before releasing to production.

About the author
About the author

Jeff has over 15 years of experience in software development using Java, C#, JavaScript, CoffeeScript, and TypeScript. His belief that clean, well organized code is key to making software maintainable has led him to focus on unit testing and solid programming practices and principles as a cornerstone of everyday coding.

More from the author
Creating JavaScript Modules with Browserify
1h 13m
Apr 9, 2015
Section Introduction Transcripts
Section Introduction Transcripts

Defining and Requiring Modules
In this module, we will discuss defining and requiring modules in our JavaScript. Modules are the building blocks of RequireJS, and modules can depend on other modules, which makes up our dependency hierarchy. We will also learn about the require and define functions that are provided by RequireJS. We'll then introduce the Asynchronous Module Definition, also known as simply AMD, CommonJS, and Some common module design patterns used in JavaScript that fit nicely with our modules. We'll do this by continuing to refactor our sample task list web application. If you'd like to follow along, the source code for the sample application that I'm working with in this module is available in the course materials on Pluralsight. com. So, let's get started.

Loading Remote Modules
In this module, we will continue to refactor our to-do list application by moving all of our RequireJS AMD modules to separate files. We will then look at some performance implications of this approach and begin to see what we can do to eliminate these issues. Up until this point, we have been working in one large main. js file making it bigger and bigger as we need to add new modules. When developing a real application, you would typically not do this as it would make your code bulky and hard to read, which is one of the original problems we were trying to get away from when using RequireJS. Instead, we want to be able to put each of our AMD modules, which each deal with a single responsibility, into its own file. This lets us organize things nicely in our project during development. Let's begin by looking at our existing sample project.

In the previous module, we separated our code into multiple files and used subdirectories to organize our code to make it easier to read and maintain. This had great development time benefits because we can have smaller files, avoid spaghetti code, and respect the single responsibility and dependency inversion principles. However, this caused a runtime issue for the end user because each file now has to be loaded from the server. This caused more requests to the server and increased the load time of the client. In this module, we will finally find the right balance between deployment ease and runtime efficiency by using the RequireJS optimizer named r. js to eliminate this problem. The desired outcome of this optimization step is to take all of our individual files, main. js, tasks. js, etc. , and combine them into a single file, main-optimized. js. This will reduce the number of server requests the browser has to make. We then want our file to be minified, which will reduce the overall size of the file that needs to be transferred. To accomplish this, we are going to need to set up a build environment for our project.

Unit Testing RequireJS Modules
In this module, we will discuss unit testing of our AMD modules and how RequireJS plays into testing. In general, the nice thing about breaking our code into smaller modules and using a dependency injection framework like Require is that it makes our code more testable. We now have smaller units to test and can inject mocks to test with. However, use of Require actually significantly complicates unit testing. This is due to two issues. First is that module loading is asynchronous, so we need to use a test framework that can deal with asynchronous testing. Second is that Require caches loaded modules. This means that when a module is loaded for one test, the modules will still be cached in Require for the next test. But, don't worry too much about this yet. We'll get to that later. First, let's go over some unit testing basics and set up a test environment.