Before diving into the details, let us first figure out what a module is. In short, a module is a piece of code. In order to share and reuse, we need to group the code. Through modules, we can decompose complex applications into small pieces of code. At the same time, modules can also help us understand the intent of the program code and find or fix various errors.
Set up the app:
The above code snippet shows the usage of the module.exports keyword. This syntax is used to expose attributes or objects in a given file (appMsgs.js here) so that they can be used directly in another file (app.js in this example). In this system, every file can access the file named module.exports. Therefore, we have disclosed some items in the appMsgs.js file to facilitate the observation of how app.js uses (require) certain properties.
Obviously, the required keyword can make it easy for us to refer to a file. In other words, when we execute require, it will return an object representing the modular code segment. Therefore, we can assign it to an appMsgs variable, and then simply use the attribute in the console.log statement. When the code is executed, we will see the following output:
As shown in the code snippet above, I made changes to the previous code. Now, instead of publishing objects, I exported a function. This code needs to be executed every time the function is called. Below, let’s take a look at how to use it in the app.js file:
In addition to calling a property, we can also execute it like a function. Therefore, the main difference here is that whenever we execute the code, the code inside the function will be re-executed.
Here is the output of our re-running the code snippet:
So far, we have seen the two modes of module.exports and the difference between the two. Another common pattern is to use it as a constructor method. Below, let us look at another example:
The following is the changed app.js file:
Here is the changed output:
Next, let us continue to discuss another example of this type of pattern. As shown in the following code snippet, I created a new file called userRepo.js.
Below is the changed app.js file.
The following figure is the result of this change:
Of course, it is not common to use require for a single file. Next, let us discuss another mode-folder dependency.
var appMsgs = require(“ ./appMsgs”)
Node will not only look for the appMsgs.js file, but also look for appMsgs as a directory, and retrieve its value. I created a folder named logger and created an index.js file in it, the content of which is shown in the following code snippet:
Below is the app.js file that requires this module:
var logger = require(“./logger/index.js”)
var logger = require(“./logger”)
Since there is no logger.js, but only the logger directory, by default, Node will load index.js as the starting point for logger. We can verify the output result through the following command:
Here, you may have doubts in mind: Why did we so exhausted to create folders and index.js? The reason behind it is: You may put some complex dependencies together, and these dependencies may also There are other dependencies. For callers who need loggers, they don’t need to know the existence of other dependencies. This is a form of encapsulation. We can build more complex code segments in multiple files; from the consumer’s point of view, they only need to use one file. It can be seen that folders are a better way to manage such dependencies.
Node Package Manager (NPM):
Usually, we can use the following npm command to install dependencies:
npm install underscore;
As shown in the following code snippet, we can also simply require it in app.js:
As you can see, we can use various functions through the underscore software package. In the same way, when we need to use this type of module, we did not specify the path of the file, but just use its name. Node.js will be automatically loaded into its corresponding module from the node_modules folder of your application.