We've described the semantic structure of our application with HTML. We have defined with CSS how our UI elements shall look. Now, we will teach our application to retrieve and update the content as well as to respond to user events. Actually, we will allocate the following tasks to several modules:
- DirService: This provides control on directory navigation
- FileService: This handles file operations
- FileListView: This updates the file list with the data received from DirService, handles user events (open file, delete file, and so on) using FileService
- DirListView: This updates the directory list with the data received from DirService and handles navigation events using DirService
- TitleBarPath: This updates the current location with the path received from DirService
- TitleBarActions: This handles user iteration with title bar buttons
- LangSelector: This handles user iteration with language selector
However, before we start coding, let's see what we have in our arsenal.
NW.js gets distributed together with the latest stable version of Node.js, which has a great support for ES2015/ES2016 (http://node.green). It means that we can use any of the inherent new JavaScript features, but modules (http://bit.ly/2moblwB). Node.js has its own CommonJS-compliant module loading system. When we request a module by path, for example, require( "./foo" ), the runtime searches for a corresponding file (foo.js, foo.json, or foo.node) or a directory (./foo/index.js). Then, Node.js evaluates the module code and returns the exported type.
For example, we can create a module that exports a string:
./foo.js
console.log( "foo runs" );
exports.message = "foo's export";
and another one, which imports from the first module:
./bar.js
const foo = require( "./foo" );
console.log( foo.message );
If we run it, we get the following:
$node bar.js
foo runs
foo's export
One should note here that regardless of how many times we require a module, it gets executed just once, and every time, its exports are taken from the cache.