Patterns of JavaScript modules in Impress for node.js and browsers

I got the impression that there is still a prejudice in society against the use of global variables for official purposes. In this regard, I want to give some explanations with examples that will remove any doubts and will be useful to everyone who is eager for modularity and flexibility in JavaScript development . I can not trace the sources of all the ideas below, but I do not claim their authorship, but only a creative synthesis. I also refuse to claim one universal pattern of definition of modules for all occasions, I hope it is clear to everyone that this can never happen. All of this is significantly different from the requirements of RequireJS, CommonJS, and how modules are created in node.js via module.exports, however, each of these patterns has its place, if you approach the task without fanaticism and prejudice .

Special features

• Support for private and public methods and properties.
• The pattern is applicable for both server-side JavaScript and client-side . For both client and server JS modules can be loaded dynamically, as in Require.js (AMD).
• Gluing of several files containing code of different modules into one file is supported, it allows optimizing js loading for browsers, minifying and sticking into one file. I note that Asynchronous module definition (AMD) and CommonJS have the ideology of "one module - one file." Although there is a means of merging into one file, but when merging, the basic meaning of asynchronous module loading is lost.
• It is possible to divide the code of one module into several files that are loaded sequentially and complement each other. This is useful, for example, for putting constants, configurations into separate files.
• Due to the division into several files, it is possible to make modules with extensible functionality , i.e. make modules, bringing into them the functionality that is needed only in some cases and load it by condition.
• It is possible to make an interface and implementation by defining the same methods in several different sub-modules. This needs to be clarified in more detail, using an example: you need to store the tree data structure in browser storages (localstorage, WebSQL, IndexedDB), and they must have the same interface and a part of the logic the same. Create treeStorage.js, treeStorage.localstorage.js, treeStorage.websql.js, treeStorage.indexeddb.js
• It is possible to hide some loadable methods and properties in a wrapper method and call it optionally or load several implementations with wrapped methods at once and switch between them, causing wrappers with different names by condition.
• For Impress, it is important that the modules fall into the global namespace and are accessible from all handlers, without the need to connect them in each handler separately.

Code

// File: global.js //     if (typeof(window) != 'undefined') window.global = window; Function.prototype.override = function(fn) { var superFunction = this; return function() { this.inherited = superFunction; return fn.apply(this, arguments); } } 

')

 // File: moduleName.js //    moduleName (,    ) (function(moduleName) { //     console.log(' moduleName'); moduleName.publicProperty = '  '; var privateProperty = '  '; moduleName.publicMethod = function() { console.log(' publicMethod  moduleName'); }; moduleName.toBeOverridden = function() { console.log('   toBeOverriden   moduleName ( )'); }; var privateMethod = function() { console.log('  privateMethod  moduleName'); }; } (global.moduleName = global.moduleName || {})); 

 // File: moduleName.implementationName.js //    moduleName  ,      (function(moduleName) { //        console.log(' implementationName'); //      //       // moduleName.publicProperty = '  '; //      //        // var privateProperty = '   '; moduleName.publicMethod = function() { //      //       console.log('  '); }; var privateMethod = function() { console.log('   '); }; //    "Function.override" // moduleName.toBeOverridden = moduleName.toBeOverridden.override(function() { console.log(' : moduleName.toBeOverridden'); this.inherited(); //     }); //   ,     //  -         // moduleName.wrapperName = function() { //      console.log('   '); moduleName.publicMethod = moduleName.publicMethod.override(function() { console.log(' : moduleName.publicMethod'); }); }; } (global.moduleName = global.moduleName || {})); 

 // File: test.js require('./global.js'); require('./moduleName.js'); require('./moduleName.implementationName.js'); moduleName.wrapperName(); moduleName.publicMethod(); 

How this template is used in Impress

1. Rendering configuration: impress.constants.js removed from impress.js
2. Submodules : db.mongodb.js extends db.js
3. Since all handlers and Impress are in separate files , then handlers do not need to write require. But the handlers themselves are defined using the usual method for node.js, i.e. via module.exports.
Example:

 module.exports = function(req, res, callback) { res.context.data = []; db.impress.sessions.find({}).toArray(function(err, nodes) { res.context.data = nodes; callback(); }); } 

Links

Global.js with comments in Russian and English on Github: github.com/tshemsedinov/global.js
Impress on Github: https://github.com/tshemsedinov/impress
Impress npm: https://npmjs.org/package/impress

Ps. I express my deep gratitude to tblasv , who found a mistake in the private method.