Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
FREELessons:16Length:1.8 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

2.4 Specifying Configuration

There are several different ways that we can specify configuration options for our application, and several configuration options that we'll often want to use. In this lesson we'll explore the configuration options available and see how to set them.

2.4 Specifying Configuration

Hey there. In this lesson, we're going to look at how we can configure require JS. It comes with a lot of different configuration options, making it extremely flexible. The great thing is that we can very easily create different configurations that can be used in different situations. Such as using one configuration for development, another for production and yet another for our tests. There are a number of different ways of specifying configurations for require and it's very common to need to configurate, so it's best to get it sorted out early in the project. Yeoman generators that work with require invariably gets a lot of the basic configuration options set up for us automatically, but it's useful to understand how to provide configuration manually when necessary. One way that we can supply configuration for require js is using an inline script in the html page before the script that loads require. So we would do that like this. [BLANK_AUDIO] All we need to do is create a variable called require and set any of the configurable properties that we need to set. Require will automatically use this configuration. So let's run the page in the browser now briefly. And we'll open up the console and here we see a script error. This script error is a foyer full because our module can't be found. Because we configured require to set the base url to the external directory and our main js bootstrapper. Doesn't sit in the external folder. So this is our intentional error this time. What i wanted to show you is that when we set the base URL property in configuration. It overrides the data main attribute. So let's go back to the ID now. So this way of providing configuration using a script element inside our index.HTML page. Is useful for when we want the configuration to apply just to the HTML page that is currently running the code. So, we can have one HTML page for developing and another for the unit test and have each file specify its own configuration. So, we're not gonna use this configuration now let's just get rid of it again. Another thing we can do is create the configuration in a completely separate file. So let's create a basic configuration file. It can go into the SRC folder along with our modules. We'll call it config.js. [BLANK_AUDIO] So, this time we can use the config method to set the configuration. This method is a property of the global Require object. [BLANK_AUDIO] So we pass the config method an object literal, and this is where we specify the different configuration options. So let's incorrectly set the base URL to the external directory one more time. [BLANK_AUDIO] And let's go back to the HTML page. So this time, we can get rid of the data main attribute from the script elements and we can load the config as a traditional script as well. So here we;re just loading the config in the usual non asynch traditional way. So let's go back to the browser now. And when I refresh the page we should still have this exact same error. So it's saying that requirer is not defined. And we just need to load the main js file as well. And both of these scripts should actually come after the require js scripts, otherwise we'll see the same error that we saw before. [BLANK_AUDIO] So now it goes back to the 404 error. So it can't find our task manage module because the module is not in the external directory. Great. So this way of specifying configuration is useful if we want to share a single configuration file between multiple pages. But, it has the overhead of the extra script tags. We can improve things slightly with another configuration option. So, let us remove the script tag for main JS. And we can set the base URL correctly in our configuration. And now we can add a new configuration option called depths. So the depths option if useful for specifying dependencies and in this case the dependency that we need to specify is our main J.S. Boot java script. So now that we've set the base URL correctly, all of our modules or other scripts that get loaded, such as the boot strapper, will be relative to the base URL. So we don't need to specify the full path domain because main is already inside the base URL directory. So the deps option allows us to specify dependencies that should be loaded as soon as the require method has been defined and is an array. We can specify our bootstrapping main module as the dependency, so let's go back to the browser now. And we go back to seeing our task in the console. So this is better, but we're still loading the config itself as a regular script file. The last way that we can specify config is by loading the configuration file itself as a module. So we can do this by removing the script tag that loads the config and setting the config as the data main attribute on the require script. [BLANK_AUDIO] So that's it. No other changes are required. And everything is still working as it did before. So this last way of specifying configuration is most useful in most situations. This way also works with the require JS Optimizer, R JS, which we'll look at in more detail towards the end of the course. So we've seen the base URL in deps options so far. We'll also be using other options as and when we need to in later lessons. But let's look at a few of these options now. One option is used with deps, one of the options we've set. This is the callback option, which is used to provide a callback function that is executed once all of the dependencies specified in the depths array have loaded. The paths option can be used to map paths to modules, to different paths. This is another option that can be useful for testing, because we can use it to very easily load mocks in our tests instead of the actual dependent modules to make unit testing more precise. The shim option is another very useful and commonly used option. We can use it to load older scripts that don't code-define as if they were properly defined AMD modules. One option that we might want to set is the enforce define option. Which enforces the rule that every module should either use the define method or set an export value using the shim option. This does mean we'll need to update our bootstrapper, so let's set this option now quickly. [BLANK_AUDIO] So this option is disabled by default but we probably want to enable it in most situations because it helps debugging in the ie a lot. So it's recommended to set the option to true. So if we go back to the browser now. We see an error that there is no define call in our configuration and no define call in main. So let's just fix that quickly. In both of these modules, all we need to do is call the define method. [BLANK_AUDIO] And now everything goes back to how it was before. So in this lesson we looked at how we can create configuration for RequireJS that we can load in a variety of different ways. We can either use in-line script tags or traditional script tags with an SRC attribute, both of which can be useful for development or test situations. We also saw that using the config as a module is possible, and is useful for when we're working with the optimizer. We also took a quick look at some of the different configuration options that we can use, including the base URL option which specifies the root directory that all modules are loaded from. And the deps option which we can use to specify an array of dependencies that should be loaded once the config is loaded. Lastly, we looked at some other common options like paths, shim and enforceDefine. Thanks for watching.

Back to the top