3.1 Using Non-AMD Scripts With RequireJS

Hi folks. In this lesson we're going to look at an important feature of RequireJS. One which we'll use frequently, and which requires a little configuration. We're going to see how we can load non-AMD scripts as if they were AMD modules. One of Require's configuration options we can make of use of at this point is the paths option. By default, the file name for Knockout includes the version number. Which is useful, but means that we'll have to use it whenever we reference Knockout in one of our modules. Plus, Knockout is in the external directory, so we need to include a slightly longer path whenever we want to use it. So we can use the paths option to set a friendlier name that we can use to reference the module by. Let's add it to our config. [BLANK_AUDIO] The path we add creates a short alias if just knockout, which refers to the full path and file name of the source file. So when we want to use Knockout in a module, we can use the short path. So the script that we'll want to use which isn't an AMD module is called Smoke Signals and is a tiny little event-emitting microlibrary. We'll want our modules to be able to communicate without having to have every module require every other module, so we can just have our modules emit events. We can download it from Bitbucket. [BLANK_AUDIO] Let's grab the source file. [BLANK_AUDIO] And we can save this straight into the external directory. [BLANK_AUDIO] So this script doesn't call the define method, and it adds a global which is used to interact with the framework. One of the ideas behind RequireJS is that we don't make use of any globals except require and define. So in order to load the framework as if it were a module, we need to use the shim configuration property. Let's take a look. Like the paths option that we looked at just a minute ago, the shim option takes an object. [BLANK_AUDIO] Each key in the object sets the name that we'll use to specify the script when used in a dependency array inside another module. We'll call it smokesignals. [BLANK_AUDIO] And the value of this is another object. We can use this object to set other options for how this external framework is used. The only option that we need to set is exports. [BLANK_AUDIO] This tells Require what the name of the global that the framework sets is called. So Require will be able to grab this global and pass it into our modules whenever we want to make use of smoke signals. And that way we don't have to actually make use of the global that it creates ourselves directly. Other options that we can set for non-AMD modules are deps, which takes an array of dependencies that should be loaded before the script. And init, which takes a function to invoke once the script is loaded. We don't need to use either of these today. We can also add a paths entry for the script, just like we did with knockout. [BLANK_AUDIO] So this is optional. It just means that we have to type less if we use the script in more than one module. So now inside another module, we should now find that we can specify this script as a dependency. So let's just use our main js bootstrapper for now. [BLANK_AUDIO] So there is still a global called smokesignals, we just don't have to use it. We'll used the value passed into our callback function instead, which will always be available when we want to use it. The global may or may not always be there, depending on whether our asynchronous modules load before it, which is a real possibility. Instead of logging the task, let's just log the smokesignals framework, and make sure that it's available for us to use. [BLANK_AUDIO] And let's run the page in the browser again. [BLANK_AUDIO] And we can see the smoke signals object so let's just inspect it briefly. And we can see that it contains a convert method, and we'll want to make use of that later on. This tells us that everything is working as we expect. So we'll need some view models that we can use to bind the data from our app to our views. So let's create a new folder in the SRC folder. We'll call it view models. [BLANK_AUDIO] And then inside of this we can create three new scripts. So the first one we can call app. [BLANK_AUDIO] And we can create a list view model, and lastly, we can create a task view model. [BLANK_AUDIO] So we can fill out the view models as and where we need to. For now, let's just add the calls to define to them. [BLANK_AUDIO] We'll come back to these later on once we start to wire up our app more fully. So in this lesson we saw how to load scripts that are not defined as AMD modules and which do not call the define method. We looked at two additional configuration options. The paths option which allows us to set short, friendly names for paths to modules outside of the base directory. And the shim option, which is what we use to load non-AMD scripts as if they were modules. We saw that at a minimum, we should provide an export value for the non-AMD script that we want to use. But that optionally, we can also specify dependencies and init callback. Thanks for watching.