Modularity in node. js

Write an article every day to record your own growth. Sophomore, it's time to meditate. Cheer Up ~

All right, nonsense, talk about the modularity in Nodejs today. (Note: This article for oneself to the book Nodejs actual combat summary)

One important feature of Nodejs is modularity, which is how node. js groups common functions. Furthermore, node does not need to really discern whether the module was written by ourselves or taken from an external repository. So we just need an extra JSON document and one or two lines of code, and we can refer to someone else's code or someone else to quote our code, isn't it cool ~.

OK, let's write a simple module:

function () {    console.log ("Hello World");}

We use the Mymodule.js file to save this code, the exports object is a special object that is created by node's file system in each file we create, and when we reference the module, it is returned as the value of the Require function. It is encapsulated in the module object of each block, used to expose a function, variable, or class. The method of using the module is also very simple, the code is as follows:

var mm = require ('./mymodule '); Mm.hello_world ();

This allows us to expose any functions and classes we want to expose by exports objects. When we frequently return objects from the module, we have two core patterns to use:

The first is our factory model, see the following section of code:

functionHello (lang) { This. Language =Lang;  This. Greet () =function(){        Switch( This. Language) {             Case"EN":return"Hello1"; Break;  Case"De":return"Hello2"; Break;  Case"JP":return"Hello3"; Break; default:return"No Speaka that language"; Break; }    }}//Now we use the Factory mode to return an instance of our Hello classExports.create_hello =function(lang) {return NewHello (lang);}

View Code

Something about this pattern is that the module can expose other functions and classes through the exports object.

The second pattern is the constructor pattern, which is the direct mode, and now our function is the same as the constructor code:

Module.exports = Hello;

Note that we should change the code when we use it:

var hello = require ("./mymodule"); var lang = "en"; var New hello (lang); Obj.greet ();

But remember here, the only real thing we're exposing is the constructor of a class. This is very close to our object-oriented thinking, but one drawback is that we can't let the module expose more things. So we often use our factory model.

On the difference between exports and module.exports, let's see this website: https://cnodejs.org/topic/52308842101e574521c16e06.

We know we want to introduce modules into a file we just need to use the Require function, and note that the modules we introduce are proprietary to the modules they are introduced to. If A.js loads the HTTP module, then b.js cannot load the module unless B also introduces an HTTP module.

Let's look at how node. js looks for modules, but the rules are simple:

1. When a built-in module (such as HTTP and FS) is requested, node uses these modules directly

2. When the requested module is a path character such as./. //) At the beginning, node will find the specified directory and load him, and if the. js extension is not specified in the module name, then node will first look for a module based on the folder with the same name, and if not found, he will add the extension. js. JSON and. node, and try to load these modules at once (modules with the node extension are compiled into additional modules)

3. If there is no path character, node looks for the module under the Node_modules/subfolder of the current folder. If found, the module is loaded, otherwise, node will look for the mode_modules/folder in its own way under the path tree in its current location, and if it fails, he will search under some default addresses, such as the/usr/lib and/usr/local/lib folders.

4. Throws an error if it is not found.

We used to be able to refer to a file in a dead loop when referencing a file, but not in node. For example, I introduced B.js in A.js, introduced A.js in B.js, introduced Main.js in A.js, the order of execution in node is to load Main.js first, then run Introducing A.js, and then introducing B.js, then node detects the loop and returns an object pointing to A.js, but no longer executes the code.

We know that every file in node. js is a module that contains modules and exports objects, which can also be complex: contains a directory to hold the contents of the module and a file containing the package information. If we want to write a series of supporting files and break the functionality of the module into multiple JS files, even the unit tests, then we can write:

1. Create a folder to hold the contents of the module

2. Add a file named Package.json to the folder. The file contains at least the name of the current module and a primary JS file (used to start loading the module)

3. If node does not find the Package.json file or does not specify a main JS file, then he will look for index.js (or a compiled add-on module Index.node)

Of course, the contents of the module more than a little bit, the rest of the later to add it.

Modularity in node. js