Hello and welcome to part 2 of the first of the three weekly lessons about Oracle JET.
In the first part your were introduced to the ideas behind JET.
A central problem in JavaScript is related to the absence of modularity, as well as the
absence of built-in file-loading mechanisms.
While the JavaScript ecosystem continues to innovate, with new features and libraries
popping up continually, there have for a long time not been any built-in solutions in JavaScript
to solve this specific set of problems.
That's why in the context of Oracle JET, we need to look at including an external library
in our toolkit to help to solve this problem.
In the JavaScript ecosystem, a number of modularity solutions are available.
At the time that JET was being developed, Require.js was the most popular and most stable
solution in this area.
In the meantime, a number of other modularity solutions have been developed, including Browserify
and SystemJS, as well as the native module system that is part of ECMAScript 6.
For JET, the decision has explicitly been made to not necessarily choose the newest
solutions as part of JET.
Instead, the approach is to prefer the stability of a technology over its newness.
In that light, Require.js fits the bill perfectly.
It has been around for quite some time, it does exactly what it needs to do for the purposes
of JET, and when one of the other solutions becomes more stable, and more applicable to
JET, we'll be able to replace Require.js with something different.
That's the way we have built up JET, benefiting from the modular architecture that enables
individual libraries and technologies to be replaced as needed.
Let's now look specifically at Require.js.
You will see that we are able to delegate the loading of files to Require.js.
Require.js also lets you build applications using modules, specifically using a module
format called Asynchronous Module Definition, known as AMD.
Every Oracle JET application is structured in the same way.
You do all your work in the 'src' folder.
Inside the 'src' folder, you will find the "index.html" file.
Right at the end of the index file, you will see a reference to Require.js, so this is
where Require.js is loaded into the application, and you will also see a reference to "main.js".
"main.js" is the entry point into the application; what it provides most importantly of all is
what is called a "require block".
A "require block" is a Require.js construct that provides the entry point into the application.
If you're from a Java background, you will be familiar with the "public static void main"
constructor, in a Java desktop application; this is the equivalent of that.
You see here a "require block" and you see a number of modules being referenced here.
These are modules and components that are inside of the Oracle JET application, that
are being loaded at start up of the application.
In addition to one single "require block", you will find in the "viewModels" folder a
"define" block for each of the modules in the application.
You can see that, by default, there are 4 modules in the application, each beginning
with a "define statement".
Every Oracle JET application has multiple "define blocks", in other words, multiple
different modules, and one single "require block".
One single "require block", always found within the "main.js" file, which is always loaded
by means of the index file.
Via the lazy loading strategy that Require.js provides, only the modules that you specify
in the "define block" are loaded by that specific module.
You have now learned the basics of Require.js.
Require.js helps you by letting you delegate file loading, while also letting you construct
modular applications.
In the next part, you will learn some more advanced Require.js techniques.
In particular, you will learn how to set up and work with configuration files in Require.js,
which will allow you to lazy load JavaScript resources, when working with Oracle JET applications.
In the homework for this part, spend some time going over the requirejs.org website.