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.
Optimization 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.